| name | spec-writerspecs-workflow |
| description | This skill should be used when the user asks to "create a spec", "write a specification", "create a feature specification", "build a requirements document", "gather requirements", "develop user stories", "start discovery process", or mentions needing help with requirements analysis or product specification. Guides users through a structured discovery process where stories emerge from problem understanding rather than being predefined. Use when this capability is needed. |
| metadata | {"author":"aaronbassett"} |
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:
- Confirm with user: "Story [X] feels complete. Here's the summary: [brief]. Ready to graduate to SPEC.md?"
- If yes: Write full story to SPEC.md, update STATE.md
- 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/)
- 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?"
-
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.
-
Continue the discovery process from the project root (discovery/ directory will be created there)
Resuming (Existing discovery/)
- Read SPEC.md header + completed story count
- Read STATE.md (in-flight work)
- Read OPEN_QUESTIONS.md
- 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
- User confirms: "This spec captures everything"
Final Deliverable Check
Before marking complete, verify:
Context Recovery
Standard Resume
- Read SPEC.md header + story status markers
- Read STATE.md
- Read OPEN_QUESTIONS.md
- Report current state and continue
User Asks About Completed Story
- Read that story section from SPEC.md
- If context needed, search archive files
User Wants to Restart or Revise
- Confirm: "Do you want to revise specific stories, or restart discovery entirely?"
- If restart: Archive current files, begin fresh
- If revise: Identify what to reconsider, move back to appropriate phase
Additional Resources
Reference Files
For detailed templates and formats:
references/file-templates.md - Manual operations reference showing what sections you must write manually vs what scripts handle. Focus on Problem Understanding, In-Progress Story Detail, and manual metadata updates.references/file-operations.md - Exhaustive field-level update rules, sync checkpoints, and cross-file consistency invariants. Reference when updating files to ensure all required fields are updated and cross-references maintained.references/phase-guide.md - Comprehensive phase-by-phase guidance with questioning strategies, research approaches, and transition criteria
Example Files
Working examples in examples/:
examples/sample-spec/ - Complete example specification showing the discovery process from problem exploration through graduated stories
Helper Scripts
The spec-writer skill includes 14 automation scripts in scripts/ organized in four tiers by functionality.
Script Organization:
- Tier 1: Essential Scripts (6 scripts) - Initialization, question management, decision logging, validation
- Tier 2: High-Value Automation (4 scripts) - Story graduation, status updates, research search
- Tier 3: Enhancement Scripts (3 scripts) - Research logging, revisions, status monitoring
- Tier 4: Specialized Tables (3 scripts) - Edge cases, requirements, success criteria
Quick Start:
scripts/init-spec.sh payment-flow-redesign --base-path "${CLAUDE_WORKING_DIRECTORY}"
scripts/add-question.py \
--question "Who are the primary users?" \
--category clarifying
scripts/log-decision.py \
--title "Use REST API" \
--context "Need API protocol" \
--decision "REST with JSON" \
--stories "Story 1, Story 2"
scripts/find-decisions.py --story 1
scripts/validate-spec.py
Smart Directory Discovery: All scripts automatically locate discovery/ directory using:
- Explicit
--discovery-path flag
- Current directory if in
discovery/
- Auto-locate in parent directories
Script Reference Documentation:
Read the appropriate tier reference based on your current task:
-
references/scripts-tier-1.md - Read when: starting new spec, adding questions, logging decisions, finding past decisions, validating spec integrity
- init-spec.sh, next-id.py, add-question.py, find-decisions.py, log-decision.py, validate-spec.py
-
references/scripts-tier-2.md - Read when: graduating stories to SPEC.md, changing story status, resolving questions, searching research log
- graduate-story.py, update-story-status.py, resolve-question.py, find-research.py
-
references/scripts-tier-3.md - Read when: logging research findings, recording revisions to graduated stories, getting quick status overview
- log-research.py, add-revision.py, story-status.sh
-
references/scripts-tier-4.md - Read when: adding edge cases, extracting functional requirements, defining success criteria
- add-edge-case.py, add-functional-requirement.py, add-success-criteria.py
Progressive Reading: Start with Tier 1 for basic operations, read higher tiers only when needed for specific tasks.
When to Use Scripts
The 16 automation scripts are organized into 4 tiers by functionality and use case. Use this quick reference to find the right script and its documentation.
Quick Reference: Task → Tier
| Task | Tier | Key Scripts | Reference |
|---|
| Starting a new spec | 1 | init-spec.sh | scripts-tier-1.md |
| Adding questions | 1 | add-question.py | scripts-tier-1.md |
| Logging decisions | 1 | log-decision.py | scripts-tier-1.md |
| Finding decisions | 1 | find-decisions.py | scripts-tier-1.md |
| Validating spec | 1 | validate-spec.py | scripts-tier-1.md |
| Graduating stories | 2 | graduate-story.py | scripts-tier-2.md |
| Changing story status | 2 | update-story-status.py | scripts-tier-2.md |
| Resolving questions | 2 | resolve-question.py | scripts-tier-2.md |
| Finding research | 2 | find-research.py | scripts-tier-2.md |
| Logging research | 3 | log-research.py | scripts-tier-3.md |
| Recording revisions | 3 | add-revision.py | scripts-tier-3.md |
| Logging iterations | 3 | log-iteration.py | scripts-tier-3.md |
| Finding iterations | 3 | find-iterations.py | scripts-tier-3.md |
| Status overview | 3 | story-status.sh | scripts-tier-3.md |
| Adding edge cases | 4 | add-edge-case.py | scripts-tier-4.md |
| Adding requirements | 4 | add-functional-requirement.py | scripts-tier-4.md |
| Adding success criteria | 4 | add-success-criteria.py | scripts-tier-4.md |
Tier Documentation
Read the appropriate tier reference based on your current task:
-
Tier 1: Essential Scripts — references/scripts-tier-1.md
Read when: starting new spec, adding questions, logging decisions, finding past decisions, validating spec integrity
Core scripts for initialization and basic discovery operations.
-
Tier 2: High-Value Automation — references/scripts-tier-2.md
Read when: graduating stories to SPEC.md, changing story status, resolving questions, searching research log
Advanced workflow automation for story lifecycle management.
-
Tier 3: Enhancement Scripts — references/scripts-tier-3.md
Read when: logging research findings, recording revisions to graduated stories, logging iteration summaries, getting quick status overview
Support scripts for research, revisions, iteration tracking, and monitoring.
-
Tier 4: Specialized Tables — references/scripts-tier-4.md
Read when: adding edge cases, extracting functional requirements, defining success criteria
Scripts for managing SPEC.md requirement tables.
Progressive Reading Strategy:
- Start with Tier 1 for basic operations
- Read higher tiers only when needed for specific tasks
- Each tier reference includes complete usage examples and workflow patterns
Implementation Approach
Phase Transitions
Monitor for transition signals:
- Phase 1 → 2: Problem statement clear, personas identified, proto-stories emerging
- Phase 2 → 3: Story backlog confirmed, priorities agreed, ready to deep-dive
- Phase 3 → 4: First story graduates (automatic—always in refinement mode afterward)
- Phase 4 → Complete: All stories graduated, no open questions, user confirms completeness
Story Development Workflow
For each story (in priority order):
- Update status - Use
update-story-status.py (Tier 2) to mark story as "In Progress"
- Deep-dive questions - Track with
add-question.py (Tier 1)
- Research - Log findings with
log-research.py (Tier 3)
- Draft and validate - Extract requirements with Tier 4 scripts
- Check graduation criteria - All blockers resolved? Testable? Complete?
- Graduate - Use
graduate-story.py (Tier 2) to move to SPEC.md
- Validate - Run
validate-spec.py (Tier 1) to check integrity
- Log iteration - Use
log-iteration.py (Tier 3) after completing story cycle
See appropriate tier references for detailed usage. For graduation field updates and sync rules, see references/file-operations.md.
Stay alert for:
- New stories emerging (add to backlog, discuss priority)
- Stories needing to split (too complex)
- Stories needing to merge (too coupled)
- Questions affecting graduated stories (add to Watching list)
Revision Management
When new information affects graduated stories:
- Flag immediately: "This answer suggests we may need to revise Story 1. Specifically: [what might change]"
- Ask user: "Should I proceed with this revision, or do you want to discuss first?"
- If approved:
- Log revision with
add-revision.py (Tier 3 Enhancement)
- Update SPEC.md manually
- Update affected requirements/edge cases with Tier 4 scripts if needed
- Update cross-references and validate with
validate-spec.py (Tier 1)
For revision field updates and sync rules, see references/file-operations.md. For revision logging script details, see references/scripts-tier-3.md.
Best Practices
- Begin each session by checking for existing discovery/ directory
- Use STATE.md as working memory, SPEC.md as graduated deliverable
- Track all questions in OPEN_QUESTIONS.md for visibility
- Log decisions and research in archive files for traceability
- Update STATE.md frequently to reflect current understanding
- Graduate stories only when 100% confident
- Flag potential revisions to graduated stories proactively
- Quantify all vague terms in requirements and success criteria
- Challenge assumptions respectfully but firmly
- Maintain story independence for testability
Start by checking if discovery/SPEC.md exists, then follow the appropriate protocol (fresh start or resume). Guide the user through discovery with patience, using questions to deepen understanding rather than rushing to document preconceived stories.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
