to-prd
by mattpocockto-prd skill turns current conversation context and codebase understanding into a PRD, then publishes it to the project issue tracker. Use it when you already know the change and want a repo-aware PRD without an interview, especially for Skill Authoring workflows.
This skill scores 67/100, which is acceptable for directory listing but still somewhat limited. It gives users a clear trigger and a real PRD-generation workflow tied to publishing an issue, so it can reduce guesswork versus a generic prompt; however, users should expect some setup friction and incomplete operational guidance.
- Clear trigger: "use when user wants to create a PRD from the current context" with direct intent to synthesize from existing conversation/codebase state.
- Concrete workflow value: instructs the agent to explore the repo, use domain glossary/ADRs, draft a PRD, and publish it to the project issue tracker with a ready-for-agent label.
- No placeholder/demo signals; the body is substantial (2915 chars) and includes structured sections and constraints, which improves agent leverage.
- No install command or support files are provided, so users may need to infer setup and integration steps.
- The workflow still leaves some ambiguity: it references a provided issue tracker and label vocabulary, and asks the agent to check with the user on module/test scope, which may require extra prompting.
Overview of to-prd skill
What to-prd does
The to-prd skill turns the current conversation context and codebase understanding into a PRD, then publishes it to the project issue tracker. It is built for situations where you already have enough context to write, and you want a structured product brief instead of a back-and-forth discovery interview.
Who it fits best
Use the to-prd skill when you are working inside an existing repo, already know the rough change, and need a PRD that matches the project’s terminology, ADRs, and tracker workflow. It is especially useful for Skill Authoring or agent-driven implementation flows where the next step is handing off to another agent.
What makes it different
The main differentiator in to-prd is its “do not interview” stance: it synthesizes from what is already known, then pushes the result into the tracker with the correct triage label. That makes it faster than a generic prompt, but also more dependent on having the right repo context and tracker setup available up front.
How to Use to-prd skill
Install and expected context
For to-prd install, use the project’s skill installer, then confirm the repo is connected to the issue tracker workflow you want to use. The skill assumes the issue tracker and triage label vocabulary are already available; if not, run /setup-matt-pocock-skills first. If you skip that setup, the skill may produce a PRD draft but fail at publishing it cleanly.
How to prompt for to-prd usage
The best to-prd usage starts with a clear implementation target, a repo path or feature area, and any constraints you already know. Good input looks like: “Create a PRD for adding OAuth refresh handling in apps/web, using the repo’s glossary and existing ADRs, and publish it to the tracker.” Weak input is just a vague goal like “write a PRD for auth,” because the skill is designed to synthesize, not interview.
Files and signals to check first
Before relying on the output, inspect SKILL.md, then the repo’s README.md, AGENTS.md, metadata.json, and any rules/, resources/, references/, or scripts/ folders if they exist. In this repository, SKILL.md is the primary source, so the workflow is intentionally lightweight; that also means the quality of the PRD depends heavily on the live codebase context you provide.
Practical workflow for better output
Use the skill when you can already describe the change in product terms, then let it convert that into a PRD with problem statement, solution, and user stories. Ask it to respect domain glossary vocabulary and ADRs, and be explicit about which modules may need to change and where test coverage matters. If you are using to-prd for Skill Authoring, keep the prompt scoped to the skill behavior you want documented, not the whole upstream repository.
to-prd skill FAQ
Is to-prd a fit for every PRD task?
No. The to-prd skill is best when the change is already understood well enough to write from context. If you need discovery, product interviews, or market research, a normal prompting workflow is a better fit than to-prd.
How is to-prd different from a generic prompt?
A generic prompt can ask for a PRD, but to-prd adds repo-aware behavior: it looks for glossary terms, respects ADRs, sketches deep modules, and publishes to the issue tracker with the ready-for-agent label. That makes it more operational than a freeform PRD request.
Can beginners use it?
Yes, if they can supply a concrete feature direction and understand that the skill does not ask follow-up questions. Beginners get the best results when they include the repo area, the user problem, and any non-negotiable constraints in the initial request.
When should I not use to-prd?
Do not use to-prd when the tracker is unavailable, the label vocabulary is unknown, or the feature is still being explored. It is also a poor fit when you need iterative stakeholder interviews before drafting the PRD.
How to Improve to-prd skill
Give the skill sharper input
The biggest quality lever is specificity. Include the repo location, the problem to solve, the expected user outcome, and any constraints like platform, performance, or rollout limits. Stronger inputs help to-prd produce a PRD that is closer to implementation reality and less generic.
State module and test expectations
The skill explicitly looks for deep modules and asks which modules should get tests. If you want better output, name candidate modules, say which ones should stay shallow, and flag any isolated logic that should be extracted. This reduces handoff friction and makes the PRD more actionable for the next agent.
Watch for common failure modes
The main failure mode is under-specified context: the PRD becomes broad, tracker-ready prose instead of a decision-driving plan. Another risk is stale terminology if the repo glossary or ADRs are not current. To fix both, anchor your prompt in the current codebase state and update the brief before asking for publication.
Iterate from the first draft
After the first PRD, refine by tightening user stories, clarifying acceptance boundaries, and checking that the issue label and tracker destination are correct. For to-prd, iteration is usually about removing ambiguity, not expanding scope.