write-a-prd
This skill creates a PRD and saves it to ./docs/<feature-name>/PRD.md. You may skip steps if context is already provided or you don't consider them necessary.
When invoked interactively (user at the keyboard)
-
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 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.
-
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 a complete understanding of the problem and solution, write the PRD using the template below.
When invoked by afk (context provided, no user interaction)
More from tahajemmali/skills
prd-to-plan
Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in ./docs/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".
80grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
77reality-check
Activate a brutally honest, skeptical architectural partner that stress-tests ideas, architectures, and assumptions. Use when the user says "reality check", wants their design challenged, asks if their idea is sound, wants a devil's advocate review, or wants architectural critique without hand-holding.
77ship-check
Run the standard post-change validation flow after a fix, refactor, or new feature. Use when implementation work is done and you should validate the latest changes by invoking the repo's review skills, starting with review-changes and then repo-doc-maintainer, before giving the final close-out.
73review-changes
Review the latest changes and check whether they comply with the project's documented guidelines (AGENTS.md, CLAUDE.md, or equivalent). Use when reviewing local diffs, recent commits, or feature work and you need a findings-first assessment of architecture, reuse, testing, and repo-specific rules.
73repo-doc-maintainer
Review recent repository changes and decide whether AGENTS.md or other project-level documentation needs a high-level update. Use when finishing a feature, fix, refactor, or architectural change and you need to preserve repo-shaping guidance such as new patterns, constraints, workflows, validation rules, or onboarding-relevant gotchas without adding low-level implementation detail.
72