菜单
Create a Product Requirements Document through structured interview. Use when the user wants to write a PRD, define requirements, or plan a new feature.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | blueprint |
| description | Create a Product Requirements Document through structured interview. Use when the user wants to write a PRD, define requirements, or plan a new feature. |
This skill will be invoked when the user wants to create a PRD. You should go through the steps below. 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.
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 functional components of the system. Actively look for opportunities to extract deep modules that can be verified independently.
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.
Reasoning approach: Deep modules aren't visible in a first pass. Sketch the obvious components, then ask of each: is its interface narrow relative to its body? Does it leak implementation details? Iterate silently before presenting — first-draft components tend to be shallow. Recommended for this step: opus-4.7 with extended thinking (medium-to-high effort).
When 2+ architectural interpretations are plausible: do NOT pick silently. Present the top 2-3 options with their trade-offs (cost, complexity, lock-in, time to first user) and let the client choose. Writing a PRD on a silent architectural guess wastes the entire downstream pipeline.
Check with the user that these components match their expectations. Check with the user which components they want validation criteria for.
Before submitting, verify the PRD passes these gates:
Before creating GitHub issues, verify:
gh CLI is installed and authenticated (gh auth status)If any check fails, inform the user and provide the fix command.
Audit a React/TSX repository for React anti-patterns by loading rule cards from the brainstormer card library, scanning via each card's declared detect strategy, and filing one grouped GitHub issue per `(skill, rule_id)` via the `gh` CLI. Phase 3 adds the full re-run lifecycle: `findIssueByLabel` lookup, in-place body rewrite bounded by `react-audit:managed:start/end` sentinels (human comments survive), close-with-dated-resolution on emptied findings, regression-with-backlink on resurfaced findings, label-collision protocol under concurrent runs, never-reopen invariant. Phase 2c grouped body (15 MVP cards, per-occurrence severity, `<details>` collapsibles) and Phase 2b smart scan (`SMART_SCAN_THRESHOLD=50`) unchanged. Manual invocation only — no hooks. Triggers on `/react-audit`, "audit this repo for react anti-patterns", "run a react audit". Skip design questions, scaffolding, audits of non-React frameworks (Vue, Svelte, Solid).
Discovery interview and requirements gathering session. Pressure-test an idea, architecture, or design decision through structured client interviews. Use when the user wants to be challenged on their thinking, explore trade-offs, or vet a plan before committing.
Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in ./plans/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".
Convert a PRD into independently-grabbable GitHub issues using vertical slices. Use when the user wants to create issues from a PRD, break down a PRD into tasks, or create GitHub issues from requirements.
Test-Driven Development workflow using vertical slices. Use when implementing features with TDD, writing tests before code, or doing red-green-refactor cycles.
Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.