
Write A Prd
Turn a vague client request into a structured PRD on disk after repo exploration and a design interview.
Overview
write-a-prd is an agent skill most often used in Validate (also Build) that interviews you through design decisions and writes a structured PRD to issues/prd.md.
Install
npx skills add https://github.com/mattpocock/ai-engineer-workshop-2026-project --skill write-a-prdWhat is this skill?
- Five-step ritual: problem intake, repo verification, relentless interview, deep-module sketch, templated PRD write
- Writes issues/prd.md locally—no GitHub issue API or external submission
- Pushes deep modules with simple, stable interfaces versus shallow wrappers
- Confirms module list and which modules get tests with the user before drafting
- Steps are optional when the agent judges them unnecessary
- 5-step PRD workflow (intake, repo explore, interview, modules, templated write)
- Output path: issues/prd.md with optional issues/ directory creation
Adoption & trust: 60 installs on skills.sh; 146 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a client or product ask but no shared, repo-grounded spec that captures modules, tests, and scope before implementation.
Who is it for?
Solo builders turning informal requests into file-based PRDs after a short repo audit and structured Q&A.
Skip if: One-line tweaks, tasks where an approved spec already exists, or teams that require PRDs only in Jira/Linear instead of the repo.
When should I use this skill?
User wants to turn a client request into a structured PRD saved locally in issues/.
What do I get? / Deliverables
You get issues/prd.md with a module-oriented plan you can hand to implementation skills or your own build pass.
- issues/prd.md from the skill template
- Agreed module list with optional test targets noted in the PRD
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
PRDs belong on the Validate shelf because they lock scope and solution shape before full implementation. Scope is where solo builders formalize problem, modules, and test boundaries instead of coding from chat memory.
Where it fits
Client email describes a dashboard—you interview on metrics, auth, and data sources, then PRD modules before any UI work.
You need a spike plan—PRD captures MVP boundaries so the prototype does not absorb production scope.
Mid-project drift—rewrite issues/prd.md after repo exploration so the agent’s next tasks match reality.
Early opportunity doc from a workshop—you still run the interview to separate must-haves from nice-to-haves before validate.
How it compares
Use instead of dumping requirements into chat without a versioned markdown artifact in the project.
Common Questions / FAQ
Who is write-a-prd for?
Indie builders and small teams who want agent-assisted product scoping with output committed as issues/prd.md beside the code.
When should I use write-a-prd?
Use it in Validate when scoping a new feature or client deliverable; in Build when refreshing PM docs before a large refactor; and whenever the user explicitly asks to turn a brief into a PRD.
Is write-a-prd safe to install?
It is procedural guidance for interviews and local markdown—review the Security Audits panel on this Prism page before trusting third-party skill packages in your agent.
SKILL.md
READMESKILL.md - Write A Prd
This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary. 1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions. 2. Explore the repo to verify their assertions and understand the current state of the codebase. 3. Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. 4. Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation. A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes. Check with the user that these modules match their expectations. Check with the user which modules they want tests written for. 5. Once you have a complete understanding of the problem and solution, use the template below to write the PRD. The PRD should be written as a local markdown file at `issues/prd.md`. Create the `issues/` directory if it doesn't exist. Do NOT submit a GitHub issue or call any external service. <prd-template> ## Problem Statement The problem that the user is facing, from the user's perspective. ## Solution The solution to the problem, from the user's perspective. ## User Stories A LONG, numbered list of user stories. Each user story should be in the format of: 1. As an <actor>, I want a <feature>, so that <benefit> <user-story-example> 1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending </user-story-example> This list of user stories should be extremely extensive and cover all aspects of the feature. ## Implementation Decisions A list of implementation decisions that were made. This can include: - The modules that will be built/modified - The interfaces of those modules that will be modified - Technical clarifications from the developer - Architectural decisions - Schema changes - API contracts - Specific interactions Do NOT include specific file paths or code snippets. They may end up being outdated very quickly. ## Testing Decisions A list of testing decisions that were made. Include: - A description of what makes a good test (only test external behavior, not implementation details) - Which modules will be tested - Prior art for the tests (i.e. similar types of tests in the codebase) ## Out of Scope A description of the things that are out of scope for this PRD. ## Further Notes Any further notes about the feature. </prd-template>