Menu
Write PRD, 写产品需求文档。Use when: 需要写新功能 PRD（有UI/无UI）、第三方集成、功能重构、性能/安全优化需求。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| 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 应该：
以下输入应触发此技能：
从 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 测试失败原因 - 排查问题、查看日志、定位根因