> ## 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.

# Templates reference

> The five render targets the skills fill in — what each section captures.

Templates live in `templates/` and get filled into `.shipflow/{id}/` (or a PR body) by the phase
that owns them. All five ship with `{placeholder}` markers and HTML-comment guidance inline — this
page describes what each section is *for*, not a copy of the placeholder text itself.

## `context.md` → `feature-context`

| Section               | Captures                                                                                     |
| --------------------- | -------------------------------------------------------------------------------------------- |
| Header                | Work item id, provider, state, whether `product.md` was read, likely-touched repos, links    |
| Change type           | New feature (omitted) vs. rework — an ADDED/MODIFIED/REMOVED delta against current behavior  |
| Requirement           | The verbatim description — never paraphrased away                                            |
| Acceptance criteria   | Normalized, numbered `AC1, AC2, …` — table of criterion + how it'll be proven                |
| Local grounding       | Likely code area, conventions to match, test-framework signals, repo instruction files found |
| Per-repo grounding    | Polyrepo only — which repos and why, per repo                                                |
| Clarifications needed | Specific open questions, batched into one round — never resolved by assumption               |
| Link-back             | The reference that must land in commits, PR title, and PR body                               |

## `plan.md` → `feature-plan`

| Section          | Captures                                                                                                                   |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Approach         | The chosen design, grounded in the codebase and `product.md`; rejected alternatives noted                                  |
| Repos touched    | Polyrepo only — which configured repos actually get a branch + PR, and why                                                 |
| Files to touch   | Real paths, each with a one-line reason                                                                                    |
| Impact analysis  | Callers/consumers of the touched surface, existing tests, cross-cutting concerns from `product.md`/`CLAUDE.md`/`AGENTS.md` |
| Tasks → ACs      | Every task tagged with its repo (polyrepo) and the AC(s) it satisfies                                                      |
| Test strategy    | Framework/command and how each AC becomes a test                                                                           |
| Risks / unknowns | Blast radius, migrations, anything that could make the work bigger than it looks                                           |
| Out of scope     | What's explicitly not being done — makes scope creep easy to spot at verify time                                           |

## `pr-body.md` → `feature-pr`

| Section                | Captures                                                                                         |
| ---------------------- | ------------------------------------------------------------------------------------------------ |
| Summary                | What changed in *this* repo and why, with the link-back reference                                |
| Sibling PRs            | Polyrepo only — "Part of `{ref}`" block cross-linking the other touched repos' PRs               |
| Acceptance criteria    | Checklist with each item's verify status; sibling-owned ACs noted with a pointer, not duplicated |
| Tests                  | Command run, pass/fail counts, AC → test traceability                                            |
| Notes for the reviewer | Intentional scope, risks/follow-ups carried from the plan                                        |

## `product.md` → `product-context`

See [Product Context](/shipflow/configuration/product-context) for the full section-by-section breakdown —
domain glossary, architecture & boundaries, conventions, non-negotiables, definition of done,
ownership, and the ratification footer.

## `repair.md` → `feature-repair`

| Section           | Captures                                                                              |
| ----------------- | ------------------------------------------------------------------------------------- |
| Header            | Which NOT READY verdict this repairs, and the attempt number                          |
| Gaps being closed | Only the PARTIAL/MISSING ACs verify cited, with its own evidence copied verbatim      |
| Fix tasks         | Small, one-commit-sized tasks, same "name real paths" discipline as `plan.md`         |
| Out of scope      | Every already-MET AC — explicitly untouched                                           |
| Result            | Filled after the fix loop: repaired ACs, commits, new test result, new verify verdict |