القائمة
Synthesize the current conversation into a spec at docs/specs/<feature>.md, test seams included.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
Scan the session for compound-worthy learnings, then commit the working tree with a repo-appropriate, value-communicating message.
Garbage-collect the knowledge stores — audit docs/solutions/ and AGENTS.md against the current code.
Capture this session's durable learnings and route each to the right knowledge store, every write user-gated. Use at loop end when /commit's opening scan finds candidates, when /diagnosing-bugs closes out a fix, or when the user wants to capture, remember, or write down a learning, convention, gotcha, or preference.
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to be grilled about a plan, wants a decision stress-tested, or when requirements are fuzzy before a spec is written.
| name | spec |
| description | Synthesize the current conversation into a spec at docs/specs/<feature>.md, test seams included. |
| disable-model-invocation | true |
| version | 1.0.0 |
| source | mattpocock/skills@1.1.0 (to-spec) |
Produce a spec (you may know this document as a PRD) from the current conversation and codebase understanding.
Synthesize what you already know — the interview, if any, already happened (/grilling).
Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain vocabulary throughout the spec.
Search docs/solutions/ and existing docs/specs/ for learnings that bear on this feature — root causes, gotchas, approaches that failed before, decisions already made.
Fold whatever applies into the spec's decisions.
Propose the test seams — the places /implement will drive TDD (seam vocabulary: /codebase-design).
Prefer existing seams to new ones; place any new seam at the highest point you can.
The fewer seams across the codebase, the better — the ideal number is one.
Check the seams with the user before writing the spec: approving them now, while the decisions are fresh, lets implementation test at them later without relitigating the design.
Write the spec to docs/specs/<feature>.md (kebab-case feature slug) using the template below.
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.
The seams the user approved in step 3 — where TDD will bite during implementation. For each seam: the interface under test, what behavior the tests will verify through it, and prior art (similar tests in the codebase).
A description of the things that are out of scope for this spec.
Any further notes about the feature.
Spec written → close with a flow pointer (presentation): /tickets (user-invoked) if the work spans multiple sessions or context windows, else /implement (user-invoked) — in a fresh context either way.
