write-feature-prd
Write Feature PRD
Write PRDs for features in an existing system. Start from what already exists; do not treat the codebase as greenfield.
Quick Start
- Clarify the problem, users, and constraints.
- Explore the repo to find the current flows, modules, and boundaries involved.
- Inventory reusable code, existing skills, and deterministic tools before proposing new work.
- Write the PRD with explicit reuse decisions, gaps, risks, and testing/rollout guidance.
Workflow
1. Frame the request
Capture:
- user problem and desired outcome
- affected actors and surfaces
- constraints, deadlines, and non-goals
- whether this is net-new behavior, an extension, or a replacement
2. Audit the current system
Read enough code to answer:
- where this feature enters the system
- which modules already solve part of it
- what patterns, contracts, and naming conventions already exist
- what tests, plans, or docs already describe adjacent behavior
Prefer exact code lookup over guessing. Use /find-code and /code-graph if available.
3. Inventory available tools
Before proposing implementation, list:
- reusable modules, services, and components already in the repo
- existing skills that can help deliver the work (
/design-api,/write-tests,/prd-to-plan,/grill-me, etc.) - scripts, generators, or platform capabilities already present
The PRD must distinguish:
- Reuse: extend or compose as-is
- Modify: existing modules that need changes
- Net-new: capabilities that do not exist yet
4. Resolve decisions
Interrogate missing details until the design is coherent:
- user-visible behavior and edge cases
- data model or schema impact
- API, events, and background jobs
- auth and permissions
- migration, rollout, and failure modes
- observability and testing approach
Use /grill-me if the proposal is still vague or risky.
5. Write the PRD
Use the template in REFERENCE.md. Keep the document implementation-aware but durable:
- include module boundaries, contracts, dependencies, and testing strategy
- include named systems and routes when they are durable
- avoid volatile file paths or code snippets unless the user explicitly asks
6. Hand off cleanly
If the user wants next steps:
- use
/prd-to-planto break the PRD into phases - route focused execution work to the relevant skill
- note open questions that block implementation
Guardrails
- Never recommend building new infrastructure when a viable existing path already exists.
- Call out assumptions separately from confirmed findings.
- Treat missing code evidence as uncertainty, not permission to invent.
- If the repo is too large to inspect fully, state the sample you used and the confidence level.
References
- REFERENCE.md - PRD template, repo-audit checklist, reuse inventory format, and decision prompts.
More from rockclaver/systemcraft
code-graph
Builds and maintains a `.claude/codegraph.md` index of a codebase — a structured map of every module with purpose, key exports, and dependencies — so the agent can navigate any repo by reading one file instead of scanning dozens. Use when starting work on an unfamiliar codebase, when asked to index a repo, when context costs are high from repeated scans, or at the start of any task that will touch multiple files.
14find-code
Locate files and code using grep and shell scripts — never by AI scanning. Returns exact file paths and line numbers so the agent can jump directly to the location. Use whenever the agent needs to find a function, class, variable, import, file, or any pattern in the codebase. Code and file discovery must always be a tool call, never an AI guess.
14grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
13prd-to-plan
Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in ./plans/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".
13write-a-prd
Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.
13design-api
Design and implement consistent, DRY REST API endpoints for database models — handlers, routing, validation, error responses, and shared utilities — then generate test coverage for every endpoint. Use when the user asks to write an API, add endpoints for a model, build a REST layer, or create CRUD routes.
13