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.From its SKILL.md
npx -y skills add aylee/agent-os --skill specAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.2 KB, 190 tokens by cl100k_base, as published. Nobody here has run it
Product spec
- Read the owner binder, active workstream, relevant research and decisions, and
library/templates/spec.md. - Establish user problem, audience, desired outcome, success measures, constraints, non-goals, and current behavior.
- Specify behavior, primary flows, interfaces, state changes, failure modes, and acceptance criteria at implementation-ready depth.
- Resolve material ambiguity or mark it as an owned open decision. Use
$grillwhen a decision tree remains broad. - Write new specs in the owner binder and revise existing specs in place. Keep execution plans and chronological logs out of the spec.
- 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.
What ships with it: 2 files
556 B alongside SKILL.md
agents/
- agent-os.yaml300 B
- openai.yaml256 B