/implementation-planning

Purpose

Create the Implementation Plan section for build execution. Run as a sub-agent and return a draft section to the orchestrator; do not write the plan artifact directly.

Required outputs

• Exhaustive file deltas with change type, explicit owner (existing agent/WS), and rationale.
• Workstreams with dependencies, merge points, and explicitly owned files.
• An integration / merge points checklist (what gets integrated, how, and what gates run).
• Enforce the workstream file-ownership rule: each file delta is owned by exactly one workstream until an explicit merge point.
• Phases and tasks mapped to workstreams/owners.
• Evidence-based exit criteria per phase.
• Build-time gates for each phase.
• Test Plan including at least a minimal test matrix (risk -> test type -> where it runs).
• Rollout/Deployment steps (even minimal) and an explicit rollback trigger + rollback steps.
• Draft section content for ## Implementation Plan

Anti-placeholder rule (hard rule)

• Do not use placeholder language like “run smoke tests” or “add gates” without naming:
  • the gate name(s),
  • where they run (CI vs local vs deployed), and
  • the entrypoint/command (or test runner/target) and what “green” means.
• If specifics are truly unknown, convert them into either:
  • an explicit Decision boundary (A/B/C) with a recommended default, OR
  • a DR-backed Defer with an explicit trigger.

Q/A wrapper

• The orchestrator must run the inline Q/A loop to confirm user understanding and agreement on scope, ownership, and gates.

Ownership policy

• Prefer existing agents from the plan's ## Context Snapshot or the user-provided roster.
• If no roster is available, return Questions asking for the available agents/owners before assigning work.
• Do not default all ownership to the user unless the user explicitly requests it.

Parallel workstreams / multi-agent contract (hard rule)

• If the user requests multiple agents or parallel workstreams:
  • Ensure the draft includes an explicit agent roster (names/handles) and assigns ownership for each workstream and file-delta cluster.
  • If the roster is missing, ask a single focused question to obtain it (do not guess).
  • The orchestrator should mirror this roster into ## Context Snapshot (call this out explicitly in Notes if needed).

Sub-agent output contract

Return a single block in this shape:

md
1DraftSection:
2<exact section content for ## Implementation Plan (must include the section header)>
3
4Checklist:
5- <criterion>: Pass | Fail
6
7Questions:
8- <if blocked>
9
10Notes:
11- <optional risks/assumptions/tests updates>

Malformed output handling

• If you cannot produce the exact section header or required fields, return Questions explaining what is missing and leave DraftSection as N/A.

User experience rule (no "go read the plan")

• When asking the user to confirm plan readiness, paste the key parts directly in the chat response:
  • File deltas (owned)
  • Workstreams + owned files + merge points
  • Phase list with exit criteria
  • Test matrix + rollback

Output template (required for PlanTier: Full)

Use this exact structure so the /plan validator can deterministically check executability:

md
1## Implementation Plan
2### Agent roster (required for PlanTier: Full)
3- <agent/owner>: <responsibilities>
4
5### File Deltas (exhaustive) + rationale
6- path/to/file.ext - change type (create/modify/delete) - owner (WSx / agent) - rationale
7
8### Workstreams + merge points
9- WS1: <name>
10  - Owner:
11  - Depends on:
12  - Review gates (named):
13    - G-...
14  - Owns files:
15    - path/to/file.ext
16  - Merge point / integration step:
17
18### Phases + tasks + exit criteria
19#### Phase 1: <name>
20- Owner(s):
21- Depends on:
22- Tasks (by owner):
23  - Owner: <agent>
24    - [ ] Task
25- Exit criteria (evidence):
26- Gates (named):
27  - G-...
28
29### Review gates (named + definitions)
30- G-...:
31  - Where it runs: CI | Local | Deployed
32  - Entry point / command:
33  - Green means:
34
35### Merge points -> required gates
36- MP1: <merge point>
37  - Blocks on:
38    - G-...
39
40### Test Matrix
41- Area/component - risk - test type - where it runs
42
43### Test plan (CI vs deployed)
44- CI:
45  - ...
46- Deployed environment:
47  - ...
48
49### Rollout / Rollback
50- Rollout:
51- Rollback trigger:
52- Rollback steps: