spec-writer:specs-workflow

What this skill does

# Spec Writer

## Purpose

Guide users through creating complete, unambiguous feature specifications using a discovery-driven process. Unlike traditional requirements gathering that starts with predefined user stories, this skill helps stories emerge naturally from deep problem understanding. The resulting specification is comprehensive enough for implementation without further clarification.

## Core Philosophy

**Stories emerge from discovery, they don't precede it.**

Begin by understanding the problem space. Stories crystallize as understanding deepens through iterative exploration. Stories may split, merge, be added, or be revised as learning progresses—even after being written into the specification.

## When to Use This Skill

Use this skill when the user needs to:

- Transform a feature idea into a detailed specification
- Understand and document a problem before designing solutions
- Develop user stories through structured discovery
- Create implementation-ready requirements documentation
- Guide stakeholders through requirements clarification

## State Management Architecture

### The Compaction Mechanism

SPEC.md serves as the compaction mechanism. As user stories reach full clarity, they graduate from working state into the deliverable specification. STATE.md holds only in-flight work. SPEC.md is a living document—graduated stories can be revised when new information warrants it.

### Discovery Directory Structure

```
discovery/
├── SPEC.md            # Progressive deliverable (mutable)
├── STATE.md           # Working memory (current work)
├── OPEN_QUESTIONS.md  # Current blockers
└── archive/
    ├── DECISIONS.md   # Decision history
    ├── RESEARCH.md    # Research log
    ├── ITERATIONS.md  # Iteration summaries
    └── REVISIONS.md   # Changes to graduated stories
```

## Discovery Process Overview

### Phase 1: Problem Space Exploration

**Goal**: Understand the problem before proposing solutions.

**Activities**:
- Ask open-ended questions about the problem domain
- Research similar solutions and industry patterns
- Identify stakeholders and personas
- Map current state vs. desired state

**Outputs to STATE.md**:
- Problem statement (draft, iteratively refined)
- Identified personas
- Current vs. desired state comparison
- Emerging themes (proto-stories)

**Exit Criteria**:
- Core problem articulated in one paragraph
- Primary personas identified
- At least 2-3 proto-stories emerging from themes

### Phase 2: Story Crystallization

**Goal**: Transform themes into concrete, prioritized user stories.

Proto-stories become real stories when they have:
- A clear actor (persona)
- A clear goal
- A clear value proposition ("so that...")
- Sufficient shape to enable specific questions

**Activities**:
- Propose story candidates from emerged themes
- Collaborate with user to prioritize (P1, P2, P3...)
- Identify dependencies between stories
- Validate stories are independently valuable

**Outputs to STATE.md**:
- Story backlog with priorities
- Story dependency map
- Initial confidence assessment per story

**Exit Criteria**:
- User has agreed on initial story set and priorities
- Each story passes "independently testable" validation
- Ready to deep-dive on P1 story

### Phase 3: Story Development (Iterative)

**Goal**: Develop each story to graduation-ready clarity.

Work through stories by priority while remaining alert to:
- New stories emerging from questions
- Existing stories needing to split
- Stories that should merge
- Cross-cutting concerns affecting multiple stories

**Activities**:
- Deep-dive questions on focused story
- Story-specific research
- Draft acceptance scenarios
- Identify edge cases and requirements
- Validate with user

**Graduation Criteria** (per story):
- 100% confidence on story scope
- All blocking questions resolved
- Acceptance scenarios specific and testable
- Edge cases identified with defined handling
- Requirements extractable
- Success criteria measurable

**Graduation Protocol**:
1. Confirm with user: "Story [X] feels complete. Here's the summary: [brief]. Ready to graduate to SPEC.md?"
2. If yes: Write full story to SPEC.md, update STATE.md
3. Move to next priority story

### Phase 4: Continuous Refinement

**Reality**: Discovery doesn't end when a story graduates.

Later stories may reveal:
- Gaps in earlier stories
- Conflicting requirements
- Shared concerns not previously visible
- Edge cases spanning stories

**Process**:
- Flag when new information affects graduated stories
- Propose revisions to SPEC.md when warranted
- Log all revisions to archive/REVISIONS.md
- Re-confirm with user before modifying graduated work

**Revision Types**:
- **Additive**: New acceptance scenario, edge case, requirement
- **Modificative**: Changing existing scenario or requirement
- **Structural**: Story splits or merges

**All revisions require**:
- User confirmation before changing SPEC.md
- Entry in archive/REVISIONS.md
- Update to affected decision/research references

## Session Start Protocol

### Fresh Start (No existing discovery/)

1. Begin with opening question to understand the problem and identify a feature name:

"Let's build a feature specification together. I'm going to start by understanding the problem space - we'll figure out the user stories together as we go.

Tell me: What problem are you trying to solve? Who experiences this problem, and what does their life look like today without a solution?"

2. Once you understand the problem and have identified an appropriate feature name, use `scripts/init-spec.sh <feature-name> --base-path "${CLAUDE_WORKING_DIRECTORY}"` (Tier 1 Essential) to initialize the discovery/ directory with all required files at the project root. See `references/scripts-tier-1.md` for detailed usage.

3. Continue the discovery process from the project root (discovery/ directory will be created there)

### Resuming (Existing discovery/)

1. Read SPEC.md header + completed story count
2. Read STATE.md (in-flight work)
3. Read OPEN_QUESTIONS.md
4. Report current state:

"We're in Phase [X]. [N] stories completed, working on [Story Y]. [M] blocking questions. Any graduated stories at revision risk: [list]"

**Field Update Rules**: For exhaustive guidance on when to update each field and section, see `references/file-operations.md`.

## Question Management

### Question Categories

Track questions in OPEN_QUESTIONS.md by type using `add-question.py` (Tier 1 Essential):

- **🔴 Blocking**: Prevents progress on current story
- **🟡 Clarifying**: Needed for completeness, not blocking
- **🔵 Research Pending**: Requires investigation
- **🟠 Watching**: May affect graduated stories

Use `resolve-question.py` (Tier 2 Automation) to remove questions when answered.

See `references/scripts-tier-1.md` and `references/scripts-tier-2.md` for details.

### TodoWrite Integration

Use TodoWrite to track:
- Current phase
- Blocking questions for active story
- Emerging stories needing investigation
- Watching items (graduated story risks)
- Ready actions (stories ready to graduate)

## Rules of Engagement

- **Problem before solution** - Understand problem space before structuring stories
- **Stories emerge** - Let them crystallize from understanding, don't assign them
- **Stories are mutable** - Even graduated work can be revised with new information
- **Graduation is not forever** - Flag and revise when later discovery reveals gaps
- **Always confirm changes** - Never modify SPEC.md without user approval
- **Track everything** - Log decisions, research, revisions
- **Quantify everything** - Replace vague terms with specific numbers ("fast" → "under 200ms", "many" → "up to 10,000")
- **Challenge assumptions** - Question both your assumptions and the user's

## Completion Criteria

The specification is complete when:

- All identified stories graduated to SPEC.md
- No proto-stories remain in STATE.md
- OPEN_QUESTIONS.md is empty (including Watching list)
- All cross-cutting concerns addressed