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.

aylee a6f5a04 3 files · 1.8 KB Updated

File contents

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.

aylee/agent-os/tree/main/.agents/skills/spec commit a6f5a0477d

Frequently asked questions

npx skillmds@latest add aylee/spec