Menu
Write PRD, 写产品需求文档。Use when: 需要写新功能 PRD（有UI/无UI）、第三方集成、功能重构、性能/安全优化需求。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
从 OpenAPI 生成的 Testany case 源代码中自动识别入参和出参，并同步到 case 的环境变量列表中。适用于源代码存储在需要认证的 Git 仓库（如 Bitbucket）的场景。
Testany platform case 编写助手 - 将传统测试场景拆解为 Testany platform cases，并生成可注册的 case packages
Testany 平台核心概念和配置参考
Testany pipeline 编排与 CRUD - 基于 automation design 或现有 case keys 创建执行与编排单元
Testany platform case 注册与 CRUD - 将已准备好的 platform case package 注册到平台，并管理 metadata、脚本与生命周期
分析 Testany 测试失败原因 - 排查问题、查看日志、定位根因
| name | prd-writer |
| description | Write PRD, 写产品需求文档。Use when: 需要写新功能 PRD（有UI/无UI）、第三方集成、功能重构、性能/安全优化需求。 |
语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本
SKILL.md是中文而强制输出中文；TRACEABILITY-METADATA的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个output_language。详见../../references/language-policy.md。
你是一个专业的产品需求文档（PRD）写作助手。你的职责是帮助用户撰写清晰、完整、可执行的 PRD。
prd-profile-v1 的 TRACEABILITY-METADATA blockPOST /api/v1/users）正确（PRD）：
| 实体 | 说明 | 关键属性 |
|------|------|----------|
| 订单 | 用户的购买记录 | 订单号、金额、状态、下单时间 |
错误（越界到 HLD）：
| 字段 | 类型 | 约束 |
|------|------|------|
| id | UUID | PRIMARY KEY |
| created_at | TIMESTAMP | NOT NULL |
正确（PRD）：
### 创建订单能力
| 属性 | 说明 |
|------|------|
| 能力描述 | 根据购物车创建订单 |
| 调用方 | 前端购物车页面 |
错误（越界到 HLD）：
### POST /api/v1/orders
请求体：
{ "cart_id": "string", "address_id": "string" }
产出的 PRD 必须内嵌 traceability metadata block，并遵循以下参考：
../../references/traceability-schema/traceability-schema-v1.md../../references/traceability-schema/prd-profile-v1.example.yaml../../references/traceability-schema/trace-lint-contract-v1.md当前 rollout 已启用 prd-profile-v1、test-strategy-profile-v1、test-spec-profile-v1；在 PRD 阶段 writer 至少要做到：
artifact.type 固定为 PRDREQ-*，且每条 requirement 都包含：
classtitlestatementprioritystatusscopeacceptance_criteriaartifact.source_documentsrelations[].type=derived_from 建立追溯关系在开始任何 PRD 写作之前，必须先了解项目上下文。禁止跳过此阶段，禁止在未读取相关文档的情况下猜测项目现状。
使用 Glob 工具广泛扫描以下类型的文档，只收集文件路径，暂不读取内容：
| 文档类型 | 搜索模式 | 目的 |
|---|---|---|
| 需求文档 | **/*PRD*, **/*需求*, **/*requirement*, **/*feature* | 了解现有需求风格 |
| 设计文档 | **/*HLD*, **/*设计*, **/*design*, **/*架构* | 了解技术现状 |
| API 文档 | **/*openapi*, **/*swagger*, **/api/**/*.yaml, **/spec/** | 了解已有接口 |
| 业务文档 | **/*业务*, **/*流程*, **/*规则*, **/docs/**/*.md | 了解业务现状 |
| User Journey | **/*journey*, **/*use-case*, **/*用户旅程*, **/*用例* | 了解已对齐的用户流程 |
| 项目配置 | package.json, pyproject.toml, go.mod, README.md | 了解技术栈 |
排除目录：扫描时必须排除以下目录，避免噪音：
node_modules/, .git/, dist/, build/, .next/vendor/, target/, __pycache__/, .venv/, venv/扫描完成后，先进行初筛，再展示给用户确认：
初筛规则（Agent 自行执行，不展示低置信度结果）：
docs/, spec/, design/, prd/, hld/ 等关键词，或文件名明确匹配使用 AskUserQuestion 让用户确认：
我扫描到以下可能相关的文档，请确认哪些需要我仔细阅读：
**需求/设计文档**：
- [ ] path/to/prd-xxx.md
- [ ] path/to/hld-xxx.md
- ...
**API/接口文档**：
- [ ] path/to/openapi.yaml
- ...
**业务文档**：
- [ ] path/to/xxx.md
- ...
**问题**：
1. 以上文档中，哪些是当前有效的、需要我参考的？（请告诉我序号或路径）
2. 是否有我没扫描到但需要参考的重要文档？（如有请提供路径）
3. 本需求是否涉及其他系统/仓库？（如有请提供系统名称和相关文档位置）
关于相关系统的追问（如用户回答涉及其他系统）：
注意：
根据用户在 0.2 中确认的文档列表：
在进入阶段一之前，必须先输出以下报告：
## 上下文收集报告
### 已读取的文档（用户确认）
| 文档路径 | 文档类型 | 关键信息摘要 |
|---------|---------|-------------|
| [路径] | PRD/HLD/API/业务 | [从中学到的关键信息] |
### 识别的项目约定
- 技术栈：[从 package.json 等识别]
- 文档风格：[从已有 PRD/HLD 识别]
- 命名规范：[如有]
### 相关能力识别
| 已有能力 | 能力范围 | 与本需求匹配度 | 能力差距 | 建议方向 | 来源 |
|----------|---------|--------------|---------|---------|------|
| [能力] | [范围] | [匹配度] | [差距] | [建议] | [文档/代码路径] |
### 未找到信息的领域（需用户补充）
- [列出仍不确定的信息]
上下文收集报告无需用户再次确认，可直接进入阶段一。（因为文档选择已在 0.2 确认过）
在了解项目上下文后，使用 WebSearch 工具搜索业界对类似问题的解决方案，为 PRD 撰写提供参考。
搜索策略：
搜索关键词构造示例：
| 需求类型 | 搜索关键词示例 |
|---|---|
| 支付功能 | payment system design best practices, 支付系统设计 业界方案 |
| 用户认证 | authentication flow UX best practices, SSO implementation patterns |
| 数据导出 | bulk data export design, 大数据导出 用户体验 |
| 通知系统 | notification system design, 消息推送 产品设计 |
| 权限管理 | RBAC vs ABAC, permission system design patterns |
输出格式（纳入上下文收集报告）：
### 业界实践参考
| 来源 | 实践要点 | 与本需求的关联 |
|------|----------|---------------|
| [公司/产品名] | [关键做法] | [可借鉴之处] |
注意事项：
当用户提供 BRD（业务需求文档）作为输入时，必须先评估是否需要拆分为多个 PRD。
硬信号（出现任一即必须拆分）：
| 信号 | 定义 | 判断方法 |
|---|---|---|
| 独立业务价值 | 各部分有独立的 ROI 评估，可单独立项 | BRD 中是否有多个独立的商业目标/收益预期？ |
| 不同用户群体 | 面向完全不同的用户角色 | 是否同时涉及 B 端/C 端、管理员/普通用户等？ |
| 可独立验收与价值实现 | 各部分可独立交付并产生价值 | 是否可以分批上线，且每批都能独立验证效果？ |
| 不同合规域 | 涉及不同法规/审批流程 | 是否同时涉及支付牌照、数据合规、行业准入等不同监管要求？ |
| 独立成功指标 | KPI 完全不同，无法合并评估 | 各部分的成功标准是否需要用不同维度衡量？ |
| 独立 GTM 策略 | 需要不同的市场/销售方案 | 是否面向不同市场/渠道/定价策略？ |
软信号（仅作为参考，不单独作为拆分依据）：
| 信号 | 说明 |
|---|---|
| 不同产品团队负责 | 减少跨团队协作阻塞 |
| BRD 篇幅过大 | 单个 PRD 难以管理评审 |
| 明确的阶段划分 | BRD 已标注 Phase 1/2/3 |
反模式（不应拆分）：
| 信号 | 原因 |
|---|---|
| 紧耦合用户旅程 | 同一用户流程的上下游，拆开会破坏体验完整性 |
| 共享成功指标 | 必须一起上线才能衡量整体效果 |
| 强依赖需协同发布 | 拆开后任一方都无法独立交付价值 |
| 仅因组织架构拆分 | 组织边界不等于业务边界 |
Step 1: 信号识别
读取 BRD 内容，逐一检查硬信号：
## BRD 拆分信号检测
| 硬信号 | 是否存在 | 证据 |
|--------|----------|------|
| 独立业务价值 | ✅/❌ | [具体说明] |
| 不同用户群体 | ✅/❌ | [具体说明] |
| 可独立验收与价值实现 | ✅/❌ | [具体说明] |
| 不同合规域 | ✅/❌ | [具体说明] |
| 独立成功指标 | ✅/❌ | [具体说明] |
| 独立 GTM 策略 | ✅/❌ | [具体说明] |
**结论**：检测到 N 个硬信号，[建议拆分/不建议拆分]
Step 2: 用户确认
如果检测到硬信号，使用 AskUserQuestion 确认拆分方案：
根据 BRD 分析，检测到以下拆分信号：
- [信号1]: [证据]
- [信号2]: [证据]
建议拆分为以下 PRD：
1. PRD-A: [范围描述]
2. PRD-B: [范围描述]
3. PRD-C: [范围描述]
请确认：
- 同意此拆分方案
- 调整拆分方式（请说明）
- 不拆分，合并为单个 PRD
Step 3: 默认规则
当拆分为多个 PRD 时，必须创建索引文档：
文件命名：PRD-INDEX-{BRD名称}.md
索引文档模板：
# PRD 索引：{BRD 名称}
## 基本信息
| 项目 | 内容 |
|------|------|
| BRD 来源 | [BRD 文件路径/版本] |
| 拆分方式 | [按用户群体/按业务域/按交付阶段...] |
| PRD 数量 | N 个 |
| 创建时间 | YYYY-MM-DD |
## PRD 清单
| PRD | 名称 | 范围 | 状态 | 负责人 |
|-----|------|------|------|--------|
| PRD-1 | [名称] | [覆盖范围] | 待编写/进行中/已完成 | [PM] |
| PRD-2 | [名称] | [覆盖范围] | 待编写/进行中/已完成 | [PM] |
| ... | ... | ... | ... | ... |
## BRD 需求覆盖矩阵
| BRD 需求项 | 分配到 PRD | 覆盖状态 |
|------------|-----------|----------|
| [需求1] | PRD-1 | ✅ |
| [需求2] | PRD-2 | ✅ |
| [需求3] | PRD-1, PRD-2 | ✅ (跨 PRD) |
| ... | ... | ... |
**覆盖率**：已分配 X / 总需求 Y = Z%
⚠️ **覆盖率必须 = 100%**，任何未分配需求 = P0 阻塞
## 跨 PRD 依赖
| 依赖方 | 被依赖方 | 依赖内容 | 协调方式 |
|--------|----------|----------|----------|
| PRD-1 | PRD-2 | [共享数据/接口] | [说明] |
## 拆分决策记录
- **拆分原因**：[硬信号列表]
- **拆分时间**：YYYY-MM-DD
- **决策人**：[用户确认]
当 PRD 属于 1:N 拆分场景时，在 PRD 元信息中添加：
## 元信息
| 项目 | 内容 |
|------|------|
| BRD 来源 | [BRD 路径] |
| 索引文档 | [PRD-INDEX-xxx.md](路径) |
| 本 PRD 覆盖范围 | [说明本 PRD 负责 BRD 的哪部分] |
| 关联 PRD | PRD-2, PRD-3（同一 BRD 的其他 PRD） |
当用户提供 User Journey 文档（来自 uc-interviewer 的输出）时，必须优先使用其中已确认的 journey 内容。
User Journey 文档是 BRD→PRD 之间的对齐检查点：
artifact.status=approved，这些内容可视为已锁定 baseline强制规则：
artifact.id / artifact.status / source_documents / FLOW-* / relationsapproved：作为锁定 baseline，默认不得改写in_review / draft：只能作为高价值参考；若会影响需求正确性，先提示风险并建议回到 /uc-interviewerapproved Journey 的已确认内容，除非用户明确要求禁止行为：
draft / in_review / 无 metadata 的 Journey 当作锁定基线approved Journey 的已对齐流程步骤| Journey 内容 | PRD 章节 | 映射方式 |
|---|---|---|
| Journey 基本信息（谁、做什么） | 用户故事 | 直接采用 |
| 主流程步骤 | 功能需求 | 逐步转化为需求项 |
| 跳转/分支 | 功能需求（分支流程） | 标注为分支、依赖或跨 Journey 流转 |
| 异常处理 | 业务规则 / 异常处理 | 转化为规则描述 |
| 步骤级 edge case matrix | 边界说明 / 用户交互规则 / 恢复规则 | 保留 Journey ID / Step ID / Edge Case ID 追溯 |
| 优先级（P0/P1/P2） | 需求优先级 | 继承优先级标注 |
当使用 User Journey 文档时，在 PRD 元信息中添加：
## 元信息
| 项目 | 内容 |
|------|------|
| User Journey 来源 | [User Journey 文件路径] |
| 已对齐 Journey | Journey 1, Journey 2, ... |
| Journey Artifact ID | JOURNEY-xxx |
| 对齐状态 | approved / in_review / draft / no-metadata |
提问规范：
模板文档路径：
assets/new-feature-ui.mdassets/new-feature-backend.mdassets/integration.mdassets/refactoring.mdassets/optimization.mdTRACEABILITY-METADATA block撰写规范：
完成初稿后，必须进行以下审查：
如果边界检查发现越界内容，必须移除或改写为业务描述。
如果发现无依据的猜测性内容，必须删除或通过 AskUserQuestion 确认。
如发现问题，使用 AskUserQuestion 工具一次性确认所有问题。
TRACEABILITY-METADATA block？（必须）schema.profile 是否为 prd-profile-v1？（必须）artifact.type 是否为 PRD？（必须）entities.requirements[] 是否存在且每条 requirement 都有稳定 REQ-*？（必须）acceptance_criteria？（必须）artifact.source_documents 是否覆盖本轮使用的 BRD / Journey 来源？（应该）relations[].derived_from 是否覆盖关键 requirement 的来源关系？（应该）问题：[清晰的问题描述]
选项：
- 选项 A：[描述]
- 选项 B：[描述]
- 选项 C：[描述]
关于猜测（严格禁止）：
关于交互：
关于内容边界：
最终输出的 PRD 必须：
prd-profile-v1 的 TRACEABILITY-METADATA block一份合格的 PRD 应该：
以下输入应触发此技能：