菜单
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 职业分类
| 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. |
| disable-model-invocation | true |
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.
Publish per the tracker skill's conventions (or the tracker the project's CLAUDE.md declares).
Explore the repo to understand the current state of the codebase, if you haven't already. Use the vocabulary from CONTEXT.md throughout the spec, and respect any ADRs in decisions/ 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.
agent/tasks/<feature-slug>/spec.md. Decisions that pass the ADR gate belong in decisions/ via /mx:domain-modelling — the spec references them, it doesn't restate them.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 — extremely extensive, covering every actor and every aspect of the feature. No human reads this document, so exhaustiveness costs nothing; the stories carry the definition of done, and tickets are later sliced from and checked against them. Each user story should be in the format of:
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.
Work a feature's ticket DAG in parallel — one orchestrator fans independent frontier tickets out to parallel worker agents and integrates them on the feature branch until the feature ships. Use when a ticketed feature has independent frontier tickets, the user says "dispatch" or wants tickets worked in parallel, or when another skill routes parallel frontier work here.
Which mx skill or flow fits the current situation — a router over the mx workflow.
Run commands in tmux whenever they run long or need eyes on them — anything expected to take more than ~30–60s (training runs, ML experiments, builds, servers), anything worth observing mid-run (progress logs, monitoring output), and anything interactive (sudo prompts, REPLs, wizards), locally or on a remote host. Always reach for this instead of a fire-and-forget Bash call in those cases — the human can attach and step in at any time.
Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published per the tracker conventions — ticket files with blocked-by edges, or native blocking links on a real tracker.
Review and update Claude Code's auto-approved command allowlist based on Bash commands that triggered permission prompts in recent sessions.
File-based issue tracker conventions — how specs, tickets, and small tasks live in agent/tasks/ and how to publish, fetch, claim, and retire them. Use when publishing or fetching a spec/ticket/task, picking work from the frontier, or when another skill says "publish to the issue tracker".