> ## Documentation Index
> Fetch the complete documentation index at: https://kowshik-93.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# feature-plan (Phase 2)

> A technical plan and task list grounded in your actual code — not a generic description.

<Info>
  **Invoke:** `/feature-plan AB#1234` · **Side effects:** writes plan files, no code · **Writes:**
  `.shipflow/{id}/plan.md`, `tasks.md`
</Info>

## 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](/shipflow/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.