This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary.

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.
If a grilling session has already been conducted in this conversation and its wrap-up covered the decision space needed for the PRD, skip this step. Otherwise, read and run a grilling skill on the plan: prefer grill-with-docs if it's available (it adds inline CONTEXT.md updates and ADR offers on top of the same interview engine), and fall back to grill-me if not. If neither skill is installed, skip this step.
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.

Read the tdd skill and incorporate its testing philosophy into the PRD's Testing Decisions section. Specifically, ensure the PRD specifies:
- TDD red-green-refactor workflow using vertical slices (one test → one implementation → repeat), not horizontal slices (all tests first, then all implementation)
- Tests verify behavior through public interfaces, not implementation details
- Which behaviors each module should be tested for (not implementation steps)
- Before recommending test scope, read the project's testing conventions doc and align the recommendation with the project's coverage threshold and per-file test-density rule

write-a-prd