Master Plan Synthesis

Synthesize the expert reports into a single, code-grounded plan the user can audit in one sitting. Runs in the main session (no subagent dispatch); the orchestrator does the consolidation directly because the expert reports already live in conversation context.

Required Inputs

• Every expert report from the most recent /forge:expert-analysis run, present in the conversation transcript. On the standard path these are markdown reports parsed by heading; on the deep-mode path they are structured JSON objects from the Workflow result — the fields map one-to-one onto the report headings, and the synthesis procedure below is identical for both.
• The original feature requirements as the user expressed them.
• Optional: any user clarifications since the experts were dispatched.

What to produce

A single markdown plan inside the conversation, capped at ≤ 80 lines for typical features (1–3 steps; ≤ 120 lines for 4–5 steps). The plan has four sections, in this order: Feature, Steps, Risks, Open questions. An optional Integration contract appendix is appended ONLY when the plan has ≥ 2 steps marked Parallel-friendly: yes.

For the full template with field-by-field guidance, see references/plan-structure.md.

Synthesis procedure

1. Cluster the steps. Each step is a bounded edit a reader can hold in their head. 1 step is fine for focused changes; 5 is the practical ceiling. Cluster by what belongs together, NOT by parallelism — disjointness is the Parallel-friendly annotation's job, not the step boundary's.
2. Write step descriptions as prose. 2–4 sentences naming what gets built, against which existing patterns (cite file:line), and the order if it matters. NO numbered substeps, NO inline pseudocode, NO code snippets.
3. Reconcile citations. Every file:line cited by any expert appears in exactly one step's "Files touched" list. If two experts cite the same line with conflicting interpretations, MUST invoke Read on the file and resolve by reading the code yourself.
4. Triage risks ruthlessly. A risk has the shape: "if this mitigation goes wrong, the user observes <symptom>." Cap at 3. One-line code fixes (clamps, sort tie-breaks, exclusion sets) are NOT risks — fold them into the relevant step's description as a sentence and drop the row.
5. Triage open questions ruthlessly. Only items the user must decide. If you have a recommendation, write it as a stated decision in the relevant step's description and drop the row. Empty Open questions section is fine and common.
6. Annotate `Parallel-friendly: yes` only when honest. A step gets the annotation ONLY if its "Files touched" set is genuinely disjoint from every other step's AND its description has no ordering dependency. Default: omit the line entirely.
7. Emit the Integration-contract appendix only when ≥ 2 steps are `Parallel-friendly: yes`. Otherwise omit the appendix entirely; contract details fold inline into the relevant step's description (e.g. "subscribe to the dispatcher at Foo.cs:120, signature void Handle(Bar)"). For in-session implementation, the inline form is sufficient.

Critical Constraints

• Hard size cap: ≤ 80 lines for typical 1–3 step features; ≤ 120 lines for 4–5 step features. If you exceed this, you've leaked implementation work into the plan. Cut prose, drop one-line-mitigation risks, fold Open questions with recommendations into stated decisions.
• NEVER write the plan to disk. Per workflow design, the plan lives in conversation context until /forge:plan-revise finishes.
• NEVER preserve a Risk row whose mitigation is a one-line code edit. Those are implementation details. The Risks section is for failure modes the implementer or critic could realistically miss.
• NEVER preserve an Open question with a recommendation attached. If you have an answer, write the answer into the relevant step's description and drop the question.
• NEVER write step descriptions as pseudocode. If your description has numbered substeps, code snippets, or branching logic, you're writing the implementation in the plan. Cut to prose.
• NEVER emit the Integration-contract appendix for a single-step or sequential plan. It is not load-bearing in those cases and just bloats the audit surface.
• Cite `file:line` on every claim. Plans without citations fail the critic and the implementer cannot verify against the code.

Next Step

After the plan is in the conversation, invoke /forge:critic-review to dispatch the adversarial critic against it.

Additional resources

• For the full plan template with field-by-field guidance, see references/plan-structure.md