メニュー
Turn the current conversation into a PRD 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-prd |
| description | Turn the current conversation into a PRD 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 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-skills 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 PRD, 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 PRD.
Any further notes about the feature.
Rules and worked examples for writing prose that does not read like AI-generated slop. Consult before writing or editing any prose.
Louis Rossmann's writing voice for general prose: testable-number density, high sentence-length variance, claim-then-proof structure, contractions, contempt shown through precision. Consult when writing in his voice.
Audit code for security vulnerabilities across six trust boundaries — access control (IDOR, privilege escalation, mass assignment), auth & sessions (passwords, JWT, CSRF), injection (SQL, XXE, path traversal), XSS & output encoding, untrusted URLs & uploads (SSRF, open redirect, file upload), and data exposure (secrets, PII, leaky errors). Use when hardening or reviewing a feature, before shipping anything that handles untrusted input, auth, or sensitive data, or when asked to "scan for vulnerabilities", "is this secure", "check for IDOR/XSS/SQLi/SSRF", "security review". Defaults to fail-closed, least-privilege, server-side checks.
Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.
Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
Build and maintain a grounded picture of the project's users before designing solutions — personas, jobs-to-be-done, as-is/to-be workflows, and the assumptions under them, each tagged evidence or assumption. Use when kicking off a project or feature, before a PRD or user stories, when the team is guessing what users "want," or when another skill needs the user's goals or mental model.