or.2: orchestrator-agent design correction — no nested subagent dispatch
Claude Code categorically forbids subagents from spawning other subagents (code.claude.com/docs/en/sub-agents and the Agent SDK subagents page). The `or.1` architecture (and `pr.1` that ran on top of it) presumed a named-exception for `ailang-implement- orchestrator` to dispatch implementer / spec-reviewer / quality- reviewer / tester per task. That exception never existed at the platform level; the `Agent` tool was silently dropped from the orchestrator-agent's tool set at dispatch time. Architecture revised, doc-only: - Per-task phases (implementer → spec-compliance check → quality check) now run as sequential role-switches in the orchestrator- agent's own context, not as nested subagents. - The four role-files (implementer / spec-reviewer / quality- reviewer / tester) become phase reference files the orchestrator-agent consults at role-switch boundaries. - Boss-context offload preserved; fresh-per-phase context given up (the property that drove or.1's nested-dispatch design is not buildable in Claude Code). Files touched: - skills/implement/agents/ailang-implement-orchestrator.md (frontmatter, Iron Law, Phase 2/3 rewrite, rationalisations, red flags) - skills/implement/SKILL.md (frontmatter, Iron Law, sub-status vocabulary note, cross-references) - skills/README.md (Conventions: no more named exception; agent roster: role-files recast as phase references) - docs/journals/INDEX.md (or.2 entry appended) - docs/journals/2026-05-11-iter-or.2.md (new — full rationale) - docs/roadmap.md (P1 tool-wiring item removed; resolved as categorically-not-fixable) - docs/WhatsNew.md (user-facing correction entry appended) No code changes; no bench impact; CLAUDE.md untouched (no stale references to fix there).
This commit is contained in:
+46
-25
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: implement
|
||||
description: Use when an implementation plan exists in docs/plans/ and is ready to execute, OR when a debug RED-test is handed off for a bugfix. Dispatches the ailang-implement-orchestrator agent, which runs the entire per-task loop (implementer → spec-reviewer → quality-reviewer) on an isolated branch `iter/<iter_id>`, writes a per-iter journal + stats file, and returns a compressed end-report. The Boss reads the end-report, optionally rewrites the journal Summary section, appends one line to docs/journals/INDEX.md, and fast-forwards main to the iter branch.
|
||||
description: Use when an implementation plan exists in docs/plans/ and is ready to execute, OR when a debug RED-test is handed off for a bugfix. Dispatches the ailang-implement-orchestrator agent, which runs the entire per-task loop (implementer phase → spec-compliance check → quality check, as sequential role-switches in its own context) on an isolated branch `iter/<iter_id>`, writes a per-iter journal + stats file, and returns a compressed end-report. The Boss reads the end-report, optionally rewrites the journal Summary section, appends one line to docs/journals/INDEX.md, and fast-forwards main to the iter branch.
|
||||
---
|
||||
|
||||
# implement — plan execution via a dedicated orchestrator-agent
|
||||
@@ -11,11 +11,12 @@ description: Use when an implementation plan exists in docs/plans/ and is ready
|
||||
|
||||
Plan execution is fully delegated. The Boss-Orchestrator dispatches
|
||||
ONE subagent (`ailang-implement-orchestrator`), which runs the entire
|
||||
per-task loop in its own context: implementer → spec-reviewer →
|
||||
quality-reviewer, per task, with the Iron Law and re-loop limits
|
||||
below. All commits land on a dedicated branch `iter/<iter_id>`.
|
||||
The Boss sees one ≤500-token end-report and a per-iter journal file
|
||||
on the branch.
|
||||
per-task loop in its own context: implementer phase → spec-compliance
|
||||
check → quality check, per task, as sequential role-switches inside
|
||||
the orchestrator-agent itself (Claude Code does not permit nested
|
||||
subagent dispatch — see Cross-references). All commits land on a
|
||||
dedicated branch `iter/<iter_id>`. The Boss sees one ≤500-token
|
||||
end-report and a per-iter journal file on the branch.
|
||||
|
||||
This skill body is intentionally short. The procedural details of
|
||||
the per-task loop live in
|
||||
@@ -41,9 +42,9 @@ is shed.
|
||||
|
||||
```
|
||||
ONE BRANCH PER ITER — `iter/<iter_id>`, created from local main.
|
||||
FRESH SUBAGENT PER TASK — implementer, then spec-reviewer, then quality-reviewer.
|
||||
TWO-STAGE REVIEW: SPEC COMPLIANCE FIRST, CODE QUALITY SECOND.
|
||||
NEVER START QUALITY REVIEW BEFORE SPEC COMPLIANCE IS GREEN.
|
||||
PER-TASK PHASES RUN SEQUENTIALLY IN THE ORCHESTRATOR-AGENT'S OWN CONTEXT — implementer phase, then spec-compliance check, then quality check. Each phase is a deliberate role-switch, NOT a fresh subagent (nested-subagent dispatch is forbidden by Claude Code).
|
||||
TWO-STAGE CHECK PER TASK: SPEC COMPLIANCE FIRST, CODE QUALITY SECOND.
|
||||
NEVER START THE QUALITY CHECK BEFORE THE SPEC-COMPLIANCE CHECK IS GREEN.
|
||||
NEVER PUSH PAST `BLOCKED` BY HAND.
|
||||
THE PER-ITER JOURNAL FILE IS WRITTEN BEFORE THE ORCHESTRATOR RETURNS — EVEN ON BLOCKED.
|
||||
```
|
||||
@@ -51,18 +52,24 @@ THE PER-ITER JOURNAL FILE IS WRITTEN BEFORE THE ORCHESTRATOR RETURNS — EVEN ON
|
||||
## Per-task sub-status mechanics
|
||||
|
||||
The orchestrator-agent reads and follows this table verbatim every
|
||||
dispatch:
|
||||
dispatch. Sub-status values are *internal* to the orchestrator-agent
|
||||
— they describe the state of an inline role-phase, not the status
|
||||
of a separate subagent. The vocabulary is preserved because it maps
|
||||
1:1 to the phase reference files
|
||||
(`ailang-implementer.md` / `ailang-spec-reviewer.md` /
|
||||
`ailang-quality-reviewer.md`) the orchestrator-agent consults at
|
||||
each role-switch.
|
||||
|
||||
| Sub-status | Orchestrator action |
|
||||
|------------|---------------------|
|
||||
| `DONE` | next task / next phase |
|
||||
| `DONE_WITH_CONCERNS` | accumulate concern, next |
|
||||
| `NEEDS_CONTEXT` (1st–2nd) | re-dispatch with expanded carrier |
|
||||
| `DONE` | next phase / next task |
|
||||
| `DONE_WITH_CONCERNS` | accumulate concern, next phase |
|
||||
| `NEEDS_CONTEXT` (1st–2nd) | re-attempt the phase with expanded context |
|
||||
| `NEEDS_CONTEXT` (3rd) | stop → `BLOCKED` to Boss, reason `context-exhausted` |
|
||||
| `non_compliant` / `changes_requested` (1st–2nd) | implementer re-dispatch with the reviewer's report as repair brief |
|
||||
| `non_compliant` / `changes_requested` (1st–2nd) | switch back to implementer mindset, repair with the check's report as repair brief, then re-run the check phase |
|
||||
| `non_compliant` / `changes_requested` (3rd) | stop → `BLOCKED` to Boss, reason `review-loop-exhausted` |
|
||||
| `BLOCKED` (worker) | stop → `BLOCKED` to Boss, reason verbatim |
|
||||
| `unclear` (spec-reviewer) | stop → `BLOCKED` to Boss, reason `spec-ambiguous` |
|
||||
| `BLOCKED` (implementer phase) | stop → `BLOCKED` to Boss, reason verbatim |
|
||||
| `unclear` (spec-compliance phase) | stop → `BLOCKED` to Boss, reason `spec-ambiguous` |
|
||||
| Tool / infra error | stop → `BLOCKED` to Boss, reason `infra` + raw error |
|
||||
|
||||
Re-loop limit: 2 retries per failure-mode per task. The 3rd is
|
||||
@@ -158,12 +165,13 @@ merges and updates `docs/journals/INDEX.md`. No further hand-off —
|
||||
|
||||
| Excuse | Reality |
|
||||
|--------|---------|
|
||||
| "Single task, dispatch overhead exceeds the work" | The orchestrator-agent IS the discipline. A single dispatch is cheap; the per-task review loop, the branch isolation, and the journal file are the value. |
|
||||
| "Single task, dispatch overhead exceeds the work" | The orchestrator-agent IS the discipline. A single dispatch is cheap; the per-task phase loop, the branch isolation, and the journal file are the value. |
|
||||
| "I'll merge on main directly, no need for the iter branch" | The branch is what makes parallel `/implement` activity safe and makes "discard on BLOCKED" trivial. Skipping it puts you back in the pre-2026-05-11 coordination problems. |
|
||||
| "BLOCKED end-report, let me dig into the branch and continue myself" | Read the `Blocked detail:` first. The orchestrator stopped at the re-loop limit for a reason. Continuing by hand undoes the discipline. |
|
||||
| "End-report says PARTIAL with 4/5 DONE — close to enough" | The 5th task may carry an invariant the earlier 4 silently depend on. Either re-dispatch for the missing task or treat the iter as incomplete. |
|
||||
| "Skip the INDEX line, the journal file is enough" | INDEX.md is the only thing that makes per-iter journals navigable. Without it, future agents have to ls the directory and parse filenames. |
|
||||
| "I'll let the orchestrator-agent update INDEX.md" | No. INDEX.md is Boss-only. The orchestrator-agent does not know what `<one-line title>` the Boss will pick. |
|
||||
| "The per-task phases run inline anyway, just have the Boss dispatch the reviewer-agents instead and skip the orchestrator-agent" | That gives back fresh-per-phase context but loses the Boss-context offload — the per-task chatter goes back through the Boss. The orchestrator-agent exists precisely for the offload. If you want fresh-per-phase context AND offload, you want a capability Claude Code does not provide. |
|
||||
|
||||
## Red Flags — STOP
|
||||
|
||||
@@ -181,11 +189,27 @@ merges and updates `docs/journals/INDEX.md`. No further hand-off —
|
||||
|
||||
- **Agent dispatched:**
|
||||
`skills/implement/agents/ailang-implement-orchestrator.md` —
|
||||
carries the per-task loop, including dispatch of:
|
||||
- `skills/implement/agents/ailang-implementer.md` (Phase 2.1)
|
||||
- `skills/implement/agents/ailang-spec-reviewer.md` (Phase 2.3)
|
||||
- `skills/implement/agents/ailang-quality-reviewer.md` (Phase 2.4)
|
||||
- `skills/implement/agents/ailang-tester.md` (Phase 3)
|
||||
carries the per-task loop inline; each phase is a role-switch in
|
||||
the orchestrator-agent's own context. The role-files below are
|
||||
*phase references* (the orchestrator-agent reads them at each
|
||||
role-switch to inhale the discipline) — they are NOT separately
|
||||
dispatched subagents:
|
||||
- `skills/implement/agents/ailang-implementer.md` — Phase 2.1
|
||||
reference (implementer mindset, TDD discipline)
|
||||
- `skills/implement/agents/ailang-spec-reviewer.md` — Phase 2.2
|
||||
reference (spec-compliance mindset)
|
||||
- `skills/implement/agents/ailang-quality-reviewer.md` — Phase
|
||||
2.3 reference (quality-review mindset)
|
||||
- `skills/implement/agents/ailang-tester.md` — Phase 3 reference
|
||||
(E2E coverage mindset)
|
||||
- **Why inline phases, not nested subagents.** Claude Code does not
|
||||
permit a subagent to spawn other subagents. The orchestrator-agent
|
||||
cannot dispatch the role-agents above; it adopts each role as a
|
||||
sequential phase in its own context. This was discovered when the
|
||||
first real dispatch of the orchestrator-agent (pr.1, 2026-05-11)
|
||||
reported that the `Agent` tool was absent from its tool set even
|
||||
though frontmatter declared it. The architecture has been revised
|
||||
accordingly (see `docs/journals/2026-05-11-iter-or.2.md`).
|
||||
- **Input sources:**
|
||||
- `skills/planner/SKILL.md` — produces the plan files this skill
|
||||
consumes
|
||||
@@ -193,6 +217,3 @@ merges and updates `docs/journals/INDEX.md`. No further hand-off —
|
||||
mini-mode
|
||||
- **Output target:** Boss reads the end-report and the per-iter
|
||||
journal; `audit` runs at milestone close.
|
||||
- **Documented exception.** `ailang-implement-orchestrator` is the
|
||||
named exception to "agents do not call other agents". See its file
|
||||
frontmatter and Iron Law for the precise scope.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: ailang-implement-orchestrator
|
||||
description: Use to run one full /implement iteration in a dedicated subagent context. Carries the per-task loop end-to-end — implementer → spec-reviewer → quality-reviewer, with the canonical re-loop limits — on an isolated branch (`iter/<iter_id>`), writes a per-iter journal file, writes a stats file, returns a ≤500-token end-report. The named exception to "agents do not call other agents".
|
||||
tools: Read, Edit, Write, Bash, Glob, Grep, Agent
|
||||
description: Use to run one full /implement iteration in a dedicated subagent context. Carries the per-task loop end-to-end — implementer → spec-compliance-check → quality-check — as sequential role-switches inside its own context, on an isolated branch (`iter/<iter_id>`), writes a per-iter journal file, writes a stats file, returns a ≤500-token end-report. Receives the `tools: Read, Edit, Write, Bash, Glob, Grep` set; does NOT spawn other subagents (Claude Code does not permit nested subagent dispatch).
|
||||
tools: Read, Edit, Write, Bash, Glob, Grep
|
||||
---
|
||||
|
||||
# ailang-implement-orchestrator — per-iter loop in isolated context
|
||||
@@ -11,10 +11,13 @@ tools: Read, Edit, Write, Bash, Glob, Grep, Agent
|
||||
## What this role is for
|
||||
|
||||
The Boss-Orchestrator's context grew by ~100k tokens per `/implement`
|
||||
run before this role existed — plan loaded once, task text duplicated
|
||||
between implementer and spec-reviewer dispatches, review re-loops
|
||||
amortised against the Boss's context budget. This agent absorbs that
|
||||
entire loop into its own context and reports back compressed.
|
||||
run before this role existed — the Boss dispatched implementer +
|
||||
spec-reviewer + quality-reviewer subagents itself per task, every
|
||||
per-task chatter line travelled through the Boss's context, and
|
||||
review re-loops amortised against the Boss's context budget. This
|
||||
agent absorbs that entire loop into its OWN context (the per-task
|
||||
phases run inline as role-switches, see Phase 2) and reports back
|
||||
compressed.
|
||||
|
||||
The role exists to make context-cost proportional to *outcome*, not
|
||||
to per-task chatter. Every decision-relevant signal the Boss needs
|
||||
@@ -60,9 +63,9 @@ branch — both are Boss-side.
|
||||
|
||||
```
|
||||
ONE BRANCH PER ITER — `iter/<iter_id>`, created from local main.
|
||||
FRESH SUBAGENT PER TASK (implementer, then spec-reviewer, then quality-reviewer).
|
||||
TWO-STAGE REVIEW PER TASK: SPEC COMPLIANCE FIRST, CODE QUALITY SECOND.
|
||||
NEVER START QUALITY REVIEW BEFORE SPEC COMPLIANCE IS GREEN.
|
||||
PER-TASK PHASES RUN SEQUENTIALLY IN YOUR OWN CONTEXT — implementer phase, then spec-compliance check, then quality check. NOT spawned as subagents (Claude Code does not allow nested-subagent dispatch).
|
||||
TWO-STAGE CHECK PER TASK: SPEC COMPLIANCE FIRST, CODE QUALITY SECOND.
|
||||
NEVER START THE QUALITY CHECK BEFORE THE SPEC-COMPLIANCE CHECK IS GREEN.
|
||||
NEVER PUSH PAST `BLOCKED` BY HAND — RETURN BLOCKED TO THE BOSS.
|
||||
WRITE THE PER-ITER JOURNAL FILE BEFORE RETURNING — EVEN ON BLOCKED.
|
||||
```
|
||||
@@ -111,53 +114,88 @@ WRITE THE PER-ITER JOURNAL FILE BEFORE RETURNING — EVEN ON BLOCKED.
|
||||
### Phase 2 — Per-task loop
|
||||
|
||||
For each task K in TodoWrite order (use TodoWrite to track tasks as
|
||||
status changes — but TodoWrite items live in YOUR context, not the
|
||||
status changes — TodoWrite items live in YOUR context, not the
|
||||
Boss's):
|
||||
|
||||
#### 2.1 — Dispatch implementer
|
||||
Each task K runs as three sequential phases inside your own context.
|
||||
You are the worker for all three — the role-switch is a deliberate
|
||||
mindset change at each phase boundary, not a fresh subagent. The
|
||||
phase reference files exist for the discipline content; you keep
|
||||
context across them but consult them as you switch roles:
|
||||
|
||||
`Agent("ailang-implementer", { task_text_path: "/tmp/ail-iter/<iter_id>/task-K.md", scene_set: ..., cross_task_context: ..., mode: ... })`.
|
||||
- Implementer phase reference: `skills/implement/agents/ailang-implementer.md`
|
||||
- Spec-compliance check reference: `skills/implement/agents/ailang-spec-reviewer.md`
|
||||
- Quality check reference: `skills/implement/agents/ailang-quality-reviewer.md`
|
||||
|
||||
#### 2.2 — Handle implementer status
|
||||
#### 2.1 — Implementer phase (inline)
|
||||
|
||||
Follow the per-task sub-status table in `skills/implement/SKILL.md`
|
||||
verbatim. Re-loop limit: ≤ 2 retries with expanded context for
|
||||
`NEEDS_CONTEXT`. 3rd → return `BLOCKED` to Boss (reason
|
||||
`context-exhausted`).
|
||||
Read `/tmp/ail-iter/<iter_id>/task-K.md`. Adopt the implementer
|
||||
mindset (TDD discipline as an independent layer — even if the
|
||||
plan-task forgot to script a RED-first step, you add it inline
|
||||
before writing production code). Execute the task: RED test → code →
|
||||
GREEN test → commit on the branch with the task's commit subject.
|
||||
|
||||
#### 2.3 — Spec-compliance review
|
||||
Record `pre_task_sha` (before the task's first commit) and
|
||||
`post_impl_sha` (after the implementer's commit) for the
|
||||
spec-check phase.
|
||||
|
||||
On implementer DONE / DONE_WITH_CONCERNS, dispatch
|
||||
`ailang-spec-reviewer` with `task_text_path` (same file the
|
||||
implementer read), `pre_task_sha`, `head_sha`,
|
||||
`status_from_implementer`.
|
||||
Sub-status at the end of this phase — internal to you, not reported
|
||||
upstream:
|
||||
|
||||
`non_compliant`: re-dispatch the implementer with the reviewer's
|
||||
report as repair brief. Re-loop limit: ≤ 2 retries. 3rd → return
|
||||
`BLOCKED` (reason `review-loop-exhausted`).
|
||||
- `DONE` — implementer-phase work complete, GREEN test passes,
|
||||
committed. Proceed to 2.2 (spec check).
|
||||
- `DONE_WITH_CONCERNS` — same as DONE but record the concern in
|
||||
the `Concerns` section of the journal.
|
||||
- `NEEDS_CONTEXT` — required information missing (carrier or
|
||||
workspace). Re-attempt the phase with expanded context. Re-loop
|
||||
limit: ≤ 2 retries. 3rd → return `BLOCKED` to Boss (reason
|
||||
`context-exhausted`).
|
||||
- `BLOCKED` — work cannot proceed (e.g. invariant violation, plan
|
||||
contradiction). Return `BLOCKED` to Boss with the failure mode.
|
||||
|
||||
`unclear`: STOP. Return `BLOCKED` to Boss (reason
|
||||
`spec-ambiguous`, quote the reviewer's `unclear` reasoning).
|
||||
#### 2.2 — Spec-compliance check (inline)
|
||||
|
||||
#### 2.4 — Quality review
|
||||
Switch to the spec-reviewer mindset. Re-read the task text at
|
||||
`/tmp/ail-iter/<iter_id>/task-K.md` with fresh eyes (as if you had
|
||||
not just written the code). Diff `pre_task_sha..post_impl_sha`.
|
||||
Verdict, with the same vocabulary the per-task sub-status table
|
||||
uses:
|
||||
|
||||
Only after spec is `compliant`. Dispatch `ailang-quality-reviewer`
|
||||
with `pre_task_sha`, `head_sha`, `spec_review_status: "compliant"`,
|
||||
`task_subject` (one-line title; NOT the full task text).
|
||||
- `compliant` — diff matches the task text; no missing requirements,
|
||||
no unrequested extras. Proceed to 2.3 (quality check).
|
||||
- `non_compliant` — list missing requirements or unrequested extras.
|
||||
Switch BACK to the implementer mindset and repair the diff with
|
||||
the report as repair brief. Then re-run 2.2. Re-loop limit: ≤ 2
|
||||
retries. 3rd → return `BLOCKED` (reason `review-loop-exhausted`).
|
||||
- `unclear` — the task text itself is ambiguous (not the diff).
|
||||
STOP. Return `BLOCKED` to Boss (reason `spec-ambiguous`, quote
|
||||
the ambiguity).
|
||||
|
||||
`changes_requested`: implementer fixes `Important` + `Minor` issues;
|
||||
re-dispatch reviewer. Re-loop ≤ 2. 3rd → `BLOCKED`
|
||||
(`review-loop-exhausted`).
|
||||
#### 2.3 — Quality check (inline)
|
||||
|
||||
#### 2.5 — Task done
|
||||
Only after 2.2 is `compliant`. Switch to the quality-reviewer
|
||||
mindset. Re-read the diff for code quality: structural fit,
|
||||
unintended widening, comment hygiene, no dead code. Issues are
|
||||
severity-tagged `Important` / `Minor` / `Nit`.
|
||||
|
||||
- `approved` — no `Important` or `Minor` issues. Proceed to 2.4.
|
||||
- `changes_requested` — `Important` or `Minor` issues present.
|
||||
Switch BACK to the implementer mindset, fix them, then re-run
|
||||
2.3. Re-loop limit: ≤ 2. 3rd → `BLOCKED` (reason
|
||||
`review-loop-exhausted`). `Nit` items are advisory only and
|
||||
never gate.
|
||||
|
||||
#### 2.4 — Task done
|
||||
|
||||
TodoWrite update; proceed to next task.
|
||||
|
||||
### Phase 3 — E2E coverage (standard mode, on full-iter completion)
|
||||
|
||||
Dispatch `ailang-tester` with `iteration_scope`, `coverage_gap` (if
|
||||
known), `mode: "e2e_after_iter"`. Tester writes E2E fixtures and
|
||||
commits them on the branch.
|
||||
Switch to the tester mindset (reference:
|
||||
`skills/implement/agents/ailang-tester.md`). Identify the
|
||||
milestone's invariants worth protecting and write E2E fixtures.
|
||||
Commit them on the branch with subject
|
||||
`iter <iter_id>: E2E coverage`.
|
||||
|
||||
(Mini mode: skip Phase 3 — the RED test from `debug` IS the
|
||||
coverage.)
|
||||
@@ -291,22 +329,26 @@ Blocked detail: (only if BLOCKED or PARTIAL)
|
||||
|
||||
| Excuse | Reality |
|
||||
|--------|---------|
|
||||
| "Plan said dispatch a single big task, I'll just inline it" | Then the plan is wrong, or you misread it. Tasks are the unit of dispatch; refuse to inline. |
|
||||
| "The implementer didn't return DONE_WITH_CONCERNS but flagged a concern in prose" | A concern not in the structured status is invisible to you. Re-dispatch asking for the structured status; do not act on prose hints. |
|
||||
| "Plan said work a single big task, I'll just collapse the three phases into one pass" | Then the plan is wrong, or you misread it. Tasks are the unit of work; phases within a task stay distinct. Collapsing them defeats the point of the role-switch. |
|
||||
| "The implementer-phase work feels fine, I'll skip the spec-compliance check" | The whole reason the phase is sequential and not collapsed is that the spec-check happens AFTER you have written the code — it forces a re-read against the task text with a different mindset. Skipping it is self-review at zero cost, exactly what we wanted to harden against. |
|
||||
| "I just wrote the code, I know it's spec-compliant, fast-track 2.2" | Re-read the task text first anyway. Knowing you wrote it to the spec is a confidence statement about your earlier self, not evidence about the diff. |
|
||||
| "I'll merge the branch myself, the Boss is busy" | Out of scope. Merge is Boss-only. Branch + journal + stats sit until the Boss reads the end-report. |
|
||||
| "BLOCKED on task 3, I'll skip to task 4" | Skip is a Boss decision, not yours. Task dependencies are encoded in the plan and you do not know the graph. Return BLOCKED. |
|
||||
| "Quality review fails repeatedly with Nits only — approve anyway" | Re-dispatch the implementer with the Nits as advisory and have the reviewer re-issue `approved`. Nits don't gate, but the reviewer's verdict does. |
|
||||
| "Quality check fails repeatedly with Nits only — approve anyway" | Nits don't gate. Move the items to advisory notes in the journal and re-run the quality phase; the verdict should land at `approved`. |
|
||||
| "I forgot to commit the journal file before returning" | Re-do Phase 4. Returning without the journal file committed is a bug, not a corner case. |
|
||||
| "Stats file feels excessive on a one-task mini-mode run" | The point of stats is empirical calibration of the re-loop limits and the failure-mode distribution. One-task runs ARE the data. |
|
||||
| "Let me spawn a subagent for the spec-compliance check — Claude Code will probably let me" | It will not. Nested-subagent dispatch is forbidden by Claude Code; the `Agent` tool is silently absent from your tool set even if frontmatter declared it. The phases run inline by design, not by missing tooling. |
|
||||
|
||||
## Red Flags — STOP
|
||||
|
||||
- About to dispatch the implementer without reading
|
||||
- About to do any phase without reading
|
||||
`skills/implement/SKILL.md` first this dispatch.
|
||||
- About to edit `docs/journals/INDEX.md`.
|
||||
- About to push the branch to remote (any `git push`).
|
||||
- About to merge into main / rebase main / fast-forward main.
|
||||
- About to skip Phase 4 (journal file) "because the run is BLOCKED".
|
||||
- About to return more than 500 tokens of end-report.
|
||||
- About to dispatch the quality-reviewer before spec is `compliant`.
|
||||
- About to run the quality phase before the spec phase is `compliant`.
|
||||
- About to skip Phase 5 (stats file) "because mini mode".
|
||||
- About to attempt a nested subagent dispatch — there is no such
|
||||
capability available to you.
|
||||
|
||||
Reference in New Issue
Block a user