team-plan

The second half of the debate workflow. team-debate decides what; team-plan produces the how — a reviewed implementation plan grounded in that decision.

REQUIRED BACKGROUND: follow team-protocol for dispatch, writers, the run folder, the agent contract, counting positions, the bridge, structural choices, the handoff, execution and weakened checks. Its run-folder copy (team-protocol § Dispatch) leaves out the roles/ glob: this skill has no roles.

Preconditions

• A resolved decision: read the most recent (or user-specified) file in .council/decisions/YYYY-MM-DD-<topic>.md. If none exists, no debate has run — stop and point the user to team-debate first.
• Project profile: read .council/project-profile.md. If it is missing, run team-scan at once, announced in one line.

Flow

Load decision + profile
        ↓
Settle open questions and human-only inputs
        ↓
Draft plan (the profile's planning skill conventions, if any); keystone first
        ↓
Role review (parallel): CTO (technical soundness, sequencing, risk) + system sketch
                        PO  (scope, value, priority ordering)
                        UX  (when a user sees a change) + screen mockup
                        + any specialist the decision implicates
        ↓
Reconcile review feedback → revised plan
        ↓
Reachability: every `unverified` premise checked; unreachable risks → Settled
        ↓
Write draft to <Plan location>/YYYY-MM-DD-<topic>.md (profile's Run preferences)
        ↓
Present plan to human → approved: remove Status: draft, hand off

1. Load context

Read the decision file and the profile. The Debate Summary and the human's decisions are what the plan needs; the rest of the record is archive. Extract the accepted direction, the record's ## Constraints and ## Accepted trade-offs (they, not the PO's prose, say what binds and what was accepted, and by whom), the profile's standing constraints (its ## Constraints), any dissenting views worth guarding against, and the summary's Structural choices: the settled ones go into the plan's Structure as "the decision", the ones left to the plan are settled in § 1b. A record without those two sections (written before they existed): the plan's Constraints says "none recorded" for the record and still lists the profile's standing ones, and § 1b asks the user whether any binds; its Accepted Trade-offs quotes the PO Recommendation, marked as such.

1b. Settle before drafting

Writers type in a settled design. Before any draft, list:

• Open design questions: what the decision leaves open that would change the plan's shape (which path a call takes, where a type lives, whether two entry points share one route). Settle each with the user (AskUserQuestion, a recommendation first), or with a spike agent that writes its numbers into the brief. A spike answers a fact; a choice it opens that the user will see goes to the human (team-protocol § Structural choices).
• Structural choices (team-protocol § Structural choices) the plan would make and the decision does not: each is settled as above and recorded in the plan's Structure. One whose rule later work could break is also a constraint (bridge.md § Structural choices and constraints): it gets the next K<n> id, on its Structure line and in the plan's Constraints, source <plan path>, Structure.
• Human-only inputs: captures, probes, credentials, measurements on the user's machine. Human-only inputs include what the profile's ## Environment limits says the sandbox cannot run. Collect them now. A writer that needs one waits for it, never guesses it.
• Unobserved facts: when the plan rests on what the code does today, one evidence-pass agent gathers them first (agent id evidence), with the lifecycle map of each entity whose states the plan touches (reachability.md § Lifecycle map); the debate's map in the decision's sources, when there is one, is its start.
• A constraint found while planning (by a spike, the evidence pass or a reviewer): never folded silently into the plan. It goes on the plan gate as a decision (templates.md § Gate page), like a reverses debate D<n> option.

2. Draft the plan

Writers produce a step-by-step implementation plan in the project's plan format, or the conventions of the planning skill the profile's Process domain lists, or else templates.md § Plan. The plan implements the debate's chosen direction; it does not relitigate it.

Writers and fixers write the plan files in the profile's Run preferences Plan location folder (.council/plans/ when the line is missing), as YYYY-MM-DD-<topic>.md, sub-plans beside it, not in the run folder: that path replaces the run-folder line of team-protocol § Agent contract. Agent ids: evidence, spike-<n>, index, plan-<part>, fix-<part>, review-<role>, reach, gate, record.

A plan that fits one file is drafted by one writer. A plan large enough to split into sub-plans splits along interfaces, in this order:

1. The index (one writer): the sub-plans, their order, and the cross-plan contract: every name, signature, id and type one sub-plan exports and another uses.
2. The keystone sub-plan (the one the others build on), written against that contract. Its Interfaces block is then frozen.
3. The consumers, in parallel, each given the frozen contract, never a guess at it.

A writer that needs to change the contract stops and reports. A fresh fix-index writer amends the contract and the keystone before any consumer adapts.

3. Role review (parallel)

Dispatch the reviewers by templates.md § Review: CTO and PO always, UX whenever the plan changes something a user sees, and an ad-hoc specialist when the decision implicates another domain (write it 3–5 tests, no names, team-protocol). Each gets the copy of bridge.md, and the CTO and UX also the copies of contract.md and figures.md for their sketches.

4. Reconcile

Fold review feedback into a revised plan. One fixer per round takes every defect at once and writes the amendment's line under ## Plan gate in the decision record. Its brief adds: "Add nothing unasked; list your own additions first." Before the approval pass, one consolidation pass deletes superseded rules and their references. Where a reviewer's concern conflicts with the debate's accepted trade-off, keep the decision and pass the concern to the gate writer: it goes in the against of the step or risk it concerns, or becomes a minor item (templates.md § Gate page).

Before the gate writer, check every unverified premise in the review files by reachability.md § Reachability check (agent id reach); the gate writer gets its file.

5. Approve & write

The revised plan sits at the plan location of step 2, with Status: draft and the source decision's path at the top.

REQUIRED SUB-SKILL: team-view. The gate writer builds and renders the page by templates.md § Gate page; you serve it and read the decisions block.

Declines or notes → revise by § 4 and re-render.

The human amends the decision at the gate (picks a reverses debate D<n> option, or says so in a note):

1. No fixer ran, so a record writer (sonnet, ~8) writes that ## Plan gate line: the item, the new direction, the human's words.
2. Revise only the sub-plans or steps it changes.
3. One CTO reviewer (sonnet, ~10) checks the changed steps.
4. Re-gate only those steps. An amendment merges into the gate while it is unanswered; -r<N> only for a gate already answered (<topic>-plan-r<N>.gate.json; the earlier .decisions.txt stays on record).

On full approval, a record writer adds the constraints born in § 1b to the decision record's ## Constraints (source <plan path>, Structure); records each (lifts K<n>) of the plan gate's decisions as K<n> lifted by the human, <their words> and marks a lifted KS<n> line of the profile lifted by <record path>; adds each constraint found while planning that the human kept (confirmed, source <plan path>, the next free K<n> id); and appends every new tech constraint, from the debate gate or § 1b or kept at the plan gate, to the profile's ## Constraints with the next free KS<n> id (team-scan), unless the rule is already listed there, lifted by ones included. Then remove Status: draft and hand off (team-protocol § Handoff) with the prompt execute <plan path> with team-plan, or with <the project's own workflow> when Execution says so. Execution starts from the plan file, not from a context holding the planning.

Execution

Planning sessions never implement. The executing session, opened by the handoff, executes from the plan file by team-protocol § Execution. A plan-execution skill from a plugin (e.g. superpowers:subagent-driven-development) runs only when the human asks for it by name, even if the profile's Process domain lists it: it sends review findings back to the same implementer and reviews every task twice, so each round re-reads a growing context. The project's own execution workflow (its CLAUDE.md, or a skill in its .claude/skills/) takes precedence over both; it follows the plan's Execution economy.

Rules of this skill's own, on top of team-protocol § Execution:

1. Batch as the plan's Execution economy says; a plan without one batches by team-protocol § Execution. Executors run on sonnet, opus for a design-heavy step. Each gets its batch's steps and the plan's Goal and Outcome, never the decision record.
2. The executor writes a failing test first when a step changes behavior, commits each step on its own, and replies with one line per step: commit hash, blocked — <reason>, or stopped — <the diff guard's hit>.
3. After each batch, run the Verification commands yourself. Red → one fresh executor gets the failure output, the batch's steps and their commits, and fixes it as a fixup! of the step at fault. Still red → stop and ask the human. Never resume the batch's executor.
4. Last, the final reviewer (opus) reads the full diff against the plan: nothing smuggled in, nothing dropped, the Outcome reached, no check weakened (team-protocol § Weakened checks). Its fix findings go to fresh executors as fixup! commits (team-protocol § Execution).

Whichever path ran, offer, never impose, team-review on the executed diff, as a review of your own branch: the final reviewer checks conformance to the plan, not correctness or security. Its Recon takes this plan and the decision record as the intent.

Set Status: executed on the plan when done.

Rationalizations

The shared ones are in team-protocol. These are the planner's own.

Red Flags

• A step that traces to nothing in the decision
• A step that makes a structural choice neither the decision nor the plan's Structure settled
• A consumer writer dispatched before the contract it codes against is frozen
• A writer guessing a human-only input (a capture, a probe result)
• An amended step re-gated without a review
• A reviewer concern that is in neither the revised plan nor the gate (an against, a minor item or a tension)
• An accepted trade-off overridden without a note
• A step that exceeds an accepted trade-off (a second copy where one was accepted)
• A step that breaks a constraint of the plan's Constraints with no gate decision
• Code written during planning