| 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"] |
PRD 草稿维护
运行时边界统一参考:${CLAUDE_PLUGIN_ROOT}/protocols/runtime-boundaries.md
若本 skill、spec 或既有文档之间冲突,停止、说明冲突并等待澄清;不要平均折中。
适用范围
不要用它做:
- PRD 完整性检查 → 使用
/t-prd-check
- 用户故事质量检查 → 使用
/t-prd-check
- 实施进度或完成情况记录 → 使用对应实现阶段命令或任务状态文件,不写入 PRD
目标
基于 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 名称
- 文件名仅允许英文、数字、空格、下划线、连字符
- 拒绝
.., /, \
- 长度限制 1 到 50 字符
如果参数不合法,立即终止并提示正确用法。
核心约束
路径与域:
- PRD 草稿写入
.ai/prd/<domain>/[feature].md
- draft user story 写入
.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 不作为长期权威源;它们在设计、任务、实现和验收期间作为候选需求输入保留
- PRD、用户故事和技术预研的读取与写入边界统一参考
${CLAUDE_PLUGIN_ROOT}/protocols/requirement-source-contract.md
PRD 内容边界:
- 聚焦产品边界与规则,不承载接口 schema、数据库建表或技术方案
- 可以写:接口能力范围、访问控制原则、租户/realm 边界、兼容性要求、前端页面入口、关键交互、状态反馈约束
- 禁止写:具体端点(
GET/POST /api/...)、请求/响应参数表、HTTP 状态码列表、数据库表结构/迁移方案、Rust/TypeScript 类型定义
- 禁止写:当前任务是否已实现、完成比例、已完成/未完成清单等会随实现推进快速过期的进度状态
更新行为:
- 已有同名草稿 → update 路径,以草稿为基底逐章更新
- 无草稿但有同名正式 PRD → draft-from-published 路径,以正式 PRD 为基线创建草稿,不覆盖正式 PRD
- 无草稿且无正式 PRD → create 路径,使用 template.md
- 已有同名 draft user story 文件 → 追加到合适章节,不重建
user story 引用:
- PRD 只引用相关用户故事(ID、标题、优先级、来源文件),不复制完整验收文本
- 已发布 user story 足够覆盖时,PRD 可直接引用
docs/user-stories/...
- 缺少或需要补齐的本轮用户故事写入
.ai/user-stories/<domain>/<feature>.md
- draft user story 可以按角色分组组织在同一 feature 文件中;不得直接追加到
docs/user-stories
提问规则
$ARGUMENTS 是 Claude Code 传入的 feature 名称;用户已在命令或当前对话中给出的信息不重复追问
- 先读取现有文档和代码上下文,不询问可直接查明的事实
- 只在目标域、范围边界、成功标准或补充 user story 所需信息无法可靠推断时,才使用
AskUserQuestion
- 一次只问一个;每个问题给出推荐答案,用户可接受、修改或拒绝
- PRD 只记录已确认决策;仍待确认的信息在对话收尾中列出,不写入 Markdown PRD
- 如果存在
.ai/decision/[feature].md,PRD 必须承接其中 Verdict、Scope Direction、D0/D1 决策和 Handoff;不得把 Open Questions 写成已确认决策
- 如果 Decision Brief 的 Verdict 是
Needs Clarification、Park 或 Reject,停止并提示先回到 /t-decision [feature]
- 信息足够生成可审阅 PRD 草稿时停止追问,不为了完美而继续打断
PRD 前置澄清门禁
/t-prd 在写入 PRD 草稿前必须完成轻量澄清门禁:先研究事实,再对真正阻塞 PRD 的判断点逐一追问,直到足以形成可审阅的产品语义。
运行时维护一个临时 PRD Grill Snapshot,不写入 PRD 正文:
PRD Grill Snapshot
- Problem statement: [一句话说明要解决的问题或目标能力]
- Success criteria: [可验收的成功信号,至少 1 条]
- Facts: [来自现有文档、代码、tech research 或当前对话的事实]
- Confirmed decisions: [用户已确认的产品决策]
- Open questions: [仍阻塞 PRD 的判断题]
门禁规则:
- Discover first:先读取
docs/user-stories/、.ai/user-stories/、docs/prd/、.ai/prd/、.ai/tech-research/、产品 guide 和必要代码上下文;能查明的事实不得问用户。
- Define next:只追问判断题,包括目标、范围边界、非目标、成功标准、关键异常、优先级取舍、角色价值和验收信号。
- Depth-first:同一问题分支未澄清前,不同时抛出多个无关问题;每轮只问一个,并给出推荐答案。
- Concrete only:若用户回答仍是"更好"、"尽快"、"合理"等模糊表达,继续追问同一判断点,要求给出可判断的范围、指标、状态或验收信号。
- Stop early:当 Snapshot 已能支撑一份可审阅 PRD 草稿时停止追问;其余非阻塞疑问作为待确认项在收尾对话列出。
- Hard boundary:Snapshot 是运行时澄清工具,不是交付物;PRD 只能写入已确认决策和已确认成功标准,不能写入未确认假设。
通过门禁的最低条件:
- 能写出一句话
Problem statement
- 至少确认 1 条
Success criteria
- 已确认本次包含范围和至少 1 条明确 out of scope 或"暂无明确排除项"
- 没有会改变 PRD 主体方向的阻塞问题
职责边界
/t-prd:补齐 draft user story → 创建/更新 .ai/prd 草稿
/t-prd-check:可选检查 PRD 草稿、正式 PRD 基线和用户故事质量(不在本 skill 范围内)
/t-design:基于草稿 PRD 与正式 PRD 的混合验证生成技术设计;若跳过 /t-prd-check,/t-design 仍需自行识别关键冲突(不在本 skill 范围内)
- 本 skill 产出产品语义草稿,不负责接口明细、数据库设计或技术实现方案
Input Contract
上游输入(可选,如果存在会提升质量):
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 仍可运行,但会在文档中标记缺失项。
Output Contract
下游产出:
.ai/prd/<domain>/[feature].md — PRD 草稿,包含:
- 相关用户故事引用
- 范围界定、需求概述、业务规则与状态
- 功能需求与验收目标
- API 相关约束 / 前端交互约束(各标明适用或不适用)
- 已确认决策
- 参考资料
.ai/user-stories/<domain>/[feature].md — draft 用户故事,按需新增或补齐。/t-prd 不写入 docs/user-stories。
工作流程
1. 校验参数
- 检查
[feature] 非空且符合文件名规则
- 缺失 feature:直接失败并提示参数
- 将
$ARGUMENTS 作为 feature 名称唯一入参来源
2. 选择目标域
先读取:
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 询问一次。
3. 检查已有文件
检查 .ai/prd/<domain>/[feature].md 和 docs/prd/<domain>/[feature].md:
- 草稿不存在且正式 PRD 不存在 → create 路径
- 草稿不存在但正式 PRD 存在 → draft-from-published 路径
- 草稿已存在 → update 路径
4. 收集信息
如已存在 .ai/decision/$ARGUMENTS.md,先从中提取目标用户、问题陈述、范围方向、已确认产品决策、仍阻塞 PRD 的问题和给 PRD 的 Handoff。若 Verdict 不允许继续进入 PRD,停止并提示回到 /t-decision。
如已存在 .ai/tech-research/$ARGUMENTS.md,再从中提取技术需求(§1.2)、代码库评估(§2)、影响分析(§5)和 PRD 建议(§7)。
仅当上下文无法可靠推断时,用 AskUserQuestion 补齐:
- 功能目标与范围边界
- 相关角色(优先使用仓库既有体系,如 Admin Realm、Regular User 等)
- 关键依赖或前置能力
以下信息优先从现有文档和代码推断,不作为默认提问项:
- 是否需要后端 API → 从技术研究报告或代码结构推断
- 是否需要前端实现 → 从技术研究报告或代码结构推断
如需新建 user story,额外确认:
- 目标用户价值
- 至少 1 个主验收场景
- 默认优先级(P0/P1/P2)
5. 执行 PRD 前置澄清门禁
基于已收集信息建立临时 PRD Grill Snapshot,并按"PRD 前置澄清门禁"检查是否满足最低条件。
不得:
- 把 Snapshot 原文写入 PRD
- 把未确认的 open question 写成 PRD 决策
- 为追求完整性持续追问非阻塞细节
- 询问仓库中可直接查明的事实
6. 检查、补齐并关联 user story
读取:
docs/user-stories/00-index.md、_README.md、_roles.md
${CLAUDE_PLUGIN_ROOT}/guides/product/index.md 和 user-story.md
- 搜索
docs/user-stories/**/*.md、.ai/user-stories/**/*.md、docs/prd/**/*.md 和 .ai/prd/**/*.md
执行:
- 已存在足够覆盖的 user story → 直接引用,不重复创建
- 缺少少量场景 → 写入或追加
.ai/user-stories/<domain>/<feature>.md
- 已有同名 draft user story → 在其中追加合适章节,不重建
- 从已有草稿/正式 PRD 提取交叉引用和已有能力边界
新增 user story 必须遵循 ${CLAUDE_PLUGIN_ROOT}/guides/product/user-story.md 的结构和 GWT 风格验收标准,使用 user-story-template.md。
补齐后仍不够 → 继续生成 PRD 草稿,在文档中标记"待补充用户故事"。
7. 生成 PRD 草稿
create 路径使用 template.md;draft-from-published 和 update 路径按核心约束中的"更新行为"逐章处理。
写入 .ai/prd/<domain>/[feature].md,至少包含:
- 相关用户故事、范围界定、需求概述、业务规则与状态
- 功能需求、验收目标
- API 相关约束 / 前端交互约束(各标明适用或不适用)
- 已确认决策、参考资料
不适用的章节保留并标记"不适用"。如需技术细节,建议执行 /t-design。
8. 人机迭代
如果用户基于 PRD 草稿提出修改意见:
- 表达方式调整 → 更新 Markdown PRD 草稿
- 产品语义调整 → 更新 Markdown PRD 草稿,并同步必要的 draft user story
- 与既有 Decision Brief、正式 PRD 或 user story 冲突时,以用户最新确认的意图为准,并在草稿中记录覆盖关系
9. 收尾
完成后明确说明:
- user story 文件路径和变更方式(新增/追加)
- 若本轮产生 draft user story,说明其为
.ai/user-stories 候选来源,需在 /t-prd-publish 阶段合并到 docs/user-stories
- PRD 草稿路径、所属域
- 本次走 create、draft-from-published 还是 update
- 需要重点补充或确认的部分
- 待确认项:明确说明"无"或以对话形式列出,不写入 Markdown PRD
- 下一步:高风险或复杂需求建议先运行
/t-prd-check [feature];简单需求可直接执行 /t-design [feature]。若检查发现问题,修复后可再次运行 /t-prd-check [feature]
推断部分需在收尾对话中显式列出:哪些来自现有文档、哪些来自当前对话、哪些仍待确认;未确认内容不写入 Markdown PRD。
失败处理
- 缺失 feature → 直接失败并提示参数
- 目标域无法判断 → 提示选择
auth|billing|core|integration
- 文件无法写入 → 终止并报告
- user story 信息不足 → 先补问;仍不足则继续,PRD 中标记缺口
- Decision Brief 阻塞 PRD → 终止并提示
/t-decision [feature]
质量门禁
- 新增 PRD 草稿前应尽量具备可引用的 user story
- PRD 草稿内容边界以"核心约束"一节为准
- 新草稿创建后建议按风险决定是否运行
/t-prd-check [feature]
附加资源