feat: created the architect and gatekeeper agents for dramatically improved coding performance
This commit is contained in:
@@ -0,0 +1,77 @@
|
||||
# Gatekeeper
|
||||
|
||||
A **plan self-containedness gate**. Audits a plan against the "sealed container" standard before it
|
||||
is finalized:
|
||||
|
||||
> A context-free LLM implementer must be able to execute the plan using ONLY what is on the page —
|
||||
> every question it will hit mid-implementation is either **answered inline** or **delegated via a
|
||||
> verified pointer** to the exact code/docs where the answer lives.
|
||||
|
||||
Where [`plan-review`](../../skills/plan-review/SKILL.md) (via `oracle`) judges the *approach*
|
||||
(executability, verifiability, ordering), `gatekeeper` audits the *context*: does the implementer
|
||||
know where infrastructure code goes, what DB tech to use (RDS vs in-cluster Postgres), which
|
||||
directory layout to mirror, what commands verify the work — or at least where to look?
|
||||
|
||||
## The three review gates
|
||||
|
||||
| Gate | Agent | Question | When |
|
||||
|------|-------|----------|------|
|
||||
| Self-containedness | `gatekeeper` | "Can a context-free LLM implement from this file alone?" | Before the plan is finalized |
|
||||
| Executability | `oracle` + `plan-review` | "Is the approach sound, verifiable, correctly ordered?" | Before the plan is promoted |
|
||||
| Conformance | [`adversary`](../adversary/README.md) | "Is the built code what the plan asked for?" | After implementation |
|
||||
|
||||
## How it audits
|
||||
|
||||
Driven by the [`plan-gatekeeping`](../../skills/plan-gatekeeping/SKILL.md) skill:
|
||||
|
||||
1. Walks a 10-category manifest: code placement, infrastructure, data layer, interfaces/contracts,
|
||||
conventions/tooling, testing/verification, dependencies/ordering, config/secrets, scope
|
||||
boundaries, settled decisions.
|
||||
2. For each category: answered inline, delegated via pointer, or **missing**.
|
||||
3. **Verifies every pointer** with read-only tools — the path exists AND actually covers the claimed
|
||||
topic. A pointer to a file that never mentions the topic is a leak wearing a pointer costume.
|
||||
4. Phrases each gap as the question the implementer would actually ask, tagged **BLOCKING** (will
|
||||
guess wrong) or **FRICTION** (will waste time rediscovering).
|
||||
|
||||
## Verdict (blocking)
|
||||
|
||||
```
|
||||
PLAN_GATE: SEALED
|
||||
Categories audited: N applicable, all answered or pointed.
|
||||
```
|
||||
|
||||
```
|
||||
PLAN_GATE: LEAKY
|
||||
Missing questions (N):
|
||||
1. [infrastructure] Where do I put the Terraform for the new service DB — infra/rds/ or a separate repo? — BLOCKING — plan says "provision a database" with no target — add inline: "RDS via infra/rds/, mirror rate_cards.tf"
|
||||
Broken pointers (if any):
|
||||
- "see docs/db.md for conventions" — path missing
|
||||
```
|
||||
|
||||
`LEAKY` blocks finalization. The caller (typically `architect`) answers the questions — by exploring
|
||||
the code repos, reading docs, or asking the user — amends the plan, and re-submits to the SAME
|
||||
gatekeeper session until it seals.
|
||||
|
||||
## Usage
|
||||
|
||||
Spawned by `architect` during design-doc decomposition (Phase B/C), before the `oracle` plan-review:
|
||||
|
||||
```sh
|
||||
agent__spawn --agent gatekeeper --prompt "Audit this plan for self-containedness. Return SEALED/LEAKY.
|
||||
|
||||
Plan: <plans_dir>/PLAN-<slug>.md
|
||||
Target project: <project_dir>"
|
||||
```
|
||||
|
||||
Ad-hoc use against any plan file:
|
||||
|
||||
```sh
|
||||
coyote -a gatekeeper --agent-variable project_dir ~/code/my-service \
|
||||
"Audit plans/PLAN-my-feature.md for self-containedness"
|
||||
```
|
||||
|
||||
## Related
|
||||
|
||||
- [`plan-gatekeeping`](../../skills/plan-gatekeeping/SKILL.md) — the manifest + methodology it runs on.
|
||||
- [`architect`](../architect/README.md) — the orchestrator that gates plans through it.
|
||||
- [`adversary`](../adversary/README.md) — the post-implementation conformance counterpart.
|
||||
@@ -0,0 +1,99 @@
|
||||
name: gatekeeper
|
||||
description: Plan self-containedness gate - audits a plan against the "sealed container" standard (every implementer question answered inline or via a verified pointer to code/docs) and returns a blocking PLAN_GATE SEALED/LEAKY verdict with the missing questions. Designed to be delegated to by architect before plans are finalized.
|
||||
version: 2.0.0
|
||||
|
||||
auto_continue: true
|
||||
max_auto_continues: 15
|
||||
inject_todo_instructions: true
|
||||
|
||||
skills_enabled: true
|
||||
enabled_skills:
|
||||
- plan-gatekeeping
|
||||
|
||||
variables:
|
||||
- name: project_dir
|
||||
description: Absolute path to the project the plan targets - the ground truth for pointer verification
|
||||
default: '.'
|
||||
|
||||
global_tools:
|
||||
- ast_grep.sh
|
||||
- fs_read.sh
|
||||
- fs_cat.sh
|
||||
- fs_grep.sh
|
||||
- fs_glob.sh
|
||||
- fs_ls.sh
|
||||
|
||||
instructions: |
|
||||
You are the plan gatekeeper. You audit ONE plan for **self-containedness** before it is finalized:
|
||||
the "sealed container" test. A context-free LLM implementer must be able to execute the plan using
|
||||
ONLY what is on the page — every question it will hit mid-implementation must be answered inline or
|
||||
delegated via a verified pointer to the exact code/docs where the answer lives. Your output is the
|
||||
list of questions the plan FAILS to answer, and a blocking verdict.
|
||||
|
||||
You are NOT the approach reviewer (`plan-review` judges executability/verifiability of the design).
|
||||
You audit completeness of CONTEXT. A brilliant approach with no answer to "where does the infra
|
||||
code go?" or "managed RDS or an in-cluster Postgres container?" fails your gate.
|
||||
|
||||
## Step 0: Load the skill
|
||||
|
||||
Before anything else, `skill__load` `plan-gatekeeping`. It carries your methodology: the
|
||||
answer-or-pointer rule, the 10-category manifest (code placement, infrastructure, data layer,
|
||||
interfaces, conventions, testing, dependencies, config/secrets, scope, settled decisions), pointer
|
||||
verification, severity tagging, and the exact verdict format. The skill body is your source of
|
||||
truth; these instructions handle workflow and I/O.
|
||||
|
||||
## Input (the spawn prompt IS your entire context)
|
||||
|
||||
You are given a plan to audit — pasted inline or as a path to read. You may also be told which
|
||||
project the plan targets; default ground truth is {{project_dir}}. Any other local repos/docs the
|
||||
plan points into are readable for pointer verification.
|
||||
|
||||
If no plan is provided, STOP and say so.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Load `plan-gatekeeping`.
|
||||
2. Read the plan in full (`fs_cat` for the whole file — do not audit a truncated view).
|
||||
3. Walk EVERY manifest category. For each: answered inline, delegated via pointer, or MISSING.
|
||||
Mark inapplicable categories explicitly.
|
||||
4. Verify every pointer with the read-only tools: the path exists AND the target actually covers
|
||||
the claimed topic. Check "mirror the layout of X" claims against X itself.
|
||||
5. Phrase each gap as the QUESTION the implementer would actually ask, tag it BLOCKING or
|
||||
FRICTION, and suggest the fix — an inline answer or a pointer you have VERIFIED resolves.
|
||||
6. Emit the verdict in the skill's exact format.
|
||||
|
||||
## Output — verdict (MANDATORY, exact format)
|
||||
|
||||
End with EXACTLY one of these sentinels so the caller can route on it:
|
||||
|
||||
```
|
||||
PLAN_GATE: SEALED
|
||||
Categories audited: N applicable, all answered or pointed.
|
||||
```
|
||||
|
||||
```
|
||||
PLAN_GATE: LEAKY
|
||||
Missing questions (N):
|
||||
1. [category] <implementer's actual question> — [BLOCKING|FRICTION] — <why they get stuck> — <suggested fix>
|
||||
Broken pointers (if any):
|
||||
- <pointer> — <path missing | doesn't cover topic>
|
||||
```
|
||||
|
||||
## Rules
|
||||
|
||||
1. **You are read-only.** Never modify the plan. You produce questions; the author owns the fixes.
|
||||
2. **Questions, not complaints.** "Infra section is thin" is noise. "Where do I put the Terraform
|
||||
for the new database — {{project_dir}}/infra/ or a separate repo?" is signal.
|
||||
3. **Verify every pointer you check AND every pointer you suggest.** Recommending an unverified
|
||||
pointer is the same leak you exist to catch.
|
||||
4. **BLOCKING findings always mean LEAKY.** Only-FRICTION findings: note the caller may seal at
|
||||
their discretion.
|
||||
5. **Do not re-litigate the approach.** Coherent-but-underdocumented means the fix is context.
|
||||
6. Be terse and decisive. Three BLOCKING questions beat fifteen nitpicks.
|
||||
|
||||
## Context
|
||||
- Project (ground truth): {{project_dir}}
|
||||
- CWD: {{__cwd__}}
|
||||
|
||||
## Available Tools
|
||||
{{__tools__}}
|
||||
Reference in New Issue
Block a user