soia-team soia-dev-design-draft-prd
将模糊的互联网产品想法转化为可评审的产品需求文档（PRD）。输入可以是一句话需求或已有材料；输出是明确标注假设、范围和待决事项的 PRD 草稿，而非未经验证的实现承诺。
客户可读说明
这个技能可以做什么
| 客户想要 | 技能会做 | 客户能看到 |
|---|---|---|
| 把一句话想法变成 PRD | 用最少的追问引导补全关键上下文，并显式记录未知项 | 一份带假设和开放项的 PRD 草稿 |
| 整理已有需求材料 | 归纳问题、目标、用户故事、范围和验收条件 | 可评审的结构化需求清单 |
| 为需求评审做准备 | 检查范围边界、可验证性、依赖和风险 | 评审问题、里程碑建议与风险表 |
客户如何使用
直接描述产品机会、目标用户、要解决的问题或预期结果；也可提供已有访谈摘要、需求笔记或约束。示例：为 ExampleCorp 的示例产品起草一个 PRD：让新用户在移动端完成首次任务。
若输入只有一句话，先提出不超过五个、按影响排序的问题，优先确认目标用户、问题证据、成功指标、约束和上线窗口。客户暂时无法回答时，使用清晰的“假设”占位继续起草，不把假设写成事实。
依赖与安装
这是纯方法论技能，无强依赖、可选工具依赖或私有配置；不读取公司知识库，不执行代码、数据或远端系统操作。
claude plugin marketplace add soia-team/soia-open-skills
claude plugin install soia-dev-design@soia
只要这一个技能时，可用 npx 路线。注意技能会落进共享真源 ~/.agents/skills；若同时装了插件，同一技能会出现两份索引且各自漂移，建议二选一：
npx skills add soia-team/soia-open-dev-design-skills -g -a '*' -s soia-dev-design-draft-prd -y
配置约定采用 schema v2：~/.config/soia-skills/soia-dev-design-draft-prd/config.yml。本技能默认无需创建该文件；如客户希望长期复用文档模板、术语表或默认交付格式，可在其自有配置中定义，且不得放入凭据或私密业务资料。
工作流程
WorkBuddy 的装载单位是角色化专家而不是插件，npx skills add -a '*' 覆盖不到它，需要单独安装，见 docs/install/workbuddy.md。
1. 建立需求边界
复述已知需求，并区分看到的事实、合理推断和未验证假设。确认交付的是草稿而不是立项、排期或研发承诺；没有客户授权时，不代表客户作出商业、合规或发布决定。
2. 补全最关键的信息
从以下维度选择信息缺口最大的项目提问：目标用户与使用场景、当前问题及证据、业务目标与成功指标、时间/平台/合规约束、已有能力和明确排除项。避免为填满模板而提问；已能合理假设的低风险细节放入开放项。
3. 起草问题、目标和边界
以用户问题而非预设功能开篇。目标应包含可观察的结果或衡量方式；非目标应排除相邻但容易被误解为本次范围的事项。若没有基线数据，写明待采集的指标和采集方式，不虚构数值。
4. 定义用户故事和功能范围
为每个核心场景写出“作为 <用户>，我想要 <动作>，以便 <结果>”。按必须、应该、可选或明确不做分层功能范围；说明关键流程、异常路径、权限/状态边界和跨团队依赖。功能描述聚焦可观察行为，避免预先锁定技术实现。
5. 编写可验收的条件
为每项必须范围定义可独立核验的验收标准，覆盖正常路径、关键失败路径和边界条件。使用可观察的前置条件、动作和结果；“体验良好”或“性能快”之类表述必须改成可验证的指标，或列为待定。
6. 规划里程碑、风险与开放项
里程碑按可验证结果组织，例如“需求确认”“原型验证”“可用版本”“上线复盘”，不编造日期、资源或承诺。将风险写成“触发条件—影响—缓解/验证动作”；把未决问题单列，标明建议负责人或所需证据。
7. 自检与交付
从反面检查：目标是否能被功能范围支持、非目标是否防止范围蔓延、每个必须功能是否有验收标准、每个事实是否有来源或被标为假设。交付前删除重复描述和未经证实的断言，并说明需要客户确认的内容。
输出契约
默认以 Markdown 输出，包含以下章节；客户要求的内部模板可改变排版，但不得省略不确定性标识：
# <产品/功能名称> PRD
## 背景与问题
## 目标与非目标
## 目标用户与场景
## 用户故事
## 功能范围
## 验收标准
## 里程碑
## 风险与缓解
## 开放项与假设
- 背景与问题：只陈述客户提供的事实或标注为假设的判断。
- 目标与非目标：目标含成功信号；非目标明确本次不处理的范围。
- 用户故事、功能范围和验收标准：相互可追溯；必须范围均有至少一个验收条件。
- 里程碑：以成果和确认点描述，不在缺乏依据时承诺具体日期或人力。
- 风险开放项：每项包含影响、下一步验证或决策信息；未知项不伪装成结论。
私密信息与中间数据
- 仅使用客户在当前对话或明确授权材料中提供的需求信息；不读取、推测或复述任何未授权的公司知识库、账号资料或个人数据。
- 默认仅在对话中生成草稿，不写入本地磁盘。客户要求保存时，写入客户指定的位置；草稿中的联系人、真实业务数据和附件链接须按客户要求脱敏。
- 本技能不需要凭据，也不记录运行状态、缓存或临时数据。若客户自建配置，配置中仅保存非敏感格式偏好，保留期由客户控制。
日志与完成回执
最终回复应简要说明：已使用的输入范围、提出或采用的假设、生成的 PRD 章节、未解决的开放项，以及建议的下一步（例如确认指标或评审范围）。不得声称完成用户研究、技术评估、合规评审或上线决策，除非客户另行提供了相应证据。
质量与安全边界
- 使用通用互联网产品实践和虚构示例；不依赖任何组织专属术语、系统、流程或数据。
- 不虚构用户研究、市场数据、指标基线、客户承诺、排期或法律结论。
- 涉及隐私、安全、支付、医疗、金融或监管要求时，标为待专业评审的风险，不提供替代专业意见。
- 输出是需求沟通材料；实施方案、技术架构、项目排期和发布授权须由相应负责人另行确认。
Agent Metadata
agents/openai.yaml 仅提供界面展示和示例提示；所有可移植的执行要求以本文件为准。
验证
- 静态：确认 frontmatter、目录结构和 Markdown 链接通过仓库审计。
- 内容：用一句虚构需求检查能生成八个必需章节，并将未知信息标为假设或开放项。
- 安全：提交前扫描私有路径、凭据和不应出现的专属术语。