How do I install the Write Prd skill?

Run npx skillmds@latest add rockclaver/write-prd in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Write Prd safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Write Prd?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Write Prd free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Write Prd?

rockclaver (@rockclaver) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Write Prd by rockclaver — Agent Skill

Name: Write Prd
Author: rockclaver

Write Prd

Write a PRD grounded in the current codebase — reuse inventory, user stories, module design, testing decisions — optionally filed as a GitHub issue. Use when the user wants a PRD, feature spec, requirements doc, or feature planning.

rockclaver 32b55c1 2 files · 5.6 KB Updated Sep 17, 2026

File contents

Write PRD

Write PRDs grounded in what already exists. Greenfield repos get an interview-first flow; existing systems get a codebase audit first.

Workflow

1. Frame the request

Capture: user problem and desired outcome, affected actors and surfaces, constraints and non-goals, and whether this is net-new behavior, an extension, or a replacement. If the description is thin, ask for a detailed problem statement before exploring.

2. Audit the current system

Read enough code to answer:

where the feature enters the system
which modules already solve part of it
existing patterns, contracts, and naming conventions
tests, plans, or docs describing adjacent behavior

Verify the user's assertions against the code — treat missing evidence as uncertainty, not permission to invent.

3. Inventory reuse

Classify every capability the feature needs:

Reuse: extend or compose as-is
Modify: existing modules that need changes
Net-new: does not exist yet

Never propose new infrastructure when a viable existing path exists.

4. Resolve decisions

Interview the user until the design is coherent: user-visible behavior and edge cases, schema impact, API/events/jobs, auth, rollout and failure modes, observability and testing. Sketch the major modules; prefer deep modules (simple, stable interfaces over lots of functionality) and confirm which get tests. Use grill-me if the proposal is still vague or risky.

5. Write the PRD

Use the template in REFERENCE.md. Include an extensive numbered user-story list (As an <actor>, I want <feature>, so that <benefit>), module boundaries, contracts, and testing strategy. No volatile file paths or code snippets — they go stale. If the user wants it tracked, file it as a GitHub issue via gh issue create.

6. Hand off

prd-to-plan to phase it; note open questions that block implementation.

Guardrails

Call out assumptions separately from confirmed findings.
If the repo is too large to inspect fully, state the sample used and confidence level.

References

REFERENCE.md — PRD template, repo-audit checklist, reuse inventory format, decision prompts.

---name: write-prddescription: Write a PRD grounded in the current codebase — reuse inventory, user stories, module design, testing decisions — optionally filed as a GitHub issue. Use when the user wants a PRD, feature spec, requirements doc, or feature planning.---# Write PRDWrite PRDs grounded in what already exists. Greenfield repos get an interview-first flow; existing systems get a codebase audit first.## Workflow### 1. Frame the requestCapture: user problem and desired outcome, affected actors and surfaces, constraints and non-goals, and whether this is net-new behavior, an extension, or a replacement. If the description is thin, ask for a detailed problem statement before exploring.### 2. Audit the current systemRead enough code to answer:- where the feature enters the system- which modules already solve part of it- existing patterns, contracts, and naming conventions- tests, plans, or docs describing adjacent behaviorVerify the user's assertions against the code — treat missing evidence as uncertainty, not permission to invent.### 3. Inventory reuseClassify every capability the feature needs:- **Reuse**: extend or compose as-is- **Modify**: existing modules that need changes- **Net-new**: does not exist yetNever propose new infrastructure when a viable existing path exists.### 4. Resolve decisionsInterview the user until the design is coherent: user-visible behavior and edge cases, schema impact, API/events/jobs, auth, rollout and failure modes, observability and testing. Sketch the major modules; prefer deep modules (simple, stable interfaces over lots of functionality) and confirm which get tests. Use `grill-me` if the proposal is still vague or risky.### 5. Write the PRDUse the template in [REFERENCE.md](REFERENCE.md). Include an extensive numbered user-story list (`As an <actor>, I want <feature>, so that <benefit>`), module boundaries, contracts, and testing strategy. No volatile file paths or code snippets — they go stale. If the user wants it tracked, file it as a GitHub issue via `gh issue create`.### 6. Hand off`prd-to-plan` to phase it; note open questions that block implementation.## Guardrails- Call out assumptions separately from confirmed findings.- If the repo is too large to inspect fully, state the sample used and confidence level.## References- [REFERENCE.md](REFERENCE.md) — PRD template, repo-audit checklist, reuse inventory format, decision prompts.

Frequently asked questions