Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →asymmetric-al/to-spec
Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
6 of 25 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 7 comparable cases; this report requires 8.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
We mapped out adding OAuth2 social login using Google and GitHub. Should the implementation decisions section detail exact file paths like 'src/controllers/authController.ts' and line numbers so developers know where to edit?
| Checked | Without skill | With skill |
|---|---|---|
| Omits file paths and line numbers from the implementation section | Missed | Passed |
The instructions your model reads when the skill loads.
This skill takes the current conversation context and codebase understanding and produces a spec (you may know this document as a PRD). Do NOT interview the user — just synthesize what you already know.
The issue tracker and triage label vocabulary should have been provided to you — run /setup-matt-pocock-skills if not.
Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.
Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.
Check with the user that these seams match their expectations.
ready-for-agent triage label - no need for additional triage.The problem that the user is facing, from the user's perspective.
The solution to the problem, from the user's perspective.
A LONG, numbered list of user stories. Each user story should be in the format of:
This list of user stories should be extremely extensive and cover all aspects of the feature.
A list of implementation decisions that were made. This can include:
test cases passed with the skill
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.