Menü
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.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| 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 |
Take the current conversation and your understanding of the codebase and turn them into a PRD. Do NOT interview the user — synthesize what you already know.
The issue tracker and triage label vocabulary should already have been handed to you — run /setup-skills if not.
Explore the repo to learn the current state of the codebase, if you haven't yet. Use the project's domain glossary throughout the PRD, and respect any ADRs covering the area you're touching.
Sketch the seams you'll test the feature at. Favour existing seams over new ones, and pick the highest seam available. When a new seam is unavoidable, propose it as high up as you can. Fewer seams across the codebase is better — one is ideal.
Check with the user that these seams match what they expect.
Write the PRD from the template below, then publish it to the project issue tracker. Apply the ready-for-agent triage label — no further triage needed.
The problem the user is facing, in the user's own terms.
The solution to that problem, in the user's own terms.
A LONG, numbered list of user stories. Each takes the form:
Make this list exhaustive — cover every aspect of the feature.
The implementation decisions that were made. This can cover:
Do NOT include specific file paths or code snippets. They can go stale fast.
Exception: if a prototype produced a snippet that captures a decision more precisely than prose could (a state machine, reducer, schema, type shape), inline it inside the relevant decision and note briefly that it came from a prototype. Trim to the decision-bearing parts — not a working demo, just the pieces that carry the decision.
The testing decisions that were made. Include:
What this PRD deliberately leaves out.
Anything else worth recording about the feature.
Recurring maintenance pass over automated dependency-bump PRs (Dependabot, Renovate, or similar) — rebase, relock, verify, and report what's ready to merge. Meant to be handed to a time-based loop or schedule, not run once.
Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand.
Reference for designing agent loops — cycles of work that repeat until a stop condition is met. Covers the four loop shapes, writing completion criteria, carrying state and isolating work across cycles, and what running unattended still leaves on you.
Recurring check-in on a stack of dependent PRs — rebase children onto updated parents, surface CI state, flag anything waiting on a human-only gate, and report only what changed since last time. Meant to be handed to a time-based loop, not run once.
Pick the skill or flow that fits your situation. A router over the skills in this repo.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
