Menu
Turn the current conversation context into a PRD and save it. Use when you want a formal product requirements document from the current discussion.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Find deepening opportunities in the codebase — refactors that reduce coupling, simplify interfaces, and improve AI-navigability. Use when improving architecture, finding refactoring opportunities, or making a codebase easier to work with.
Use before any feature work — explores intent, asks clarifying questions one at a time, produces a design doc. Invoke before writing any code or plan.
Ultra-compressed communication mode. Cuts token usage ~75% by dropping filler, articles, and pleasantries while keeping full technical accuracy. Use when user says "caveman mode", "talk like caveman", "less tokens", or invokes /caveman.
Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → review. Use when something is broken, throwing errors, or regressing.
Interview the user or a design relentlessly until reaching shared understanding. Walk down every branch of the decision tree, resolving dependencies one by one. Use when stress-testing a plan, clarifying design, or the user says "grill me".
Use at the start of any session to understand which skill to invoke. Maps the full workflow — feature development, bug fixing, architecture, and utilities — for a C++ game server project with SVN.
| name | to-prd |
| description | Turn the current conversation context into a PRD and save it. Use when you want a formal product requirements document from the current discussion. |
Synthesise the current conversation and codebase understanding into a PRD. Do NOT interview the user — just synthesise what you already know.
Explore the codebase if you haven't already. Understand the current state of the relevant modules. Use the project's domain vocabulary throughout.
Sketch the major modules to build or modify. Look for opportunities to extract deep modules with clean interfaces. Check with the user that the module breakdown matches their expectations.
Write the PRD using the template below and save to docs/prd/YYYY-MM-DD-<feature>.md. Then svn add + svn commit -m "docs: add PRD".
# [Feature Name] PRD
## Problem Statement
The problem the user is facing, from their perspective.
## Solution
The solution, from the user's perspective.
## User Stories
A numbered list of user stories:
1. As a <actor>, I want <feature>, so that <benefit>
Cover all aspects of the feature. Be thorough.
## Implementation Decisions
- Modules to build or modify (name them by their Manager/class names)
- Interface decisions (what the Manager exposes to CmdParser)
- Protocol changes (new CmdId ranges, CS/SC structs)
- Data structure changes (new fields in SdpData sdp files)
- Error code additions (new ERR_ entries in ErrorDefine.sdp)
- Architectural decisions and constraints
Do NOT include specific file paths or code snippets — they go stale quickly.
Exception: if a prototype produced a snippet that encodes a decision more precisely than prose
(e.g. a key state machine or data structure shape), inline it and note it came from a prototype.
## Out of Scope
What is explicitly NOT included in this PRD.
## Further Notes
Any open questions, dependencies, or follow-up items.
Transition to /plan to create the implementation plan, or /to-issues to slice into individually-committable issues.