Specify — The WHAT

Produce the master spec: user stories, functional requirements (FRs), non-functional requirements (NFRs), acceptance criteria (ACs), and the micro-spec plan that breaks the feature into dependency-ordered groups of small implementation units. Strictly WHAT — never HOW.

Gate: the feature's design phase must be accepted (else "Accept the design first").

Inputs

• .genesis/project-state.md (mode)
• The constitution
• .genesis/features/<feature>/design.md (required)
• .genesis/features/<feature>/brainstorm-log.md (optional)
• .genesis/design/overview.md and other relevant design docs
• approvals/master.json (verify design accepted)

Process

1. Resolve the feature name; handle an existing/partial spec (revise vs continue vs fresh).
2. Write spec.md from spec-template.md with all 14 sections:
   1. Overview · 2. Design Document References · 3. User Stories · 4. Functional Requirements (FR-001…, RFC-2119 MUST/SHOULD/MAY) · 5. Non-Functional Requirements (NFR-001…) · 6. Acceptance Criteria (AC-001…, EARS form "WHEN {trigger}, THE SYSTEM SHALL {behavior}", each linked to an FR) · 7. Agent Boundaries (Always / Ask First / Never) · 8. Changelog Preview · 9. Out of Scope · 10. Assumptions (A-001…) · 11. Open Questions · 12. Constitution Compliance Check · 13. Micro Spec Plan · 14. Changelog.
3. Section 13 — the Micro Spec Plan: groups ordered by dependency. For each group list its micro specs (ID, title, description, dependencies, size S/M/L/XL); include totals (group count, spec count, critical path). Two safeguards:
   • Shared Infrastructure column — any file touched by 2+ specs gets exactly one owner group responsible for auditing it.
   • Cross-Cutting FRs table — FRs spanning 2+ subsystems (keywords across/between/coordination/handoff) are each assigned to one micro spec at the integration point, so they don't fall through audit cracks.
4. Zero implementation detail — no file paths, function names, endpoints, or schemas. Deferred items go to Out of Scope with a note on which spec they belong in.
5. If the spec depends on other features, write dependencies.json (shape below); skip the file if none.
6. Self-validation pass (up to 3 iterations): catch implementation leaks, vague requirements, missing strength keywords, FRs without ACs, untestable ACs, incomplete user stories, mode mismatch; auto-correct and report.
7. Constitution-compliance check; insert <!-- NEEDS_CLARIFICATION: {question} --> markers for residual ambiguity; recommend /genesis-clarify if any remain. Present; commit; update project-state.md.

Output

• .genesis/features/<feature>/spec.md — the 14-section master spec.
• .genesis/features/<feature>/dependencies.json (when cross-feature deps exist):

  {
    "feature": "<feature-name>",
    "dependencies": [
      { "target_feature": "<other-feature>", "source_ref": "FR-012",
        "type": "blocking|informational",
        "description": "Requires the auth module from <other-feature>", "status": "open" }
    ]
  }

Mode differences

• Greenfield: full technical spec; groups by technical dependency.
• Brownfield: add a Scope Boundary section + per-micro-spec File Operations; FRs carry scope constraints ("MUST modify X without breaking Y"); groups cluster by touched-file impact; Out of Scope lists inherited code that won't change.
• Lowfield: add a Pipeline Table and Artifact Schema section + per-stage Quality Gates; FRs are process capabilities; groups order by pipeline-stage dependency.

Next step

Run /genesis-clarify.

Natural language triggers

- "write the spec"
- "specify this feature"
- "master spec for X"