Turn an existing discussion and codebase knowledge into a specification, then publish it to the project's issue tracker. Organize the problem, user needs, implementation decisions, testing approach, and work excluded from scope.
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.
to-spec creates a specification from the current conversation and knowledge of the codebase, then publishes it to the project's issue tracker. It organizes the user's problem, the solution, needs for each type of user, implementation decisions, testing approach, and exclusions. It uses the project glossary and respects relevant architectural decisions.
Use it when you want to preserve a feature discussion as a specification that can be handed over for development. It summarizes what is already known instead of interviewing you about the requirements again. It also records implementation plans, testing decisions, and work outside the current scope together.
The issue tracker and label vocabulary must be configured. If missing, it directs you to /setup-matt-pocock-skills. Before writing, it checks the proposed testing boundaries with you. Published issues receive ready-for-agent. Implementation decisions generally omit specific file paths and code, except prototype snippets that express a decision more precisely than prose.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.
The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 19, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
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:
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.
A list of testing decisions that were made. Include:
A description of the things that are out of scope for this spec.
Any further notes about the feature.
</spec-template>No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Choose which related skill to use and in what order for planning, building, debugging, or maintaining software. It explains routes through the available workflows and helps select the next step based on your situation and project size.
Coordinate subagents, separate agents assigned tasks, to pursue a long-running goal in one session. Maintain dialogue with the user while improving working conditions, shared rules, and access to information needed for future tasks.
Summarize an ongoing conversation and launch a fresh background agent to continue the work. The handoff includes the next focus, references to existing documents, and suggested skills, with sensitive information removed.
Review code changes from a chosen Git reference against two separate criteria: documented coding standards and the original requirements. Independent reviewers check each criterion, then present findings separately so convention problems and requirement gaps remain visible.
Design modules that offer substantial behavior through a small interface, the rules callers must understand. Use shared design terms to simplify usage, contain complexity, choose where implementations can vary, and make behavior easier to test.
Investigate difficult bugs and performance slowdowns by building a repeatable test or script that detects the exact symptom. Reduce the failing case, compare possible causes, and verify the fix with checks that catch the bug if it returns.