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