Menu
Create or update draft PRD and user stories for a feature.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Run a single demo E2E test file, diagnose failures, dispatch fixes to agents, and re-run until pass.
Execute phased task plans by dispatching work to specialized sub-agents for backend, frontend, miniapp, Flutter, or demo phases.
Validate task plan executability and consistency with a 100-point score and P0/P1/P2 fix list.
Convert technical design documents into executable phased task plans with ordered work breakdown.
Evaluate technical design documents for implementability, completeness, and consistency with a quantitative 100-point score.
Initialize a full-stack project skeleton with Rust backend (Axum + SeaORM + Redis) and React frontend (TypeScript + TanStack + Tailwind).
| name | t-prd |
| description | Create or update draft PRD and user stories for a feature. |
| argument-hint | [feature-name] |
| allowed-tools | ["AskUserQuestion","Read","Glob","Grep","Write","Bash"] |
运行时边界统一参考：${CLAUDE_PLUGIN_ROOT}/protocols/runtime-boundaries.md
若本 skill、spec 或既有文档之间冲突，停止、说明冲突并等待澄清；不要平均折中。
不要用它做：
/t-prd-check/t-prd-check基于 Decision Brief、现有 user story、正式 PRD、已有 PRD 草稿和用户补充信息，先补齐必要的 draft user story，再创建或更新一份 PRD 草稿，供人类快速审阅。.ai/prd 和 .ai/user-stories 是实现前和实现期间的临时候选需求工作区，不是长期权威源。
输出文件：
.ai/prd/<domain>/[feature].md.ai/user-stories/<domain>/[feature].md（如需新增或补齐用户故事）/t-prd [feature]
[feature] 必须是 feature 名称.., /, \如果参数不合法，立即终止并提示正确用法。
路径与域：
.ai/prd/<domain>/[feature].md.ai/user-stories/<domain>/[feature].md<domain> 只能是 auth、billing、core、integration/t-prd 不写入 docs/prd/；若父目录缺失，仅在目标域已明确时创建 .ai/prd/<domain>//t-prd 不写入 docs/user-stories/；若需新增或补齐用户故事，只写 .ai/user-stories/<domain>/.ai/prd 和 .ai/user-stories 不作为长期权威源；它们在设计、任务、实现和验收期间作为候选需求输入保留${CLAUDE_PLUGIN_ROOT}/protocols/requirement-source-contract.mdPRD 内容边界：
GET/POST /api/...）、请求/响应参数表、HTTP 状态码列表、数据库表结构/迁移方案、Rust/TypeScript 类型定义更新行为：
user story 引用：
docs/user-stories/....ai/user-stories/<domain>/<feature>.mddocs/user-stories$ARGUMENTS 是 Claude Code 传入的 feature 名称；用户已在命令或当前对话中给出的信息不重复追问AskUserQuestion.ai/decision/[feature].md，PRD 必须承接其中 Verdict、Scope Direction、D0/D1 决策和 Handoff；不得把 Open Questions 写成已确认决策Needs Clarification、Park 或 Reject，停止并提示先回到 /t-decision [feature]/t-prd 在写入 PRD 草稿前必须完成轻量澄清门禁：先研究事实，再对真正阻塞 PRD 的判断点逐一追问，直到足以形成可审阅的产品语义。
运行时维护一个临时 PRD Grill Snapshot，不写入 PRD 正文：
PRD Grill Snapshot
- Problem statement: [一句话说明要解决的问题或目标能力]
- Success criteria: [可验收的成功信号，至少 1 条]
- Facts: [来自现有文档、代码、tech research 或当前对话的事实]
- Confirmed decisions: [用户已确认的产品决策]
- Open questions: [仍阻塞 PRD 的判断题]
门禁规则：
docs/user-stories/、.ai/user-stories/、docs/prd/、.ai/prd/、.ai/tech-research/、产品 guide 和必要代码上下文；能查明的事实不得问用户。通过门禁的最低条件：
Problem statementSuccess criteria/t-prd：补齐 draft user story → 创建/更新 .ai/prd 草稿/t-prd-check：可选检查 PRD 草稿、正式 PRD 基线和用户故事质量（不在本 skill 范围内）/t-design：基于草稿 PRD 与正式 PRD 的混合验证生成技术设计；若跳过 /t-prd-check，/t-design 仍需自行识别关键冲突（不在本 skill 范围内）上游输入（可选，如果存在会提升质量）：
docs/user-stories/**/*.md — 用户故事文档.ai/user-stories/**/*.md — draft 用户故事文档docs/prd/00-index.md — 正式 PRD 索引.ai/decision/[feature].md — 产品立项决策简报（必须检查；存在时必须读取，来自 /t-decision）docs/prd/<domain>/[feature].md — 已发布正式 PRD（可选，用作草稿基线）.ai/prd/<domain>/[feature].md — 已有 PRD 草稿（可选，用作更新基线）.ai/tech-research/[feature].md — 技术可行性研究报告（可选，来自 /t-tech-research）${CLAUDE_PLUGIN_ROOT}/guides/product/index.md — 产品规范入口${CLAUDE_PLUGIN_ROOT}/guides/product/user-story.md — 用户故事规范${CLAUDE_PLUGIN_ROOT}/protocols/requirement-source-contract.md — 需求来源正式/候选边界如果上游输入缺失，skill 仍可运行，但会在文档中标记缺失项。
下游产出：
.ai/prd/<domain>/[feature].md — PRD 草稿，包含：
.ai/user-stories/<domain>/[feature].md — draft 用户故事，按需新增或补齐。/t-prd 不写入 docs/user-stories。
[feature] 非空且符合文件名规则$ARGUMENTS 作为 feature 名称唯一入参来源先读取：
docs/prd/00-index.md.ai/decision/$ARGUMENTS.md（必须检查；存在时从中提取 Verdict、Scope Direction、D0/D1 决策、Open Questions 和 Handoff）docs/user-stories/00-index.md.ai/user-stories/**/*.md.ai/tech-research/$ARGUMENTS.md（如已存在，从中提取技术需求和影响分析）.ai/prd/**/*.md 和 docs/prd/**/*.md 中与 $ARGUMENTS 相关的少量候选文件根据已发布/候选用户故事、草稿/正式 PRD 和需求语义推断目标域（auth | billing | core | integration）。无法推断时用 AskUserQuestion 询问一次。
检查 .ai/prd/<domain>/[feature].md 和 docs/prd/<domain>/[feature].md：
如已存在 .ai/decision/$ARGUMENTS.md，先从中提取目标用户、问题陈述、范围方向、已确认产品决策、仍阻塞 PRD 的问题和给 PRD 的 Handoff。若 Verdict 不允许继续进入 PRD，停止并提示回到 /t-decision。
如已存在 .ai/tech-research/$ARGUMENTS.md，再从中提取技术需求（§1.2）、代码库评估（§2）、影响分析（§5）和 PRD 建议（§7）。
仅当上下文无法可靠推断时，用 AskUserQuestion 补齐：
以下信息优先从现有文档和代码推断，不作为默认提问项：
如需新建 user story，额外确认：
基于已收集信息建立临时 PRD Grill Snapshot，并按"PRD 前置澄清门禁"检查是否满足最低条件。
不得：
读取：
docs/user-stories/00-index.md、_README.md、_roles.md${CLAUDE_PLUGIN_ROOT}/guides/product/index.md 和 user-story.mddocs/user-stories/**/*.md、.ai/user-stories/**/*.md、docs/prd/**/*.md 和 .ai/prd/**/*.md执行：
.ai/user-stories/<domain>/<feature>.md新增 user story 必须遵循 ${CLAUDE_PLUGIN_ROOT}/guides/product/user-story.md 的结构和 GWT 风格验收标准，使用 user-story-template.md。
补齐后仍不够 → 继续生成 PRD 草稿，在文档中标记"待补充用户故事"。
create 路径使用 template.md；draft-from-published 和 update 路径按核心约束中的"更新行为"逐章处理。
写入 .ai/prd/<domain>/[feature].md，至少包含：
不适用的章节保留并标记"不适用"。如需技术细节，建议执行 /t-design。
如果用户基于 PRD 草稿提出修改意见：
完成后明确说明：
.ai/user-stories 候选来源，需在 /t-prd-publish 阶段合并到 docs/user-stories/t-prd-check [feature]；简单需求可直接执行 /t-design [feature]。若检查发现问题，修复后可再次运行 /t-prd-check [feature]推断部分需在收尾对话中显式列出：哪些来自现有文档、哪些来自当前对话、哪些仍待确认；未确认内容不写入 Markdown PRD。
auth|billing|core|integration/t-decision [feature]/t-prd-check [feature]