Skip to main content
Invoke: /product-context · Side effects: writes one doc · Writes: product.md only
Full guide: Product Context. In short — this establishes product.md, the durable “what is always true here” doc: domain glossary, architecture boundaries, house-rule conventions, non-negotiables (graded by feature-verify as implicit acceptance criteria), and a baseline definition of done.

​
Bootstrap vs. update

  • Doesn’t exist yet → bootstraps from templates/product.md, grounded in evidence (READMEs, package metadata, the repos in your config, conventions already dominant in your code) — never invented. Genuine unknowns get a “confirm with the team” placeholder instead of a guess.
  • Already exists → an update: changes only what’s asked or clearly stale, bumps the version/last-amended footer, leaves everything still-true untouched.

​
Always presented for ratification

product.md encodes team commitments, so this skill never silently finalizes it — it presents the draft (or the diff, on update) and asks you to ratify, especially the non-negotiables, before setting the version footer.

​
Boundaries

Writes only product.md and its footer. No branch, no feature code, no PR, and it never touches .shipflow/{id}/ per-work-item files — that’s the phase skills’ domain.