Templates reference

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

Getting Started

Configuration

Polyrepo & Monorepo

Skills

Reference

Contributing

Templates reference

`context.md` → `feature-context`

`plan.md` → `feature-plan`

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

`product.md` → `product-context`

`repair.md` → `feature-repair`

​context.md → feature-context

​plan.md → feature-plan

​pr-body.md → feature-pr

​product.md → product-context

​repair.md → feature-repair

`context.md` → `feature-context`

`plan.md` → `feature-plan`

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

`product.md` → `product-context`

`repair.md` → `feature-repair`