deep-plan

name	deep-plan
description	Use before touching code for any multi-step task — features, refactors, migrations, architectural decisions, bug fixes, or any work that needs to be broken into verifiable steps. Trigger phrases include "write a plan", "implementation plan", "plan this", "plan the work", "break this down", "how should I approach this", "make a plan", "design the approach", "before I code this", "I need a plan", "write up the plan", "spec to plan", "requirements to plan". Produces SDD-compatible plan.md, research.md, data-model.md, contracts/, and tasks.md via a Planner → Architect → Critic consensus loop.
user_invocable	true
argument	The task description or problem statement to produce a deep plan for. --sdd-dir <path> Target directory for SDD artifacts (e.g., specs/003-feature/). If omitted, auto-creates specs/{NNN-feature-name}/ from task. --spec <path> Path to existing spec.md to plan against. If omitted, plans from the task description directly.
category	plan
capabilities	["consensus-building","adr-generation"]
best_for	["Breaking multi-step tasks into verifiable implementation plans","Architectural decisions needing Planner/Architect/Critic consensus","Producing ADR-backed plans with acceptance criteria"]
not_for	["Designing a system spec (use deep-design)","Executing code (use autopilot)","Reviewing existing work (use deep-qa)"]
input_types	["task","concept"]
output_types	["plan","tasks","research","data-model","contracts"]
output_signals	["termination_label","iteration_count","verdict"]
complexity	moderate
model_tier	sonnet
cost_profile	medium
execution	{"sagaflow":"required","temporal_skill":"deep-plan-temporal","estimated_duration":"10-30min"}
related_skills	[{"name":"deep-design","relation":"prerequisite","note":"Design spec should exist before planning implementation"},{"name":"autopilot","relation":"follow-up","note":"Execute the plan"},{"name":"team","relation":"follow-up","note":"Execute the plan with multiple agents"}]
maturity	stable

Deep Plan Skill

Produce SDD-compatible implementation artifacts that three fully independent agents — Planner, Architect, Critic — agree on, or stop honestly at max iterations. The coordinator never evaluates. All three roles read and write via files only; they do not inherit coordinator context.

SDD Artifact Output

When consensus is reached (or max iterations hit), deep-plan produces the following artifacts in the target directory (--sdd-dir or auto-created specs/{NNN-feature}/):

specs/{NNN-feature}/
├── plan.md              # Implementation plan (SDD format)
├── research.md          # Resolved unknowns: Decision / Rationale / Alternatives
├── data-model.md        # Entities, fields, relationships, validation rules
├── contracts/           # Interface contracts (API endpoints, CLI schemas, etc.)
├── quickstart.md        # Key validation scenarios
├── tasks.md             # Ordered task list (phased, user-story-organized)
└── adr.md               # Architecture Decision Record

If --spec <path> is provided, the Planner reads the spec.md for requirements, user stories, and acceptance criteria. Tasks in tasks.md are organized by user story (from spec.md) with FR-### traceability.

Execution Model

All operations use Claude Code primitives. Contracts are non-negotiable:

• Fully independent agents, file I/O only. Planner, Architect, Critic are separate Agent-tool spawns. Each receives file paths, not inline content. None of them inherit the coordinator's message history. Coordinator reads structured outputs, never paraphrases.
• Strictly sequential Architect → Critic. Architect verdict file must exist on disk before Critic is spawned. Never parallelize Steps 3 and 4.
• Falsifiable rejection gate. Critic rejection is invalid without a concrete failure scenario AND an executable verification command that would prove the flaw. Vague "needs more detail" rejections are dropped.
• Verification commands per acceptance criterion. Every acceptance criterion in the final plan has a verification_command and expected_output_pattern. Prose-only criteria are rejected by the Critic.
• Honest termination labels. One of: consensus_reached_at_iter_N / max_iter_no_consensus / user_stopped. Never "approved" without a Critic APPROVE verdict on disk.
• State written before each agent spawn. spawn_time_iso recorded pre-call; spawn failure records spawn_failed and is retried on resume, not waited on.
• Structured output is the contract. All role outputs include STRUCTURED_OUTPUT_START / STRUCTURED_OUTPUT_END markers. Unparseable output fails the iteration for that role (fail-safe: Critic unparseable → treat as REJECT, Architect unparseable → re-spawn once then fail).
• No coordinator self-approval. The coordinator cannot author a plan revision or approve one. Every revision is by the Planner; every approval is by the Critic.

Shared contracts: this skill inherits the four execution-model contracts (files-not-inline, state-before-agent-spawn, structured-output, independence-invariant) from _shared/execution-model-contracts.md. The items listed above are the skill-specific elaborations; the shared file is authoritative for the base contracts.

Subagent watchdog: every run_in_background=true spawn (Planner, Architect, Critic) MUST be armed with a staleness monitor per _shared/subagent-watchdog.md. Use Flavor A with thresholds STALE=10 min, HUNG=30 min — planning agents can legitimately sit quiet while they think, but a 30-min silence is pathological. TaskOutput status is not evidence of progress. Contract inheritance: timed_out_heartbeat_<role> joins this skill's iteration-level termination vocabulary (e.g. planner_timed_out_heartbeat_at_iter_N); stalled_watchdog / hung_killed join per-role state. A watchdog-killed Planner/Architect/Critic pass terminates the iteration honestly — never silently rolls forward into consensus.

Flags

Flag	Effect
--interactive	Gates at draft review (after first Planner pass) and at final approval. Without it, runs fully autonomous and stops after the terminal label is written.
--deliberate	Forces Deliberate mode: Planner must emit a pre-mortem (3 failure scenarios) and an expanded test plan (unit / integration / e2e / observability). Critic rejects on missing/weak pre-mortem. Auto-enables for explicit high-risk signals (auth, security, data migration, destructive ops, production incident, compliance/PII, public API breakage).
--architect codex	Spawn Architect via codex CLI instead of Claude Agent. See INTEGRATION.md for invocation and degraded-mode fallback.
--critic codex / --critic gemini	Same for Critic.
--max-iter N	Override default max iterations (5). Never exceeds 5 without explicit user extension.

Workflow

Step 0: Input Validation & Initialization

1. Validate task description. Reject if:
   • Empty or <10 words of actionable content
   • Pure execution request with concrete file/symbol anchors — route back to direct execution
   • Harmful scope (weapon, exploit) — decline
2. Detect high-risk signals (see --deliberate) and set mode: "short" | "deliberate".
3. Generate run_id = $(date +%Y%m%d-%H%M%S).
4. Resolve SDD output directory:
   • If --sdd-dir provided: use that path (e.g., specs/003-user-auth/).
   • Otherwise: scan existing specs/ directories for next sequential 3-digit prefix, derive 2-4 word kebab-case name from task, create specs/{NNN-name}/.
   • Set SDD_DIR to the resolved path.
5. Resolve spec input:
   • If --spec provided: set SPEC_FILE to that path. Read and extract user stories, requirements (FR-###), success criteria (SC-###).
   • Otherwise: SPEC_FILE is empty; Planner works from task description only.
6. Create working directory: deep-plan-{run_id}/
   • state.json (see STATE.md)
   • task.md — task description locked verbatim
   • spec_ref — path to SPEC_FILE if provided
   • sdd_dir — resolved SDD_DIR
   • iterations/iter-{N}/ — one directory per iteration
     • plan.md — Planner output
     • architect-verdict.md — Architect output with STRUCTURED_OUTPUT_START/END
     • critic-verdict.md — Critic output with STRUCTURED_OUTPUT_START/END
     • feedback-bundle.md — coordinator-assembled file handed to next Planner
   • logs/decisions.jsonl — audit trail, one line per decision
7. Write initial state.json with iteration: 0, status: "planner_pending", mode, max_iterations (default 5, capped by --max-iter), sdd_dir, spec_file.
8. Print: Starting deep-plan on: {task summary} [run: {run_id}] [mode: {short|deliberate}] [max_iter: {N}] [sdd: {SDD_DIR}]

Step 1: Planner Pass (iteration N)

Before spawning:

• Increment state iteration to N.
• Write spawn_time_iso for planner in state.json; increment generation.
• Assemble Planner input file at iterations/iter-{N}/planner-input.md containing:
  • Path to task.md
  • Path to iter-{N-1}/feedback-bundle.md (empty for N=1)
  • Mode flag (short | deliberate)
  • Path to state.json (read-only reference for prior invalidated options)

Spawn Planner:

• Task(subagent_type="general-purpose", prompt=<see Planner Prompt Template>)
• Planner writes iterations/iter-{N}/plan.md in SDD format with:
  • Summary — primary requirement + technical approach
  • Technical Context — Language/Version, Primary Dependencies, Storage, Testing, Target Platform, Project Type, Performance Goals, Constraints, Scale/Scope
  • Constitution Check — validates against /memory/constitution.md if present
  • Project Structure — concrete file/directory layout for source code and tests
  • Acceptance criteria list with {id, criterion, verification_command, expected_output_pattern} per item
  • Implementation steps (file-anchored)
  • Risks + mitigations
  • RALPLAN-DR summary (Principles 3-5, Decision Drivers top 3, Viable Options ≥2 with bounded pros/cons, Invalidation Rationale if only 1 viable)
  • Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan
  • STRUCTURED_OUTPUT_START / STRUCTURED_OUTPUT_END block summarizing plan metadata
• If SPEC_FILE is provided, Planner MUST reference spec.md user stories and requirements (FR-###) in the plan

On failure: If Planner spawn fails, record spawn_failed with reason; resume retries spawn. Unparseable structured output → re-spawn once with same input; second failure → terminate with label planner_unparseable_at_iter_N.

Step 2: Interactive Draft Gate (--interactive only)

Only if --interactive is set AND N == 1:

Coordinator prints the plan + RALPLAN-DR summary (Principles / Drivers / Options) and STOPS. This is a turn-boundary interaction — no blocking prompt. The user continues the conversation with one of:

• "proceed" / "review" / "looks good" → go to Step 3
• "change X" / specific edits → mark planner_iteration_requested, write user feedback to iterations/iter-{N}/feedback-bundle.md with role user, go back to Step 1 (same iteration N), re-spawn Planner
• "stop" / "cancel" → write termination label user_stopped, go to Step 7

If no response for 2 turns, auto-proceed to Step 3.

Step 3: Architect Pass (strictly after Planner)

Pre-spawn gate: The coordinator MUST verify iter-{N}/plan.md exists and is non-empty before spawning Architect. If missing, the iteration is marked planner_missing_output and terminated.

Before spawning:

• Write spawn_time_iso for architect in state; increment generation.
• Assemble Architect input file at iterations/iter-{N}/architect-input.md containing:
  • Path to iter-{N}/plan.md
  • Path to task.md
  • Mode flag
  • Prior architect verdicts (iter-{M}/architect-verdict.md for all M < N) as reference

Spawn Architect:

• Default: Task(subagent_type="general-purpose", prompt=<see Architect Prompt Template>)
• If --architect codex: invoke Codex CLI per INTEGRATION.md; on CLI missing/failure, fall back to default with architect_mode: "degraded" tag in verdict.
• Architect writes iterations/iter-{N}/architect-verdict.md with:
  • Strongest steelman antithesis against the favored option
  • At least one real tradeoff tension (not a throwaway concern)
  • Synthesis path when possible
  • Deliberate mode: explicit flag of any principle violations in the plan
  • STRUCTURED_OUTPUT_START block:

    VERDICT|ARCHITECT_OK|ARCHITECT_CONCERNS
    CONCERN|{id}|{description}|{severity: critical|major|minor}
    TRADEOFF|{description}
    PRINCIPLE_VIOLATION|{principle_id}|{description}   (deliberate only)
    STRUCTURED_OUTPUT_END
    

Output gate: File MUST contain STRUCTURED_OUTPUT_START/END markers. If missing: re-spawn once; second failure → terminate iteration with label architect_unparseable_at_iter_N.

No Critic spawn yet. Architect verdict file must be written AND parsed successfully before Step 4.

Step 4: Critic Pass (strictly after Architect)

Pre-spawn gate: The coordinator MUST verify BOTH iter-{N}/plan.md AND iter-{N}/architect-verdict.md exist AND parse cleanly before spawning Critic. Verify by reading state.json: architect_status == "complete" and architect_structured_output_parsed == true. If not, do NOT spawn Critic.

Before spawning:

• Write spawn_time_iso for critic in state; increment generation.
• Assemble Critic input file at iterations/iter-{N}/critic-input.md with paths to:
  • iter-{N}/plan.md
  • iter-{N}/architect-verdict.md
  • task.md
  • Mode flag
  • iter-{N}/verification-commands.txt — extracted list of every verification_command in the plan, one per line

Spawn Critic:

• Default: Task(subagent_type="general-purpose", prompt=<see Critic Prompt Template>)
• If --critic codex|gemini: invoke external CLI per INTEGRATION.md with same fallback tag.
• Critic writes iterations/iter-{N}/critic-verdict.md with:
  • Principle-option consistency check
  • Fair alternative exploration check
  • Risk mitigation clarity check
  • Testable acceptance criteria check (every criterion has verification_command + expected_output_pattern)
  • Concrete verification steps check
  • Deliberate mode: pre-mortem and expanded test plan presence + quality
  • STRUCTURED_OUTPUT_START block:

    VERDICT|APPROVE|ITERATE|REJECT
    REJECTION|{id}|{checked_dimension}|{failure_scenario}|{verification_command}
    APPROVAL_EVIDENCE|{id}|{criterion_id}|{why_it_passes}
    STRUCTURED_OUTPUT_END
    

Falsifiability gate (coordinator-enforced post-parse): For every REJECTION line:

1. failure_scenario must be ≥ 20 chars AND contain a concrete actor/action (regex: must not match known rubber-stamp phrases like "needs more detail", "should be clearer", "add more context" without a scenario).
2. verification_command must be non-empty AND look executable (contains $, npm, pytest, make, ./, or similar — not pure prose).
3. Rejections failing either check are written to iter-{N}/dropped-rejections.md with reason and excluded from the feedback bundle. The coordinator logs the drop but does not evaluate validity of remaining rejections.

If all rejections drop and no remaining rejections → verdict is promoted to APPROVE_AFTER_RUBBER_STAMP_FILTER and tagged in state; continue to Step 6 as consensus (logged honestly). If some rejections survive → verdict remains ITERATE or REJECT.

Step 5: Re-Review Loop Control

Read Critic structured verdict.

• APPROVE (or promoted per falsifiability gate): Mark consensus_reached_at_iter_{N}. Go to Step 6.
• ITERATE / REJECT:
  • If N < max_iterations: build iter-{N}/feedback-bundle.md combining architect concerns + surviving critic rejections + dropped-rejection note. Increment N. Go back to Step 1.
  • If N == max_iterations: Mark max_iter_no_consensus. Go to Step 6 with the last iteration's plan as the output.

Step 6: ADR + SDD Artifact Generation

The coordinator does NOT author artifacts. Two independent agents run sequentially:

6a. ADR Scribe — spawned with file paths to:

• Final plan (last iteration's plan.md)
• All iterations' architect verdicts + critic verdicts
• RALPLAN-DR summary from final iteration's plan
• Termination label from state

ADR Scribe writes {SDD_DIR}/adr.md with:

• Decision — chosen option from RALPLAN-DR
• Drivers — top 3 from RALPLAN-DR
• Alternatives considered — all viable options with bounded pros/cons
• Why chosen — decision rationale referencing drivers
• Consequences — including accepted tradeoffs from Architect
• Follow-ups — surviving non-blocking concerns from critic history

6b. SDD Artifact Generator — spawned with paths to final plan, spec (if provided), and ADR:

Produces all remaining SDD artifacts in {SDD_DIR}/:

• plan.md — copy of final plan in SDD format (Technical Context, Constitution Check, Project Structure, Acceptance Criteria)
• research.md — extract all technical decisions from the plan and architect verdicts. Format: Decision / Rationale / Alternatives Considered per item.
• data-model.md — extract entities from spec/plan. Format: Entity name, fields, relationships, validation rules, state transitions (if applicable).
• contracts/ — extract interface definitions from the plan. API endpoints, CLI schemas, library interfaces — whatever the project type requires. Skip for purely internal tools.
• quickstart.md — key validation scenarios for integration testing, derived from acceptance criteria.
• tasks.md — ordered task list derived from plan phases and spec user stories:
  • Tasks grouped by user story (US1, US2, US3 from spec.md) for independent implementation.
  • Phase structure: Setup → Foundational → User Story 1 (P1) → User Story 2 (P2) → ... → Polish.
  • Format: - [ ] T{NNN} [P?] [US?] Description — [P] for parallelizable, [US?] for story traceability.
  • Each task includes exact file paths from plan.md's Project Structure.
  • Every task maps to ≥1 requirement (FR-###) or user story.
  • Checkpoints between phases.
  • Dependencies section with phase ordering and parallel opportunities.

The coordinator then writes the summary header. Summary includes:

• Termination label (never "approved" unless consensus_reached_at_iter_N)
• Iteration count
• SDD_DIR path and list of generated artifacts
• Architect degraded-mode flag if any
• Critic degraded-mode flag if any
• Count of dropped rubber-stamp rejections across all iterations

Step 7: Interactive Approval Gate (--interactive only)

Only if --interactive AND termination label is consensus_reached_at_iter_N OR max_iter_no_consensus:

Coordinator presents the final plan + ADR + termination label, then stops. User continues with one of:

• "approve / implement via team" → call INTEGRATION handoff to /team
• "approve / execute via loop" → handoff to /autopilot
• "request changes" → go back to Step 1 with user feedback at iter-{N+1} (if under max_iter)
• "reject" → write termination label user_rejected, keep artifacts for audit

Without --interactive: output the final plan path + ADR path + termination label and stop. Do NOT auto-execute.

Step 8: Resume Protocol

Any invocation with an existing deep-plan-{run_id}/ directory reads state.json and replays from the last committed status. See STATE.md for the status enum and exact replay rules. The coordinator never reconstructs from memory.

Golden Rules

1. Coordinator orchestrates; it does not evaluate. It does not rewrite the plan, does not classify rejections, does not soften Critic language. It reads structured outputs, enforces the falsifiability gate, and spawns agents.
2. Fully independent agents, file I/O only. Planner, Architect, Critic, ADR Scribe each receive file paths. No agent inherits coordinator context. No agent sees another agent's raw reasoning outside the files the coordinator hands it.
3. Strictly sequential Architect → Critic. Architect verdict on disk and parsed before Critic spawn. Never parallel.
4. Falsifiable rejection only. Critic rejections without concrete failure scenario + executable verification command are dropped. Dropped rejections are logged; the Critic is not re-spawned to "fix" them.
5. Acceptance criteria carry verification commands. Every criterion in the final plan has verification_command + expected_output_pattern. Prose criteria = Critic REJECT.
6. Honest termination labels. consensus_reached_at_iter_N / max_iter_no_consensus / user_stopped / user_rejected / planner_unparseable_at_iter_N / architect_unparseable_at_iter_N. No "approved" without a Critic APPROVE verdict.
7. State written before every agent spawn. spawn_time_iso recorded pre-call; spawn failure records spawn_failed with reason; resume retries, does not wait.
8. Structured output is the contract. All role outputs include STRUCTURED_OUTPUT_START/END markers. Files without markers fail the iteration. Coordinator reads structured fields only.

(See GOLDEN-RULES.md for full rationale and the anti-rationalization counter-table.)

Self-Review Checklist

• state.json is valid JSON after every write; generation strictly monotonic.
• spawn_time_iso written BEFORE each Agent tool call.
• Architect verdict file exists AND parsed cleanly before Critic is spawned.
• Every iteration has plan.md, architect-verdict.md, critic-verdict.md OR an explicit *_unparseable_at_iter_N / spawn_failed record.
• Every REJECTION line in the final iteration passes the falsifiability gate OR is written to dropped-rejections.md with reason.
• Every acceptance criterion in plan.md has a verification_command and expected_output_pattern.
• Final termination label matches state — never "approved" without a Critic APPROVE verdict on disk.
• RALPLAN-DR summary has 3-5 Principles, top 3 Decision Drivers, ≥2 Viable Options (or explicit Invalidation Rationale).
• ADR section present with Decision / Drivers / Alternatives / Why / Consequences / Follow-ups — written by ADR Scribe, not coordinator.
• Deliberate mode: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability) present, and Critic explicitly checked them.
• Architect/Critic degraded-mode tags surfaced in final summary header if external CLI fell back.
• Coordinator never rewrote a plan or verdict — all mutations done by agent spawns.
• Handoff to /autopilot, or stop — never direct execution from this skill.

Planner Prompt Template

You are the Planner. You are an independent agent spawned by the deep-plan coordinator. You do NOT inherit any prior conversation. You read from files only.

**Task file:** {task_file_path}
Read this first. It contains the verbatim task description.

**Spec file (may be empty):** {spec_file_path}
If present, read this spec.md for user stories (P1, P2, P3...), functional requirements (FR-###), success criteria (SC-###), and acceptance scenarios. Your plan MUST address every requirement and trace implementation steps to FR-### IDs.

**Feedback bundle (may be empty):** {feedback_bundle_path}
If present, read every concern and rejection. Each rejection includes a failure scenario and a verification command. Address the root cause of each — do not simply add prose.

**Mode:** {short | deliberate}

**Your job:**
1. Produce a complete plan in SDD format addressing the task.
2. Plan MUST include these SDD sections:
   - **Summary** — primary requirement + technical approach (1-2 sentences)
   - **Technical Context** — Language/Version, Primary Dependencies, Storage, Testing, Target Platform, Project Type, Performance Goals, Constraints, Scale/Scope. Mark unknowns as NEEDS CLARIFICATION.
   - **Constitution Check** — if `/memory/constitution.md` exists, validate against it. List pass/fail per principle.
   - **Project Structure** — concrete directory layout for source and tests. Use: `src/` for single project, `backend/`+`frontend/` for web, `api/`+`ios/` for mobile. Include exact paths.
   - **Complexity Tracking** — only if Constitution Check has violations that need justification.
3. Every acceptance criterion MUST include:
   - `id` (AC-NNN)
   - `criterion` (one sentence, testable)
   - `verification_command` (an executable shell command, e.g. `pytest tests/auth_test.py::test_login`, `npm run lint`, `curl -f http://localhost/health`)
   - `expected_output_pattern` (regex or literal substring the coordinator/Critic can match against command output)
3. Produce a RALPLAN-DR summary:
   - 3-5 Principles (foundational constraints — not empty slogans)
   - Top 3 Decision Drivers (what ACTUALLY decided this plan)
   - ≥2 Viable Options with bounded pros/cons per option
   - If only 1 option survives, provide Invalidation Rationale for the others
4. Produce two delta-thinking sections against the obvious baseline approach (the default a non-adversarial planner would produce):
   - **What I'd Cut** — ≥1 component, abstraction, or step from the obvious approach this plan drops, with reasoning per entry. If the plan keeps every piece of the obvious approach, state that explicitly and justify why no simplification was possible.
   - **What I'd Add** — ≥1 element the obvious approach omits but this plan requires, with reasoning per entry. If the obvious approach is already complete, state that explicitly.
   These force delta thinking vs. the status-quo approach and surface unjustified carryovers. Each entry MUST be a concrete component/step, not a vague direction.
5. If mode = deliberate:
   - Pre-mortem: 3 concrete failure scenarios ("In 6 months, this fails because…")
   - Expanded test plan: unit / integration / e2e / observability sections
6. Write the plan to: {plan_output_path}
7. End your file with a STRUCTURED_OUTPUT block summarizing criterion IDs, option IDs, and cut/add IDs.

STRUCTURED_OUTPUT format (REQUIRED — file fails without this):

STRUCTURED_OUTPUT_START ACCEPTANCE_CRITERION|{ac_id}|{criterion}|{verification_command}|{expected_output_pattern} PRINCIPLE|{p_id}|{statement} DRIVER|{d_id}|{statement} OPTION|{o_id}|{name}|{viable|invalidated}|{brief_rationale} CUT|{cut_id}|{component_or_step_dropped}|{reasoning} ADD|{add_id}|{element_added}|{reasoning} PREMORTEM|{scenario_id}|{scenario} (deliberate only) STRUCTURED_OUTPUT_END

Do NOT include rubber-stamp content. If you cannot produce ≥2 viable options, explain why in Invalidation Rationale with concrete reasons each alternative was ruled out.

You succeed by producing a plan that survives adversarial review. You fail by producing a plan that merely looks complete.

Architect Prompt Template

You are the Architect. You are an independent agent spawned by the deep-plan coordinator. You do NOT inherit any prior conversation. You read from files only.

**Plan file:** {plan_file_path}
**Task file:** {task_file_path}
**Prior architect verdicts (may be empty):** {prior_verdict_paths}

**Mode:** {short | deliberate}

**Your job — architectural soundness review:**
1. Read the plan fully.
2. Identify the favored option. Construct the strongest steelman ANTITHESIS — the best possible argument against this option (not a strawman).
3. Identify at least one REAL tradeoff tension — a decision where the plan trades A for B and the cost of losing A is non-trivial.
4. Attempt synthesis — is there a variant of the plan that preserves A while still getting most of B?
5. Mode = deliberate: explicitly flag any Principle that the plan's implementation steps appear to violate.
6. Do NOT perform the Critic's job (falsifiability, verification commands, acceptance-criterion quality) — the Critic will run next.

Write your verdict to: {verdict_output_path}

STRUCTURED_OUTPUT format (REQUIRED):

STRUCTURED_OUTPUT_START VERDICT|ARCHITECT_OK|ARCHITECT_CONCERNS CONCERN|{id}|{description}|{critical|major|minor} TRADEOFF|{description} SYNTHESIS|{description} (optional) PRINCIPLE_VIOLATION|{principle_id}|{description} (deliberate only) STRUCTURED_OUTPUT_END

**Calibration:**
- **Good application**: Identifying a tradeoff the Planner elided — a cost the plan pays that is not named in the Decision Drivers but would realistically bite in production. Forcing the Planner to confront that cost now, before the plan ossifies. Constructing a steelman antithesis strong enough that the Planner has to either accept it or rebut it concretely.
- **Taken too far**: Demanding the Planner justify every decision against a theoretical worst case. Filing architectural concerns that only manifest at 100× current scale with no evidence that scale is realistic. Rejecting any plan that isn't Pareto-optimal on all axes — real plans make deliberate tradeoffs. Treating the absence of every extension point as an architectural flaw.

You succeed by finding real architectural tension. You fail by rubber-stamping or surfacing cosmetic concerns. ARCHITECT_OK with zero concerns is only valid if you truly cannot construct a steelman antithesis after honest effort — and you must state that explicitly.

Critic Prompt Template

You are the Critic. You are an independent agent spawned by the deep-plan coordinator. You do NOT inherit any prior conversation. You read from files only.

**You succeed by REJECTING plans that would fail when implemented. You fail by rubber-stamping.**

**Plan file:** {plan_file_path}
**Architect verdict file:** {architect_verdict_path}
**Task file:** {task_file_path}
**Verification commands list:** {verification_commands_list_path}

**Mode:** {short | deliberate}

**Your job — quality gating:**
Check each dimension. A plan passes ONLY if all dimensions pass.

1. **Principle-option consistency** — Does the chosen option actually satisfy the stated Principles? Cite the violation if not.
2. **Fair alternative exploration** — Are ≥2 options presented with honest pros/cons? Are dismissed options dismissed for real reasons?
3. **Risk mitigation clarity** — Is every risk paired with a concrete mitigation? "Monitor closely" is not a mitigation.
4. **Testable acceptance criteria** — Does EVERY criterion have a `verification_command` and `expected_output_pattern`? Prose-only criteria must be rejected.
5. **Concrete verification steps** — Do the verification steps reference actual test names, actual commands, actual files?
6. Deliberate mode only:
   - Is the pre-mortem present with 3 distinct scenarios (not 3 rephrasings of one scenario)?
   - Is the expanded test plan present covering unit / integration / e2e / observability?

**FALSIFIABILITY REQUIREMENT for every rejection you file:**
- `failure_scenario` MUST describe a concrete actor, action, and observable failure ("When user submits form with empty email, API returns 500 instead of 400").
- `verification_command` MUST be executable shell (e.g. `curl -X POST … | grep "400"`). NOT prose like "test the error case."
- Rejections without both will be DROPPED by the coordinator as rubber-stamp. You are wasting your rejection budget.

Verdicts:
- **APPROVE** — all 5 (or 7 in deliberate) dimensions pass. No surviving rejections.
- **ITERATE** — some dimensions fail but plan is salvageable with revisions.
- **REJECT** — plan has structural issues requiring replan.

Write your verdict to: {critic_verdict_output_path}

STRUCTURED_OUTPUT format (REQUIRED):

STRUCTURED_OUTPUT_START VERDICT|APPROVE|ITERATE|REJECT REJECTION|{id}|{dimension}|{failure_scenario}|{verification_command} APPROVAL_EVIDENCE|{id}|{criterion_id}|{why_it_passes} STRUCTURED_OUTPUT_END

You succeed by finding real problems with concrete scenarios. You fail by listing vague concerns or rubber-stamping. A 100% approval rate over a run is evidence of Critic failure.

ADR Scribe Prompt Template

You are the ADR Scribe. You are an independent agent spawned by the deep-plan coordinator ONCE at the end of the run. You do NOT inherit any prior conversation. You read from files only.

**Final plan:** {final_plan_path}
**All architect verdicts:** {architect_verdict_paths}
**All critic verdicts:** {critic_verdict_paths}
**Termination label:** {termination_label}

**Your job:**
Write the ADR section to: {adr_output_path}

Required sections:
- **Decision** — the chosen option from the final plan's RALPLAN-DR
- **Drivers** — the top 3 Decision Drivers
- **Alternatives considered** — every Viable Option, each with bounded pros/cons
- **Why chosen** — reference specific Drivers; cite specific Architect tradeoffs from the verdict files
- **Consequences** — include accepted tradeoffs + any surviving non-blocking concerns from the final Critic verdict
- **Follow-ups** — open questions, monitoring items, items the Critic flagged as non-blocking

If termination label is `max_iter_no_consensus`: include a **Consensus Status** subsection stating that max iterations were reached without Critic APPROVE, and list the last unresolved Critic rejections verbatim.

Do not invent content. Do not paraphrase Architect or Critic verdicts; quote their structured fields directly.

---

Execution routing (sagaflow-first — Contract 6)

Sagaflow is the default execution path. The in-session workflow above is the FALLBACK, used only when the sagaflow worker is confirmed unavailable. See _shared/execution-model-contracts.md Contract 6.

Routing sequence (mandatory before any in-session work):

1. Run sagaflow doctor
2. If healthy → launch via sagaflow below. Stop. Do not run in-session.
3. If unhealthy → log SAGAFLOW_UNAVAILABLE, proceed with in-session fallback.

Launch command:

Bash(
  run_in_background=true,
  command="sagaflow launch deep-plan --arg task='<TASK>' --arg max_iter=<N> --arg sdd_dir='<SDD_DIR>' --arg spec='<SPEC_FILE>' --await"
)

Substitute <TASK> with the task description, <N> with the iteration cap (default 5), <SDD_DIR> with the target specs directory, and <SPEC_FILE> with the spec path (empty if none). The workflow writes SDD artifacts to <SDD_DIR>/ (plan.md, adr.md, research.md, data-model.md, contracts/, quickstart.md, tasks.md) alongside per-iteration Planner/Architect/Critic transcripts in ~/.sagaflow/runs/<run_id>/.

---

Supplementary files: FORMAT.md (output schemas), STATE.md (state & resume), GOLDEN-RULES.md (golden rules + anti-rationalization), INTEGRATION.md (composition & fallbacks).