Install any skill in seconds. Free to start, no credit card required.
Get Started Free →mattpocock/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.
5 of 22 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 6 comparable cases; this report requires 8.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
We have provided our tracker configuration and vocabulary. We are ready to draft the spec issue for user avatar uploading. Which triage label should be assigned when publishing the issue to indicate it is ready?
| Checked | Without skill | With skill |
|---|---|---|
| Applies the ready-for-agent triage label. | 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. Do NOT interview the user; just synthesize what you already know.
The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run /setup-matt-pocock-skills.
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.