# Spec

> Write or revise a decision-complete product specification. Use when the user asks to define the behavior, requirements, state, failure modes, or acceptance criteria for a feature or workflow; use brief for stakeholder framing rather than implementation-ready detail.

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

---

<!-- Generated from .agents/skills/spec/SKILL.md; source-sha256: e8bdbdc53bba677ebb568a639e64d4000105442cb4a573d0a7f81e3271223d7a. -->


# Product spec

1. Read the owner binder, active workstream, relevant research and decisions, and `library/templates/spec.md`.
2. Establish user problem, audience, desired outcome, success measures, constraints, non-goals, and current behavior.
3. Specify behavior, primary flows, interfaces, state changes, failure modes, and acceptance criteria at implementation-ready depth.
4. Resolve material ambiguity or mark it as an owned open decision. Use `$grill` when a decision tree remains broad.
5. Write new specs in the owner binder and revise existing specs in place. Keep execution plans and chronological logs out of the spec.
6. Link the artifact from the workstream when it affects active work. Do not create a receipt for the spec edit.

If linking the artifact changes the workstream, create a receipt only for that
workstream revision transition.

Do not invent analytics, customer evidence, technical constraints, or rollout promises.