Skip to main content
Invoke: /feature-plan AB#1234 · Side effects: writes plan files, no code · Writes: .shipflow/{id}/plan.md, tasks.md

​
What it does

  1. Reads context.md (never plans from the raw prompt) and the standing context — honoring its conventions and boundaries, and surfacing any unresolved clarifications rather than planning around them.
  2. Explores the code it will actually change — real modules, real entry points, real conventions — so the plan proposes changes that look native, not generic. “Add a validator” isn’t a plan; a named file and function is. Also reads any CLAUDE.md/AGENTS.md/.cursorrules/copilot instructions at each touched repo’s root, alongside product.md, for boundaries and gotchas the code alone won’t show.
  3. Impact analysis — searches for callers/consumers of the surface being changed, notes existing tests that already exercise it, and folds in cross-cutting concerns the repo’s own instructions flag (migrations, feature flags, deploy ordering). Written as its own section in plan.md, not buried in risks.
  4. Polyrepo: commits to which configured repos are actually touched (only repos with real changes get a branch/tests/PR), assigns every task — and thereby every AC — to the repo(s) that satisfy it. See Polyrepo for the full worked example.
  5. Writes the plan: approach, files to touch, impact analysis, risks/unknowns, test strategy, and an AC → task mapping where every AC maps to at least one task and vice versa.
  6. Writes an ordered, checkboxed task list — each task atomic (one conventional commit), tagged with the AC(s) it advances.

​
Honesty

An AC with no plausible task — because it needs a human decision — becomes a clarification, not an invented task. If the real scope turns out bigger than the work item implies, that gets flagged before any code, not discovered mid-implementation.

​
Gate

Gated by governance.gates.after_plan — the orchestrator stops here for you to approve the plan and task breakdown before any code is written.