Teamwork Plan
Turn one selected direction into executable work. Do not require a previous
discussion artifact.
Method
- Verify the settled direction against project facts, the full set of goals,
and observable acceptance. If a remaining unknown would change the goal,
direction, or acceptance, return that gap instead of a partial plan.
- Inspect the actual owners, interfaces, dependencies, and nearest useful
verification.
- Organize outcome-sized work in dependency order. Name exact targets and what
each step produces. The first executable step must change the target
artifact or remove an observed mechanical blocker. The critical path holds
only actions that produce the result and their real mechanical
dependencies. Benchmarks, appendices, probes, and extra documents are not
prerequisites just because they help explain.
- Use parallel tracks only when they are independent and non-overlapping.
- Include migration, rollback, compatibility, or risk work only when the chosen
direction actually requires it.
- End with dependencies, verification, and the conditions that require
replanning. When editing any existing plan surface, including a host plan,
keep the stable identity and unaffected content. Default to a local patch.
Rearrange the whole plan only when the user changes the goal or direction.
Do not open a new plan because of added acceptance checks or parallel
concerns.
Return unresolved material choices to the user; do not hide them as assumptions.
Return the executable plan.
Persistence
When a listed checkpoint fires, write in the same response cycle. If separate
stable identities each cross a checkpoint, write each to its own path.
Cross-chat memory lives in one Markdown document from references/plan.md
at docs/teamwork/plans/<slug>.md. Same identity means the same
selected outcome; reuse that path and name the document you read.
A different subject gets a new path. Later edits reuse that path; do not open
a new plan because of added acceptance checks or parallel concerns.
Checkpoints: the direction and scope are accepted (this settles direction
only; it does not create a document for an unaccepted draft); the executable
plan is first settled when that first executable plan is accepted by the
user; a material replan changes steps, dependencies, verification, or stop
conditions only after the user accepts that replan.
1---2name: teamwork-plan3description: Use when the user asks for an implementation plan, task breakdown, checklist, roadmap, or handoff and the outcome and direction are already selected; do not use to choose the direction or execute changes.4---56# Teamwork Plan78Turn one selected direction into executable work. Do not require a previous9discussion artifact.1011## Method12131. Verify the settled direction against project facts, the full set of goals,14 and observable acceptance. If a remaining unknown would change the goal,15 direction, or acceptance, return that gap instead of a partial plan.162. Inspect the actual owners, interfaces, dependencies, and nearest useful17 verification.183. Organize outcome-sized work in dependency order. Name exact targets and what19 each step produces. The first executable step must change the target20 artifact or remove an observed mechanical blocker. The critical path holds21 only actions that produce the result and their real mechanical22 dependencies. Benchmarks, appendices, probes, and extra documents are not23 prerequisites just because they help explain.244. Use parallel tracks only when they are independent and non-overlapping.255. Include migration, rollback, compatibility, or risk work only when the chosen26 direction actually requires it.276. End with dependencies, verification, and the conditions that require28 replanning. When editing any existing plan surface, including a host plan,29 keep the stable identity and unaffected content. Default to a local patch.30 Rearrange the whole plan only when the user changes the goal or direction.31 Do not open a new plan because of added acceptance checks or parallel32 concerns.3334Return unresolved material choices to the user; do not hide them as assumptions.35Return the executable plan.3637## Persistence3839When a listed checkpoint fires, write in the same response cycle. If separate40stable identities each cross a checkpoint, write each to its own path.4142Cross-chat memory lives in one Markdown document from `references/plan.md`43at `docs/teamwork/plans/<slug>.md`. Same identity means the same44selected outcome; reuse that path and name the document you read.45A different subject gets a new path. Later edits reuse that path; do not open46a new plan because of added acceptance checks or parallel concerns.4748Checkpoints: the direction and scope are accepted (this settles direction49only; it does not create a document for an unaccepted draft); the executable50plan is first settled when that first executable plan is accepted by the51user; a material replan changes steps, dependencies, verification, or stop52conditions only after the user accepts that replan.