spec-authoring

# Spec Authoring Skill

## Purpose

This skill provides expertise in writing clear, testable, and structured specifications. It activates automatically when the user discusses requirements gathering, feature definitions, user stories, or acceptance criteria. The goal is to produce specification documents that are unambiguous, complete, and directly translatable into implementation tasks.

## When It Activates

The skill is triggered when the conversation involves:

- Drafting or refining a new specification document (`spec.md`)
- Defining functional requirements (FR) or non-functional requirements (NFR)
- Writing user stories or acceptance criteria
- Discussing feature scope, constraints, or success metrics
- Reviewing specification quality or completeness

## Capabilities

### 1. Structured Specification Generation

Generate specifications following a consistent template structure:

- **Overview**: Project context, goals, and scope boundaries
- **Functional Requirements**: Numbered as `FR-001`, `FR-002`, etc.
- **Non-Functional Requirements**: Numbered as `NFR-001`, `NFR-002`, etc.
- **Data Model**: Entity definitions, relationships, and constraints
- **API Contracts**: Endpoint definitions with request/response schemas
- **Success Metrics**: Measurable criteria for feature validation

### 2. Requirement Numbering

All requirements follow a strict numbering convention:

- Functional requirements: `FR-001`, `FR-002`, `FR-003`, ...
- Non-functional requirements: `NFR-001`, `NFR-002`, `NFR-003`, ...
- Each requirement is atomic, testable, and traceable to user stories

### 3. User Story Decomposition

Break down features into user stories using the standard format:

```
As a [role],
I want to [action],
So that [benefit].
```

Each user story is labeled (e.g., `US1`, `US2`) and linked to one or more functional requirements.

### 4. Acceptance Criteria (Given/When/Then)

Every user story includes acceptance criteria in Gherkin-style syntax:

```
Given [precondition],
Wh