Spec Writer

Critical Rules

• NEVER overwrite an existing spec without reading it first and showing the user what will change
• ALWAYS use Given/When/Then format for acceptance criteria — no exceptions
• ALWAYS start with the minimum viable spec (purpose + 2-3 criteria) before going deeper — progressive disclosure, not interrogation
• WHEN the user's description is vague, ask targeted clarifying questions — do not guess at requirements
• ALWAYS validate the spec file exists after writing it
• NEVER include implementation details in specs — specs describe WHAT, not HOW

Instructions

Step 1: Determine Create or Update

1. IF $ARGUMENTS contains a path to an existing spec file → read it and go to Step 7 (Iteration)
2. IF a spec already exists at specs/<feature-name>.md for the described feature → read it and go to Step 7 (Iteration)
3. OTHERWISE → proceed to Step 2 (Elicit Purpose)