When this skill applies
This skill is invoked when:
- •The user explicitly calls
/spec-refine - •The user makes comments about a spec file (e.g., "change the acceptance criteria", "add a step for...", "what about edge case X?")
- •The user is discussing a spec and provides feedback or suggestions
Important: If a spec file contains a reference to /spec-refine, treat any user comments about that spec as refinement requests - no need for the user to explicitly invoke the skill.
Spec structure
When refining a feature spec, ensure it follows this structure:
1. Problem Statement
- •What problem does this solve?
- •Who is affected?
- •What happens if we don't solve it?
2. Proposed Solution
- •High-level description of the approach
- •Key user-facing behavior changes
3. Acceptance Criteria
Write clear, testable criteria:
- • Given [context], when [action], then [result]
- • ...
4. Technical Design
- •Components/modules affected
- •New interfaces or APIs needed
- •Data flow changes
5. Dependencies & Risks
- •External dependencies
- •Breaking changes
- •Edge cases to handle
6. Out of Scope
Explicitly list what this does NOT include to prevent scope creep.
7. Implementation Steps
Ordered list of discrete, mergeable chunks:
- •Step one (what it delivers)
- •Step two (what it delivers) ...
Process
- •If the feature request is ambiguous, ask clarifying questions upfront (batch them together)
- •Research the codebase to understand existing patterns
- •Draft or update the spec
- •Make all changes directly - do NOT ask for confirmation on individual edits
- •Present the final spec to the user for review
Key points
- •Do NOT ask for confirmation on every change - make edits directly and show the result
- •Batch clarifying questions together rather than asking one at a time
- •If the user provides feedback, apply it immediately without asking "should I update this?"
- •Only ask for final approval once the spec is complete