# Spec

> DEPRECATED — use `deep-design --spec` instead. Turns a conversation, idea, or discussion into an SDD-compatible spec.md. Use when the user asks to write a spec, technical spec, design doc, RFC, API design, data model, spec this out, turn this into a spec, write up the design, document this, implementation spec, spec for this feature.

- Skill: `npow/spec` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add npow/spec`
- Raw SKILL.md: https://api.skillmd.com/api/skills/npow/spec/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: npow (https://skillmd.com/u/npow)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/npow/spec

---


# Spec

> **DEPRECATED**: This skill is now a thin wrapper around `deep-design --spec`. The standalone `spec` skill is maintained for backwards compatibility but all new development happens in deep-design.

## Routing

When invoked, this skill delegates to `deep-design --spec`:
- If `deep-design` is available: invoke it with `--spec` flag and pass through the argument.
- If not available: fall back to the inline workflow below.

## SDD-Compatible Output

The spec is written as `specs/{NNN-feature-name}/spec.md` following the Spec-Driven Development format:

```
specs/{NNN-feature-name}/
├── spec.md              # Feature specification
└── checklists/
    └── requirements.md  # Spec quality validation
```

### Required Sections

- *User Scenarios & Testing* — prioritized user stories (P1, P2, P3) with Given/When/Then acceptance scenarios. Each story must be independently testable.
- *Functional Requirements* — FR-001, FR-002, etc. Each testable and unambiguous.
- *Success Criteria* — SC-001, SC-002, etc. Technology-agnostic, measurable outcomes.
- *Key Entities* — if data is involved (entity, attributes, relationships).
- *Assumptions* — reasonable defaults documented here.
- *Edge Cases* — boundary conditions and error scenarios.

### Spec Quality Rules

- Focus on WHAT and WHY, never HOW. No implementation details (languages, frameworks, APIs).
- Success criteria must be measurable and technology-agnostic.
- Max 3 `[NEEDS CLARIFICATION]` markers (scope > security > UX priority).
- Every requirement must be testable.

## Fallback Workflow

If `deep-design` is unavailable, use this inline workflow:

> **Pace:** Spec authoring is load-bearing design work — choices made here propagate to implementation. Think carefully and step-by-step.

1. **Extract the core idea** — identify what system, feature, or API is being specified.
2. **Ask clarifying questions if needed (batched, max 3)** — present ALL as a single numbered batch.
3. **Create SDD directory** — scan `specs/` for next sequential prefix, create `specs/{NNN-name}/`.
4. **Draft spec.md** — write all required sections following the SDD format above.
5. **Generate checklists/requirements.md** — validate spec quality (no implementation details, testable requirements, measurable criteria, max 3 clarification markers).
6. **Self-correct** — if validation fails, fix and re-validate (max 3 iterations).
7. **Report** — print SDD_DIR path, spec status, and suggested next step (`deep-plan` or `deep-design --spec` for clarification).

## Golden Rules

1. **Problem before design.** Always define what and why before how.
2. **Non-Goals are valuable.** They define the boundary of the work.
3. **Success Criteria are mandatory.** Without measurable criteria there is no definition of done.
4. **Ask at most 3 clarifying questions, batched in one message.**
5. **Spec serves downstream tools.** The spec.md must be consumable by `deep-plan` for plan generation and by `autopilot` for the full SDD workflow.

## Follow-up Skills

| Next Step | Skill | Purpose |
|-----------|-------|---------|
| Clarify ambiguities | `deep-design --spec` | Adversarial stress-testing of the spec |
| Plan implementation | `deep-plan --spec specs/{NNN}/spec.md` | Produce plan.md + tasks.md |
| Build everything | `autopilot` | Full SDD workflow: specify → plan → tasks → implement |