Write A Prd
- 95 installs
- 193 repo stars
- Updated April 1, 2026
- mattpocock/ai-engineer-workshop-2026-project
write-a-prd is an agent skill that interviews you through design decisions and writes a structured PRD to issues/prd.md.
About
write-a-prd is an agent skill that converts a long client or product brief into a structured product requirements document saved as issues/prd.md. It is built for solo and indie builders who need a durable spec before agents start touching code, especially when the request spans multiple modules or depends on what already exists in the repository. The workflow starts by collecting a detailed problem statement, then explores the repo to validate assumptions about the current codebase. The agent interviews you branch-by-branch through the design tree until decisions and dependencies are aligned, then outlines major modules to build or modify—with an explicit preference for deep modules that hide complexity behind simple, testable interfaces. After you confirm modules and test targets, it fills a standard PRD template. The output stays in your git tree for the next planning or implementation skill, not in a ticket system you do not control.
- 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
Write A Prd by the numbers
- 95 all-time installs (skills.sh)
- +15 installs in the week ending Jun 21, 2026 (Skillselion tracking)
- Ranked #1,383 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Aug 2, 2026 (Skillselion catalog sync)
npx skills add https://github.com/mattpocock/ai-engineer-workshop-2026-project --skill write-a-prdAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 95 |
|---|---|
| repo stars | ★ 193 |
| Security audit | 3 / 3 scanners passed |
| Last updated | April 1, 2026 |
| Repository | mattpocock/ai-engineer-workshop-2026-project ↗ |
What it does
Turn a vague client request into a structured PRD on disk after repo exploration and a design interview.
Who is it for?
Best when you're 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 you get
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
By the numbers
- 5-step PRD workflow (intake, repo explore, interview, modules, templated write)
- Output path: issues/prd.md with optional issues/ directory creation
Files
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>
Related skills
Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196kGrill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196k
Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493kLark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493kLark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493kLark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493kHow it compares
Use instead of dumping requirements into chat without a versioned markdown artifact in the project.
FAQ
Who is write-a-prd for?
Developers 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.