vc-generate-spec

Output style: Follow process/development-protocols/communication-standards.md — answer-first, plain language, no unexplained jargon, TL;DR on long responses.

Use this skill to produce the authoritative product-discovery SPEC artifact for a task — a plain-language requirements document written for user review, not for an engineer.

A SPEC captures what the user wants and why so the user can read it, recognize their own intent, and confirm "yes, build that" before any approach or code is chosen. It is the bridge between RESEARCH (the facts) and INNOVATE (the how). PLAN cannot start until a SPEC exists for non-trivial work.

SPEC consumes: RESEARCH findings + the user's stated intent/brainstorm. It does NOT consume a chosen approach or a Decision Summary — no approach exists yet at SPEC time.

Normal output is one SPEC file: {slug}_SPEC_{dd-mm-yy}.md.

For a phase program, the program-level (umbrella) SPEC is written once during the outer loop and governs every inner phase. Use templates/program-spec-template.md for that case. The inner loop never writes a SPEC.

Workflow

1. Read references/spec-contract.md for the full section-by-section writing rules.
2. Run date +%d-%m-%y before choosing the filename.
3. Confirm the inputs are present: RESEARCH findings + the user's stated intent. If neither is present, emit SPEC_INTENT_BLOCKED instead of writing.
4. Read process/context/all-context.md first, then load the relevant context group. When the work touches testing/verification, read process/context/tests/all-tests.md so acceptance-criteria scenarios are grounded in the real test-context chain.
5. Save the SPEC inside the task folder alongside the plan: process/features/{feature}/active/{slug}_{date}/{slug}_SPEC_{date}.md (or process/general-plans/active/{slug}_{date}/{slug}_SPEC_{date}.md). For a phase program, the umbrella task folder holds {program-slug}_SPEC_{date}.md. Per task-folder artefact colocation, never write to the deprecated sibling reports/ or references/ dirs.
6. Write the SPEC sections in canonical order (see references/spec-contract.md):
   • ## Summary
   • ## User Stories / Jobs To Be Done
   • ## What The User Wants (Behavioral Outcomes)
   • ## Flow / State Diagram (ASCII)
   • ## Acceptance Criteria (Testable Outcomes) — each criterion carries proven by: + strategy:
   • ## Out Of Scope
   • ## Constraints
   • ## Open Questions
   • ## Background / Research Findings
7. Keep the document oriented for user review: plain language, no file paths, no library names, no schema or code. Anything engineer-only moves to Background or a later phase.
8. Each acceptance criterion MUST be provable by comprehensive tests, with a fully-automated E2E/integration gate wherever the behavior is automatable. Agent-Probe / Known-Gap stand only as an explicitly-justified residual. Vacuous-green is banned.
9. If ## Open Questions is non-empty at finalize (interactive session): emit SPEC_INTENT_BLOCKED and stop. Under /goal: record each as a backlog note and continue.
10. Once Open Questions is empty/"None" (or backlogged under /goal): save the file and the agent emits PHASE_COMPLETE: SPEC.

Important Rules

• The SPEC is written for a human reviewer. If a sentence only makes sense to an engineer, rewrite it or move it to Background.
• Do NOT choose an implementation approach (INNOVATE's job, downstream), write implementation steps (PLAN), make schema decisions, or include code/library references.
• Do NOT modify any file except the SPEC file being created.
• Acceptance-criteria scenarios must be grounded in the RESEARCH test-context-discovery, not invented here.
• Once INNOVATE/PLAN begins the SPEC is frozen — later scope gaps go to the phase report ## SPEC Gaps heading and a backlog note, never an edit to the SPEC.
• For a phase program, write the umbrella SPEC once; the inner loop reads it and never writes a per-phase SPEC.

Required SPEC Sections

Every SPEC file must include all of the following, in this order:

• ## Summary — one plain-language paragraph: what changes for the user and why
• ## User Stories / Jobs To Be Done — the heart of the doc; "As a [user], I want [X], so that [Y]" or JTBD
• ## What The User Wants (Behavioral Outcomes) — observable behavior only, no implementation
• ## Flow / State Diagram — at least one ASCII flow/state diagram
• ## Acceptance Criteria (Testable Outcomes) — observable outcomes, each with proven by: + strategy:; max 20
• ## Out Of Scope — at least one item
• ## Constraints — user-stated, system/process, and technical limits from research
• ## Open Questions — each with an owner; empty/"None" required to finalize (interactive)
• ## Background / Research Findings — key facts from RESEARCH that shaped the requirements

Use Markdown-structured sections, not a second machine-only schema. Markdown sections are stable across all agents (Claude, Codex, future systems) without requiring a parser.