soia-dev-design-draft-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 链接通过仓库审计。
• 内容：用一句虚构需求检查能生成八个必需章节，并将未知信息标为假设或开放项。
• 安全：提交前扫描私有路径、凭据和不应出现的专属术语。