skills/write-a-prd/SKILL.md
Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue after user approval. Use when user wants to write a PRD, create a product requirements document, or plan a new feature. Always present the PRD for user approval before submitting.
npx skillsauth add apocohq/skills write-a-prdInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary, but you MUST NEVER skip the user approval step before submitting to GitHub.
Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
Explore the repo to verify their assertions and understand the current state of the codebase.
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one.
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.
Once you have complete understanding of the problem and solution, use the template below to write the PRD. Present the full PRD to the user and explicitly ask for their approval before proceeding.
Only after the user has explicitly approved the PRD, submit it as a GitHub issue. NEVER create the GitHub issue without user approval.
The problem that the user is facing, from the user's perpective.
The solution to the problem, from user's perspective.
Implementation decisions should not be overly prescriptive, we want those decisions to be durable.
</prd-template>testing
Tracks Architecture Decision Records (ADRs) in docs/adrs/. Creates, lists, and updates ADRs following project conventions. TRIGGER when: user wants to record, review, or update an architectural decision.
development
Morning review and prioritization of Things todos. Use this skill every morning, or whenever the user asks to review, triage, categorize, or prioritize their Things tasks. Also trigger when the user says things like 'what should I work on today', 'organize my todos', 'morning routine', or 'daily review'.
testing
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
tools
Pick and implement the next user story from a PRD GitHub issue. Analyzes merged PRs for prior work and findings, proposes a plan, implements it, and creates a PR linking back to the PRD. Use when user says "ralph it", "ralph-it", or wants to work through PRD user stories.