requirement-analysis

name	requirement-analysis
description	结构化需求澄清与优先级评估：判断需求形态（Full PRD / One-Pager / Quick Brief）、6 问澄清、RICE + MoSCoW 评估；Full PRD 移交 prd-writer，中小需求输出轻量需求摘要
when_to_use	用于把模糊需求 / 业务想法澄清到"可以决定做不做、做多大、先做哪个"时调用。 典型触发："分析需求 X" / "对齐范围" / "这个需求值不值得做" / "RICE 评估" / "优先级排序"。 不用于：正式 PRD 写作（用 prd-writer，章节结构读项目 PRD 框架 .claude/skills/prd-style/）/ 用户反馈分析（用 user-feedback-analysis）/ 竞品调研（用 competitive-analysis）/ 拆解为子任务（用 feature-breakdown）。
user-invocable	true
allowed-tools	["Read","Write","Edit","Glob","Grep"]

需求澄清与评估技能

本 skill 只负责"想清楚"：要不要做、做多大、先做哪个。正式 PRD 的工作流与写作纪律唯一来源是 prd-writer（章节结构与风格读项目 PRD 框架 .claude/skills/prd-style/），本 skill 不含 PRD 文档模板；轻量产出（One-Pager / Quick Brief）同样遵循 prd-writer writing-guide.md 通用纪律（精简表达一目了然 / 分点分段 / 模型疑问当场向用户确认，不自行归档）与项目框架的编号习惯（默认无 FR-x、BR-x 编号 / 不设非功能章）；写作分级见 skill: document-norms §11——需求摘要按 A 类，评估/论证段按 B 类（结论先行 + 分层展开，不设字数约束）。

第一步：识别需求形态

形态	适用场景	开发量	去向
Full PRD	复杂功能，涉及多角色 / 多模块 / 前后端交互	≥1 周	澄清 + 评估完成后移交 prd-writer 走完整流程
One-Pager	中型功能，范围明确	2-5 天	本 skill 输出轻量需求摘要
Quick Brief	小型迭代、配置变更、文案调整	≤1-2 天	本 skill 输出问题 + 方案 + AC（≤1 页）

不确定时倾向升一级处理。

第二步：结构化澄清（6 问）

填写任何产出前，先用以下 6 条核心问题澄清需求：

1. 这个需求解决谁的什么问题？
2. 不做这个需求的代价是什么？
3. 用户目前如何绕过这个问题？
4. 成功的样子是什么？如何衡量？
5. 有哪些已知的约束条件（技术 / 时间 / 预算）？
6. 这个需求影响哪些现有功能？

疑问处理纪律：

• 影响文档方向或范围的关键疑问 → 先向用户提问，收到答复再继续
• 次要疑问用 [待确认: {说明}] 占位，产出前汇总一次性问清；严禁编造内容
• 用户明确说"你看着填"时才允许 [待确认] 留入产出物（与 writing-guide「待确认项」准入一致）

第三步：优先级评估（按需）

RICE 计分

维度	评分	说明
Reach（影响范围）	{N} 用户/季度	{说明}
Impact（影响程度）	0.25/0.5/1/2/3	{说明}
Confidence（置信度）	50%/80%/100%	{说明}
Effort（工作量）	{N} 人周	{说明}

RICE 得分 = Reach × Impact × Confidence / Effort

MoSCoW 分类

Must have（必须做）/ Should have（应该做）/ Could have（可以做）/ Won't have（不做）

综合优先级：P0 / P1 / P2 + 建议迭代

第四步：产出

Full PRD → 移交 prd-writer

输出一段澄清结论（形态判断 + 6 问答案摘要 + 优先级结论 + 已拿到的用户拍板），作为 prd-writer S1 的输入；不在本 skill 内写任何 PRD 章节。

One-Pager 轻量模板

# {需求名} — One-Pager

## 背景与目标
- 现状：{一句}
- 痛点：{一句；可多条}
- 目标：{一句}
- 边界：{真边界，如有}

## 方案
1. **{要点 1}**：{一两句}
2. **{要点 2}**：{一两句}

## 验收标准
{AC-序号 + GWT / 规则式清单，格式见 acceptance-criteria skill}

## 优先级
RICE {N} · MoSCoW {分类} · 建议 {排期}

Quick Brief 模板

# {需求名} — Quick Brief

- 问题：{一句}
- 方案：{分点}
- 验收：{1-3 条 AC}

完成度核查清单

• 问题陈述清晰，团队成员理解一致
• 成功指标可量化（或明确说明不可量化的原因）
• 功能范围已明确边界（做什么 + 真边界）
• 所有需求条目可测试
• [待确认] 已全部向用户问清（仅用户明确授权保留的除外）

执行步骤

1. 判断需求形态（Full PRD / One-Pager / Quick Brief）
2. 执行 6 问澄清，识别关键不确定项；关键疑问先问用户，次要疑问 [待确认] 占位
3. 按需执行 RICE + MoSCoW 评估
4. 按形态产出：Full PRD 输出澄清结论并移交 prd-writer；One-Pager / Quick Brief 按上述模板在响应消息中呈现完整内容
5. 执行完成度核查清单
6. 收到用户确认信号后落盘：

   • 早期需求探索 / 一句话需求 / Quick Brief / One-Pager：写入 projects/modules/<basic>/<sub>/requirements/_draft/<slug>.md（草稿区；属于 @pm 输出根目录范畴，可直接落盘）。即使是草稿，也需 minimal frontmatter：type: concept + module: <basic>/<sub> + owner_role: pm + updated: <ISO-8601 带时区，见 document-norms §2.7> + status: draft（缺 frontmatter 的草稿不会被 librarian / module-index-refresh 扫到，等于知识黑洞）

   • Full PRD / 已立项需求：接 prd-writer skill 走完整 PRD 流程到 projects/modules/<basic>/<sub>/requirements/<req_slug>/<sub_req_slug>/prd.md（首次默认子需求 main/）；如对应子模块/需求资产包未建，先调 module-init 创建骨架

   • 文档归属与 frontmatter 字段标准查 skill: document-norms §1 §2

   • board.yaml 任务条目仅输出草稿到响应中，不直接写 board.yaml。落盘由用户/主 Claude 调用 task-management skill 执行（与 agents/pm.md "由用户确认后由主 Claude 落盘"边界对齐）；task 草稿必填二段式 module: <basic>/<sub>；挂需求的 req_slug + sub_req_slug 一起填（main 也显式写）

   • 草稿格式（必填二段式 module + 可选 req_slug / sub_req_slug / affected_modules）：

     # 待落盘的 board.yaml task 条目草稿
     - id: "TASK-<下一个序号，由 task-management 分配>"
       title: "..."
       assigned_to: "..."
       priority: "..."
       tags: ["..."]
       module: "<basic>/<sub>"