Turn vague intent into a precise, executable specification.
SkillScore74Maintained
Automatic
◆Product Management pack
Last verified 8/4/2026
What it changes
Passed 14 of 19 test cases with the skill, and 4 of 19 without it.
Without skill22%
With skill74%
Checks it passed that the model alone missed
Includes a failure mode analysis table.
States that the Out of Scope section is mandatory.
Mentions updating the registry in `.specs/index.md`.
and 14 more in the full report
12 fixed5 passed either way6 still failing0 broke
Pass-rate lift
+52 pp
Tokens
+396%
Agent turns
0%
Response time
-1%
Model gemini-3.6-flashMeasured 8/4/2026v117 of 23 cases passed with skill · 19 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 12 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 12
Prompt
What quality score status statement should be displayed if a spec scores 9 out of 10 on the internal rubric?
What was checked, without and with the skill
Checked
Without skill
With skill
Indicates that a score of 9 out of 10 means the spec is ready for engineering handoff without changes.
Missed
Passed
case-20 · gemini-3.6-flash · 8/4/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md768 linessingle file
Spec Author Skill
Purpose
Transform raw, incomplete, or ambiguous product ideas into structured, implementation-ready specifications. A good spec eliminates the guesswork from engineering, surfaces hidden constraints before coding begins, and creates a shared contract between product, design, and engineering.
This skill operates across five sequential phases: Why → Scope → Technical → Draft → File.
Do not skip phases. Do not generate a spec from the first message alone. The quality of the output depends entirely on the discipline of the process.
Trigger Conditions
Invoke this skill when the user says any of the following (or close variants):
"spec this out"
"write a spec for…"
"turn this into a ticket"
"make this a GitHub issue"
"file a backlog item"
"write up a technical requirement"
"I have an idea, help me think it through"
"what do we need to build for…"
"write implementation-ready docs for…"
"draft a feature proposal"
"write acceptance criteria for…"
Core Principles
Intent over literal request. What the user said is often different from what they meant. Your job is to surface the difference before writing a single word of spec.
Read before you write. Never author a technical spec without first reading the relevant code. Specs that ignore existing implementation details are fiction, not engineering.
Quality is a gate, not a goal. A spec that scores below 7/10 on the internal quality rubric must not be filed or handed to engineering. Revise until it passes.
Scope is sacred. Every spec must have an explicit "Out of Scope" section. Undefined boundaries are debt accrued before a line of code is written.
Acceptance criteria are testable, not descriptive. "The page should look good" is not an acceptance criterion. "The page renders within 200ms at P95 under 100 concurrent users" is.