القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Implement a feature from the plan that plan-feature produced under docs/plan/<feature>/, one reviewed sub-issue at a time. Use when the user wants to implement or build a feature from a docs/plan/<feature>/ plan or a planned GitHub issue.
Turn a GitHub issue into an implementation plan under docs/plan/<feature>/: a feature spec decomposed into context-window-sized sub-issues, committed as the first commit of the feature branch with a draft PR. Use when the user wants to plan a feature, decompose a GitHub issue into sub-issues, or produce an implementation plan from an issue.
Template and writing guidelines for a GitHub issue. Every issue is one of epic, feature, task, bug, or research task — the user decides the type, and each type has its own template. Non-epic types can suggest a parent epic from the project board.
Draft a GitHub issue, get explicit user approval, and file it via the `gh` CLI. TRIGGER when: user wants to file or "drop" a GitHub issue / ticket.
Check and align a repo's .claude/settings.json and CLAUDE.md with team conventions. Use when the user wants to standardize a repo, align conventions, check settings, or bootstrap Claude Code config in a new project.
Use this skill whenever writing, editing, reviewing, or refactoring TypeScript React code — components, custom hooks, state stores, forms, queries, mutations, API clients, or styling. Trigger it for any task touching a `.ts` or `.tsx` file in a React project, including when the user says "add a feature", "fix this bug", or "clean this up" inside a component or hook. Also use it for architectural questions about React codebases: where state should live, whether a component is too big, how to organize modules, when to reach for TanStack Query, Zustand, React Context, or React Hook Form.
| name | write-a-prd |
| description | 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. |
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.
