一键导入
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Turn raw product ideas, vague feature concepts, or partially scoped initiatives into implementation-ready briefs and sliced plans through explicit user alignment, selective research and design, and evidence-backed readiness. Use when moving from an idea or discussion to agreed scope, architecture or technical decisions, a spec, TODO plan, tickets, or implementation handoff. Do not use for already-scoped small implementation work or narrow bug fixes unless the user explicitly wants product-to-implementation alignment.
Review one explicit Git scope along two independent axes: repository standards and fidelity to the originating spec. Use for branch, PR, commit-range, or work-in-progress reviews where both code quality and requested behavior matter.
Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.
Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
Configure this repo for the engineering skills — set up its issue tracker, workflow label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.
Test-driven development using a red-green loop at explicit public seams. Use when the user wants a feature or bug fix built test-first, requests red-green development, or wants behavior-level integration tests.
| name | to-spec |
| description | 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. |
Turn the current conversation context and codebase understanding into a spec (sometimes called a PRD). Synthesize what is already known; this skill is not an interview.
The issue tracker and workflow label vocabulary should already be configured. Run $setup-matt-pocock-skills if they are not.
Explore the repo to understand the current state of the codebase, if you have not already. Use the project's domain glossary vocabulary throughout the spec, and respect ADRs in the area you are touching.
Sketch the seams at which the feature will be tested. Prefer existing seams to new ones and use the highest seam possible. If new seams are needed, propose them at the highest point you can. Fewer seams are better; one seam is ideal when it still gives meaningful coverage.
Confirm with the user that the seams match their expectations.
Write the spec with the template below, publish it to the configured issue tracker, and apply the configured ready-for-agent workflow label. No additional state transition is required.
The problem the user is facing, from the user's perspective.
The solution to the problem, from the user's perspective.
A thorough, numbered list of user stories. Use this format:
Cover the meaningful user-visible behavior without inventing scope that the conversation did not establish.
The implementation decisions already made, including whichever are relevant:
Avoid specific file paths or code snippets because they go stale quickly. Exception: when a prototype produced a state machine, reducer, schema, or type shape that captures a decision more precisely than prose, include only the decision-rich excerpt and identify it as prototype-derived.
Include:
The work explicitly outside this spec.
Any remaining context needed to implement or review the work.