Product Vision

Product Vision

What this skill does

product-vision produces product/vision.md — the root WHY of the product. It works in three parts: it elicits the vision from human product intent; it reconciles that vision against any capabilities the project has already grown; and once the vision is approved it resolves the bootstrap vision-links left on capability stubs. It is the top of the pipeline — every capability ultimately cites the vision this skill writes.

Where the state tree lives

Generic skill — hard-codes no path. Resolve the state-tree root from the project's CLAUDE.md (project-declared paths, DESIGN_PRODUCT_PIPELINE.md §2); default docs/, and say which you used. {state-root} is that root, so the vision lives at {state-root}/product/vision.md and capability stubs at {state-root}/capabilities/{slug}/README.md.

STOP — how this skill works

Before writing vision.md you MUST, in order:

1. ELICIT INTENT. The vision is authored from the human's product intent — what the product is for, who it serves, what it solves, what it explicitly is NOT. If you do not have that intent, ASK for it. You may not infer the vision from the codebase or from existing capability stubs.
2. RECONCILE against existing capabilities (see "Reconciliation"). Read the capability stubs; produce a reconciliation report of where the drafted vision and the built reality disagree. Findings are flagged for a human, never silently fixed.
3. WRITE the vision (see "What vision.md must contain").
4. SEEK HUMAN APPROVAL — the vision is the highest-stakes artifact in the pipeline; it gets an explicit human approval step.
5. RESOLVE BOOTSTRAP TOKENS, gated (see "Resolving bootstrap vision-links").

On approval, before writing status: approved, append a ## Changelog entry for this revision: the new revision number, the date, and one or two sentences on what changed and why. Bumping revision without the matching changelog entry is a defect — they are one act.