spec— agent skill

Write a specification for: $ARGUMENTS

Follow this workflow:

1. Discovery: ask the user clarifying questions before writing anything. Cover:

• Who - who is the user/audience for this feature?
• What - what exactly should it do? What is the expected behavior?
• Why - what problem does it solve? What is the success metric?
• Constraints - what technical, time, or scope constraints exist?
• Boundaries - what is explicitly out of scope?
• Ask one question at a time, waiting for the answer before asking the next. The list above is the topic checklist to cover across the discovery phase, not a batch to dump in one turn. See rules/communication.md.

1. Draft the spec: based on the answers, write a specification with these sections. Give every acceptance criterion an ID and a check. Prefer test or cmd; use manual only when no command can prove it:

---
branch: <feature branch, filled in when build starts>
---
# Spec: <title>

## Problem Statement
<What problem does this solve and for whom?>

## User Stories
- As a <role>, I want <capability> so that <benefit>

## Acceptance Criteria
- [ ] AC-1: <Specific, testable criterion> | verify: test <file>::<test name>
- [ ] AC-2: <Specific, testable criterion> | verify: cmd <command whose output shows it>
- [ ] AC-3: <Criterion only a person can judge> | verify: manual <steps>

## Seams
- <Where tests exercise the behaviour, chosen highest and fewest>

## Non-Functional Requirements
- Performance: <latency, throughput targets>
- Security: <auth, data handling requirements>
- Accessibility: <WCAG level, specific requirements>

## Technical Constraints
- <Stack, infrastructure, API compatibility requirements>

## Out of Scope
- <Explicitly excluded from this work, each item with the reason it is out>

## Open Questions
- <Anything unresolved that needs a decision>

why-no-hook: skill workflow guidance; each step requires understanding the surrounding context (repo, task shape, prior state).

1. Save: save the spec to .claude/state/specs/YYYY-MM-DD-spec-<topic>.md (review-time: see section note)
2. Review: present the spec to the user. Wait for approval before proceeding to /plan. (review-time: see section note)
3. Iterate: if the user has feedback, update the spec and re-present. Repeat until approved. (review-time: see section note)

Do NOT proceed to planning or implementation until the spec is explicitly approved.