Turn the current conversation context into a PRD. Use when user wants to create a PRD from the current context.
Turn the current conversation context into a PRD. Use when user wants to create a PRD from the current context.
npx skills add https://github.com/pruett/wpm --skill prdこのコマンドをClaude Codeにコピー＆ペーストしてスキルをインストール
React composition patterns that scale. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or designing reusable APIs. Triggers on tasks involving compound components, render props, context providers, or component architecture. Includes React 19 API changes.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Manages shadcn-svelte components — adding, composing, fixing, debugging, styling, and building UI in Svelte 5 projects that use shadcn-svelte (the Svelte port of shadcn/ui). Provides project context, component authoring rules, and composition patterns. Triggers on shadcn-svelte work, "add a component", "compose a component", "create a component", "fix this component", or any work involving packages/web/src/lib/components/ui/.
Look up dependency source code in opensrc/ for deep understanding of how packages work internally. Use when you need to understand a dependency's implementation (not just its types), debug unexpected behavior from a library, or find usage patterns in real source code. Triggers on "look at the source", "how does X work internally", "check opensrc", "fetch source for", or when library behavior is unclear from types alone.
| name | prd |
| description | Turn the current conversation context into a PRD. Use when user wants to create a PRD from the current context. |
This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
Explore the repo to understand the current state of the codebase, if you haven't already.
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.
The problem that the user is facing, from the user's perspective.
The solution to the problem, from the user's perspective.
A LONG, numbered list of user stories. Each user story should be in the format of:
This list of user stories should be extremely extensive and cover all aspects of the feature.
A list of implementation decisions that were made. This can include:
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
A list of testing decisions that were made. Include:
A description of the things that are out of scope for this PRD.
Any further notes about the feature.
