How do I install the To Prd skill?

Run npx skillmds@latest add rca32/to-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 To 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 To 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 To Prd free to use?

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

Who published To Prd?

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

To Prd by rca32 — Agent Skill

Name: To Prd
Author: rca32

To Prd

Write a product requirements document from a brief, conversation, supplied artifacts, or existing software. Use for PRDs, product specs, and product-level reconstruction. Not for implementation or engineering task decomposition.

rca32 282a105 2 files · 2.7 KB Updated Sep 17, 2026

File contents

Clarify the product outcome

Write a PRD that supports the decisions and implementation the user actually needs. A short feature brief and a cross-product initiative should not receive the same document.

For a proposed product, use the user's intent and artifacts as the starting point. For an existing product, describe observable behavior and label inferred intent. Repository evidence can establish what exists, not automatically what the product should become.

Inspect the relevant sources and reuse accepted decisions. Research only uncertainties that could change the requirements; choose scope from product boundaries, not file-count limits. Ask about consequential missing choices, but draft directly when context is sufficient. Do not require a questionnaire or a second approval after the user has already settled the brief.

Make the document useful

Cover the problem, intended users, desired outcome, scope/non-goals, required behavior, and observable success criteria. Add constraints, important edge cases, dependencies, migration/rollout considerations, and open questions when relevant. Use whichever structure makes these clear; omit irrelevant sections rather than filling them with “not applicable.”

Separate required behavior, optional ideas, observed facts, and assumptions. Identify conflicts or unresolved decisions without inventing agreement. Include enough detail to prevent a misleading implementation, while leaving ordinary engineering choices to the implementer. Do not manufacture metrics, stakeholder commitments, or technical requirements.

Return the PRD in the user's language. It is complete when its scope and requirements are understandable, success is assessable, and material uncertainty is visible.

Artifact boundary

Return the document in conversation unless saving was requested. Use the requested location or repository convention, otherwise a descriptive docs/<feature>-prd.md. Reuse a named existing document when the user requests revision; preserve unrelated content and do not overwrite a different document.

Do not implement the product or update delivery status during PRD authoring. An existing task index can track implementation separately. No other skill, saved task set, or prescribed approval sequence is required to produce this PRD.

---name: to-prddescription: Write a product requirements document from a brief, conversation, supplied artifacts, or existing software. Use for PRDs, product specs, and product-level reconstruction. Not for implementation or engineering task decomposition.---# Clarify the product outcomeWrite a PRD that supports the decisions and implementation the user actually needs. A short feature brief and a cross-product initiative should not receive the same document.For a proposed product, use the user's intent and artifacts as the starting point. For an existing product, describe observable behavior and label inferred intent. Repository evidence can establish what exists, not automatically what the product should become.Inspect the relevant sources and reuse accepted decisions. Research only uncertainties that could change the requirements; choose scope from product boundaries, not file-count limits. Ask about consequential missing choices, but draft directly when context is sufficient. Do not require a questionnaire or a second approval after the user has already settled the brief.## Make the document usefulCover the problem, intended users, desired outcome, scope/non-goals, required behavior, and observable success criteria. Add constraints, important edge cases, dependencies, migration/rollout considerations, and open questions when relevant. Use whichever structure makes these clear; omit irrelevant sections rather than filling them with “not applicable.”Separate required behavior, optional ideas, observed facts, and assumptions. Identify conflicts or unresolved decisions without inventing agreement. Include enough detail to prevent a misleading implementation, while leaving ordinary engineering choices to the implementer. Do not manufacture metrics, stakeholder commitments, or technical requirements.Return the PRD in the user's language. It is complete when its scope and requirements are understandable, success is assessable, and material uncertainty is visible.## Artifact boundaryReturn the document in conversation unless saving was requested. Use the requested location or repository convention, otherwise a descriptive `docs/<feature>-prd.md`. Reuse a named existing document when the user requests revision; preserve unrelated content and do not overwrite a different document.Do not implement the product or update delivery status during PRD authoring. An existing task index can track implementation separately. No other skill, saved task set, or prescribed approval sequence is required to produce this PRD.

Frequently asked questions