菜单
Generate a Product Requirements Document from user instructions using the PRD template. Outputs a human-readable self-contained HTML file plus a markdown source for implementation tooling. Includes a macro-level task checklist at the end.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | prd |
| description | Generate a Product Requirements Document from user instructions using the PRD template. Outputs a human-readable self-contained HTML file plus a markdown source for implementation tooling. Includes a macro-level task checklist at the end. |
Use the template at prd-template.md. Follow its directives and replace placeholders with the user's instructions.
Run these gates first and record their output in the PRD's Pre-draft findings block. Skipping them under-specifies the work; the implementer (often a weaker model that follows the PRD literally) then reinvents existing code or breaks shared components.
ts-search-first skill to find existing components, hooks, utils,
contracts, and feature codes to reuse. List each as "reuse X (path)". Don't let the
implementer recreate what exists. If the project defines its own reuse rule (CLAUDE.md,
.cursor/rules/*), cite it in the findings.components/ui|form|table|layout, hooks/, lib/, utils/,
shared packages in a monorepo — detect per project, don't assume this layout). If yes, state
per file: extend locally (preferred — new prop/variant/wrapper) OR, if an in-place edit is
unavoidable, list the consumers + require backward-compat and a regression-check pass.After the PRD content, add a "Tasks" section with a checklist (- [ ] ...). Tasks must be MACRO-level (epics), not granular case-by-case items.
The human-facing deliverable is an HTML file, not raw markdown.
Write the PRD as markdown (<name>.prd.md) — the single source of truth, consumed by
implementation skills (composer-implement, oppenheimer, plan runners). Use GFM: tables for requirements with
attributes (priority, status), - [ ] task checklist, a ## Pre-draft findings section at
the top.
Render the HTML from the markdown via the script — never write the HTML by hand:
~/.claude/skills/prd/scripts/render-prd-html.sh <name>.prd.md
It produces a self-contained <name>.prd.html (inline CSS, light/dark, table of contents,
real checkboxes) next to the source. After any edit to the .prd.md, re-run the script —
the HTML is a build artifact, not a second document to maintain.
Tell the user the HTML path and suggest open <name>.prd.html to view it.
When asked to review a PR or branch ("review this PR", "PR review", "argus", before merging), fan the diff out to parallel read-only reviewers and return a severity-ranked verdict; optionally post inline via gh.
When the user has reviewer feedback on a GitHub PR (human or bot like gemini-code-assist) and wants the pertinent items fixed — "j'ai des retours sur la PR", "résous/corrige ce qui est pertinent", "lis les commentaires de la PR via gh" — triage every comment thread via gh, apply only the pertinent fixes (drop nits), then reply to and resolve each triaged thread. Not for publishing our own review findings — that is argus-review --post.
Audit Claude Code agents, skills, and commands for quality and production readiness. Use when evaluating skill quality, checking production readiness scores, or comparing agents against best-practice templates.
Enforce project coding conventions: reduce duplication, keep naming/file placement consistent, and minimize regression risk. Includes React component and layout guidelines. Use when writing or reviewing code.
After modifying code, map all consumers of changed symbols and flag unhandled mismatches. Not for debugging (use systematic-debugging).
Review changed code (session, current branch, or colleague's branch) for principle violations, reinvented wheels, and dead code. Trigger after coding, before merge, or for PR review.