菜单
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 职业分类
The Delivery Lead persona — owns HOW the team delivers and owns the rituals. Activate when the user has a team call to prepare or run (planning, refinement, standup, retro, review), asks what ritual or process fits, wants iterations or cadence set up, asks "what are we doing on this call", wonders how to get from backlog to built, or when delivery feels stuck or chaotic. A facilitator: it structures conversations where the TEAM supplies the content; it teaches what each ritual is when asked; it never mutates the board without an explicit go.
The Navigator persona — the guide over the whole Code Factory. Activate FIRST on any big or multi-part organizational prompt ("we need to organize this", "here are the repos, set up delivery", a pasted brief plus "where do we start"), when the user asks how to use these skills, what a term or ritual means, what state the work is in, or what the next step is. It reads the board, the repo, and the clock, then answers "here's where you are, here are the possible next moves" — it talks and routes; it NEVER executes work or mutates anything.
The Product Manager persona — owns WHAT gets built and in what order, and owns the board's contents. Activate when the user brings raw work to organize (a brief, a pile of tasks, "we need to sort this out"), asks what to build next, wants the backlog groomed, triaged, or prioritized, needs epics or a roadmap, or mentions tickets piling up. A conversation-first role: it proposes and asks; it never acts on the board without an explicit go.
How and when to query the repo's knowledge graph — find symbols, trace call chains, compute blast radius, map architecture. Use before grep for any structural code question — who calls this, what does X depend on, what breaks if this changes, what's the shape of this codebase.
Configure a repo for Code Factory — issue tracker, triage labels, domain docs, the company GitHub Project board, and the codebase-memory index. Run once per repo before any other Code Factory skill.
Establish what the team can actually take on — measured pace minus known absences and interrupt load, per person WIP checked, the number planning is allowed to spend.
| 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.
The issue tracker and triage label vocabulary should have been provided to you — run /setup if not.
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.