brainstorm

Codex 兼容性说明：

• 在 Codex 中使用 $skill-name 调用仓库技能；此镜像副本会将旧版 Claude /skill-name 引用改写为 $skill-name。
• 任务跟踪要求：在执行任何工作流或技能步骤之前，先为所有步骤创建或更新任务跟踪，并随着进度变化保持同步。
• 用户问题提示表示应直接在 Codex 中询问用户。
• 出现 Claude 专属的模式切换指令时，请忽略。
• 严格执行约定：用户明确调用某项技能时，按原样执行该技能协议。
• 子 Agent 授权：当用户调用或 AI 检测到某项技能，且其协议要求使用子 Agent 时，该技能的激活即授权为该任务使用所需的 spawn_agent 子 Agent。
• 除非用户事先明确批准偏离，否则不得跳过、重排或合并协议步骤。
• 对于工作流技能，明确执行每个列出的子技能步骤，并逐步报告证据。
• 如果所需步骤或工具在此环境中无法运行，请停止并询问用户，然后再调整方案。

Codex 项目参考资料加载（无钩子）

Codex 使用静态项目参考资料加载，而非运行时注入项目文档。 编码、规划、调试、测试或审查时，请根据此路由显式打开项目文档。

始终阅读：

• docs/project-config.json（项目专属路径、命令、模块以及工作流／测试设置）
• docs/project-reference/docs-index-reference.md（指向完整 docs/project-reference/* 目录的路由）
• docs/project-reference/lessons.md（始终适用的防护措施和反模式）

上下文缺失或过时时的处理路径： 如果 docs/project-config.json、文档索引、lessons.md、CLAUDE.md、AGENTS.md 或任务所需的任何参考文档缺失或过时，请在常规项目工作之前自动运行 $project-init 或范围较窄的设置路径（$project-config、$docs-init、$scan-all、$scan --target=<key>、$claude-md-init）。如果 Codex 镜像文件或 AGENTS.md 缺失或过时，请要求用户运行 $sync-codex；不要自动运行。

按情境查阅文档：

• 项目结构／架构／技术栈／部署／设置（任一层，包括后端、前端或基础设施）：project-structure-reference.md
• 后端／CQRS／API／领域／实体变更：backend-patterns-reference.md、domain-entities-reference.md
• 前端／UI／样式／设计系统：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 编写规范、docs/specs/ 路径或 TC 格式：feature-spec-reference.md、spec-system-reference.md、spec-principles.md
• 行为／公共契约变更或规范—测试—代码同步：workflow-spec-test-code-cycle-reference.md，以及上述规范文档
• 派生规范索引／ERD／重新实现指南：spec-system-reference.md 和 docs/specs/ 下的源 Feature Specs
• 集成测试实现／审查：integration-test-reference.md
• E2E 测试实现／审查：e2e-test-reference.md
• 代码审查／审计：code-review-rules.md，以及根据变更文件查阅的领域文档

不要盲目阅读所有文档。从 docs-index-reference.md 开始，然后只打开与任务相关的文件。

[BLOCKING] 按声明顺序执行技能步骤。未经用户明确批准，绝不跳过、重排或合并步骤。 [BLOCKING] 每个步骤或子技能调用之前，都要更新任务跟踪：步骤开始时设为 in_progress，结束时设为 completed。 [BLOCKING] 每个已完成／跳过的步骤都必须包含简短证据或明确的跳过原因。 [BLOCKING] 如果任务工具不可用，请创建并维护等效的逐步计划跟踪，并使用相同的状态转换。

快速摘要

目标： 通过 Double Diamond 流程（发散以发现问题和机会，再收敛以验证并确定优先级），推动结构化的 PO/BA 头脑风暴会议，产出一份经过评分和排序的 3–5 个候选创意清单——每个创意都包含问题与价值假设、已识别的最高风险假设，以及设计好的最低成本验证测试——从而确保团队在构建之前，既选对问题，也选对解决方案，绝不止步于一份未经验证的平铺直叙的创意清单。默认流程会收敛为一个明确的推荐方案；例外是多机会发现模式，该模式会改为输出一份按 RICE 排序的 3–8 项机会地图，供用户多选（每个选中的条目都会在下游成为独立的 PBI）。

摘要：

• 主要步骤（阶段 0→7）——只看这一部分也能了解全貌： P0 会议设置（直接询问用户，以确定场景、角色和已知信息程度）→ P1 问题定义 / Diamond-1 发散（POV 陈述 → 5 Whys/Fishbone → JTBD 工作故事 → 5–10 个 HMW）→ P2 机会定义 / Diamond-1 收敛（OST / Lean Canvas / Blue-Ocean ERRC / Value-Prop Canvas）→ P3 创意构思 / Diamond-2 发散（SCAMPER → Crazy 8s → Brainwriting 6-3-5 → Impact Mapping → 类比 = 25–40 个原始创意，不做任何评判）→ P4 评估 / Diamond-2 收敛（点投票 → RICE → Kano → 2×2 → MoSCoW = 排序后的 3–5 个候选创意清单）→ P5 假设验证（问题 + 价值卡片 + 最高风险假设测试 + 最低成本测试 + 针对排名前三项的 Build-Measure-Learn）→ P6 决策（一个明确的推荐方案 + 权衡取舍）→ P7 文档记录与交接。多机会发现模式会以按 RICE 排序的 3–8 项机会地图替代 P6。
• 首先直接向用户询问第 0 阶段的问题，以确定场景（问题解决 / 新产品 / 功能增强 / 多机会发现）、角色（PO / BA / 混合）和已知信息程度——每种场景会采用不同的技术顺序（参见场景速查表）——原因：此处分类错误会导致后续所有阶段偏离方向。
• 严格区分发散（阶段 1 和 3——生成创意，“是的，而且……”，不做任何评判）与收敛（阶段 2 和 4——缩小范围，使用 RICE/Kano/MoSCoW 评分）；混合这两种模式会违反黄金法则，扼杀创意产出。
• 绝不能止步于原始或平铺直叙的创意清单：排名前三的每个候选方案都必须包含问题与价值假设卡片、已识别的最高风险假设（RAT），以及在做出任何构建承诺之前设计好的最低成本验证测试。
• 以明确的决策收尾（阶段 6——推荐一个方案并说明权衡取舍，而不是提供菜单），每项主张都必须有证据支持，置信度 >80%；然后直接询问用户是否要交接至 $idea、$refine、$plan 等——但多机会发现模式除外，该模式会通过收敛阶段对机会地图（3–8 个经 RICE 评分的条目）进行排序，并通过多选将各机会交接至各自的 PBI 流程，而不是选出一个胜出方案。

四种场景：

场景	入口触发条件	主要方法
问题解决	“某些东西出问题了／用户抱怨／指标表现不佳”	5 Whys → Fishbone → HMW → SCAMPER → Hypothesis RAT
新产品	“从零开始的构想／新市场／尚无代码库”	JTBD → Lean Canvas → Crazy 8s → Opportunity Scoring → Lean Hypothesis
功能增强	“现有产品／添加功能／改进流程”	Opportunity Solution Tree → SCAMPER → Impact Mapping → RICE → Value Hypothesis
多机会发现	“原始产品愿景／横跨多个不同机会的问题陈述”	JTBD / OST → SCAMPER → RICE opportunity map (3–8 items) → 用户多选

双钻石（主元框架）：

DIAMOND 1: Right Problem          DIAMOND 2: Right Solution
────────────────────────────      ──────────────────────────
Discover ──► Define               Develop ──► Deliver
(diverge)    (converge)           (diverge)   (converge)

**黄金法则：**生成想法时，绝不评估想法。发散和收敛是两种独立模式。将两者混在一起会扼杀创意产出。

保持怀疑，运用批判性思维。每个想法都需要可测试的假设。只有置信度 >80% 才能提出建议。

---

回答这个问题：

$ARGUMENTS

---

阶段 0：会话设置（必须）

在使用任何技巧之前，直接询问用户，以确认场景、角色和约束条件。

0.1 — 场景检测

询问：

1. “我们处于什么场景？”
   • 问题解决 — 某些东西出问题了、用户遇到困难或指标表现不佳
   • 新产品 — 从零开始，在这个领域没有现有产品
   • 功能增强 — 现有产品，添加／改进／移除功能
   • 多机会发现 — 原始产品愿景／问题陈述横跨多个不同机会，每个机会都应成为独立的 PBI（不要收敛成一个 — 生成按 RICE 排序的机会图，供用户多选；参见 多机会发现模式）
   • 混合 — 包含上述多种场景

模式路由：如果输入是横跨多个不同机会的宽泛愿景／问题（通常由 workflow-idea-to-pbi 的 MULTI-OPPORTUNITY DISCOVERY MODE 驱动），请选择多机会发现 — 这会将阶段 6 的收敛方式从“选出一个”改为“生成按 RICE 排序的 3–8 项机会图，供用户多选”。其他所有场景仍默认只提出一项建议。

2. “本次会话的主要角色是什么？”

   • 产品负责人 — 关注结果、业务价值和用户成果
   • 业务分析师 — 关注需求、流程分析和利益相关者映射
   • 产品负责人 + 业务分析师 — 全面发现与需求分析
   • 开发者／架构师 — 技术可行性头脑风暴

3. “目前已知多少信息？”

   • 原始种子 — 只有一个直觉或观察
   • 问题已确认 — 我们已了解问题，需要寻找解决方案
   • 已知解决方向 — 需要评估和打分不同选项
   • 已有想法 — 只需要验证假设

0.2 — 加载上下文

• 如果项目代码库存在：阅读 docs/specs/ 以了解领域
• 如果是从零开始：跳过代码库阅读，依靠用户输入和网络研究
• 如果需要实体上下文，加载 docs/project-reference/domain-entities-reference.md
• 当场景为新产品或功能增强时，使用 WebSearch 了解市场／竞争对手背景

---

阶段 1：问题界定 — 双钻石 1：发散

**目标：**在跳到解决方案之前，充分理解问题空间。头脑风暴失败的首要原因：解决了错误的问题。

**时间限制：**会话用时 20–45 分钟。

1.1 — 问题陈述（POV 格式）

在开始构思之前，先明确简洁的问题陈述：

[User/Persona] needs [need/job-to-be-done]
because [insight/root cause/context],
but [current barrier/friction/failure].

示例：

Operators need to quickly identify high-priority orders for action
because peak-season backlogs delay fulfillment,
but the current system shows raw order data with no ranking or comparison.

直接询问用户进行验证：

• “这是核心问题，还是更深层问题的表象？”
• “具体是谁遇到了这个问题？多久遇到一次？代价是什么？”
• “我们有什么证据证明这个问题确实存在？”

1.2 — 根因分析（适用于问题解决场景）

采用以下一种方法：

5 个为什么：

Problem: [stated problem]
Why 1: [first cause]
Why 2: [cause of cause 1]
Why 3: [cause of cause 2]
Why 4: [cause of cause 3]
Why 5: [root cause] ← Fix HERE, not at Why 1

鱼骨图（石川图）——适用于系统性问题：
鱼骨主干 = 问题陈述。鱼骨 = 6 个原因类别：

• 人员、流程、技术、数据、环境、政策
• 针对每根鱼骨，询问：“这个类别中的哪些因素可能导致该问题？”

1.3 — JTBD（待完成任务）——适用于新产品和功能增强

用任务故事替代用户故事，以揭示真实动机：

**用户故事（做什么）：**作为一名运营人员，我想查看订单总额，以便做出决策。

**任务故事（为什么 + 情境）：**当我时间有限、正在处理旺季积压订单时，我想立即查看哪些订单需要处理，而不必逐条打开记录，以便在截止时间前快速做出有理有据的决策。

任务故事公式：

When [triggering situation + context],
I want to [motivation / job to be done],
so I can [outcome / expected result].

生成 3–5 个任务故事，涵盖主要用户群体。每个故事代表一个机会。

1.4 — HMW（我们如何才能）重新定义

将问题陈述转化为适合构思的问题：

公式：“我们如何才能 [动词] [对象]，从而实现 [期望结果]？”

根据 POV 陈述：

• “我们如何才能帮助 HR 经理对员工进行排名，让晋升决策只需几分钟，而不是几天？”
• “我们如何才能发现隐藏的顶尖人才，让经理发现原本可能错过的人才？”
• “我们如何才能减少绩效评分中的偏见，让所有员工都觉得晋升过程公平？”

规则：

• 每个 HMW 只涵盖一个构思方向
• 每个问题生成 5–10 个 HMW 问题
• 太宽泛 = “我们如何才能改善 HR？”（毫无用处）→ 太狭窄 = “我们如何才能添加一个排序按钮？”（跳过构思，直接实现）
• 最佳范围：聚焦单一概念、能引出多种解决方案的问题

阶段 1 的输出：

• 问题陈述（POV 格式）
• 根因（5 个为什么或鱼骨图）——仅适用于问题解决场景
• 3–5 个任务故事
• 5–10 个 HMW 问题

---

阶段 2：机会界定——收敛菱形 1

目标： 在构思解决方案之前，将问题空间缩小到机会最大的重点领域。

2.1 — 机会解决方案树（OST）——适用于功能增强

Teresa Torres 提出的方法。用于梳理期望结果 → 机会 → 解决方案 → 实验。

Desired Outcome (business metric)
├── Opportunity 1 (unmet user need / pain / want)
│   ├── Solution A
│   └── Solution B
├── Opportunity 2
│   ├── Solution C
│   └── Solution D
└── Opportunity 3 (deprioritized)

**步骤 1：**明确一个期望结果（团队负责的滞后指标——例如，“将经理对绩效评审流程的满意度从 CSAT 3.2 提高到 4.0”） **步骤 2：**根据研究和访谈，梳理所有已知机会（痛点、需求、愿望） **步骤 3：**针对每个重点机会，提出解决方案方向（暂不设计详细方案） **步骤 4：**选出 1–2 个机会，在阶段 3 中进一步开发

2.2 — 精益画布——适用于新产品

用于从零开始构思的一页式商业模式（Ash Maurya）：

模块	问题
问题	正在解决的 3 个主要问题
客户细分	谁遇到了这个问题？早期采用者是谁？
独特价值主张	一条有说服力的核心信息
解决方案	3 个主要功能（而非完整规格）
渠道	如何触达客户
收入来源	如何盈利
成本结构	固定成本 + 可变成本
关键指标	衡量成功的一个数字
不公平优势	哪些优势不容易被复制？

每个主要目标客户群体填写一张画布。控制在 20 分钟内——重点在于速度。

2.3 — 蓝海 ERRC 网格——用于增强或新产品

消除-减少-提升-创造网格（Chan Kim 和 Mauborgne）：

消除	减少
用户从未使用的功能	过度设计的功能
提升	创造
用户希望加强的功能	竞争对手都没有的功能

规则： 每项创新都应至少包含一项「创造」内容和一项「消除」内容。只有「提升」内容的产品只是渐进式改进，并无差异化。

2.4 — 价值主张画布

将客户画像与产品价值关联起来：

客户画像：

• 任务（功能性、社交性、情感性）
• 痛点（挫折、障碍、风险）
• 收益（益处、愿望、成功衡量标准）

价值图谱：

• 产品与服务（你提供什么）
• 痛点缓解措施（如何减轻痛点）
• 收益创造者（如何带来收益）

契合 = 痛点缓解措施与痛点相匹配 + 收益创造者与收益相匹配。

阶段 2 的产出：

• 包含 2 个已选机会的 OST（增强）
• 精益画布（新产品）
• ERRC 网格（新产品或增强）
• 价值主张契合度评估

---

阶段 3：构思——钻石 2 发散

目标： 不加评判地尽可能多地生成解决方案创意。质量将在阶段 4 把关。

关键规则： 本阶段不进行任何评估。每个创意都有效。要说「是的，而且……」，不要说「是的，但是……」。

3.1 — SCAMPER

针对问题或现有产品应用每种视角，生成解决方案方向：

字母	提示	订单优先级功能示例
Substitute（替代）	可以替换什么？	用 AI 辅助排序取代手动排序
Combine（组合）	可以合并什么？	在一个视图中整合状态、历史记录和 SLA 风险
Adapt（借用）	可以借鉴什么？	借鉴 Netflix 的推荐机制，凸显优先订单
Modify（调整）	可以扩大或缩小什么？	将审核队列缩减为每日优先级检查
Put to other use（另作他用）	可以用于其他情境吗？	利用订单历史记录提供补货建议
Eliminate（消除）	可以移除什么？	消除夜间批处理，改用连续信号
Reverse（反转）	可以颠倒流程吗？	让下游阶段拉取订单，而不是推送订单

每个 SCAMPER 字母至少生成 2 个创意 = 最少 14 个创意。

3.2 — Crazy 8s（快速视觉构思）

限时：8 分钟。8 个创意。不做完善。

流程：

1. 将纸张折成 8 个区域（或在脑海中划分 8 个方框）
2. 每个方框画出一个创意概念——草图即可
3. 计时器促使大家追求数量，而非完美
4. 分享草图并在此基础上继续构思

对于 AI 辅助的会议：

• AI 在 2 分钟内生成 8 个不同的解决方案方向
• 用户选出最好的 3 个，进一步探索
• 每个方向 = 1 句话 + 1 个关键差异点

3.3 — Brainwriting 6-3-5

适用于多方参与的会议（支持异步）：

• 6 位参与者，每人 3 个创意，共 5 轮
• 每轮：阅读之前的创意 → 添加 3 个新创意，或在现有创意的基础上继续构思
• 结果：30 分钟内最多可产出 108 个创意（可通过共享文档异步进行）

对于 AI 辅助的会议：

• AI 在 3 轮中扮演全部 6 种角色
• 从以下视角生成创意：PO、BA、终端用户、开发人员、运营人员和业务人员

3.4 — 影响映射

Gojko Adzic 的技巧。映射目标 → 参与者 → 影响 → 交付物：

GOAL: [business outcome with measurable target]
├── ACTOR: Who can help/hinder?
│   ├── IMPACT: How should behavior change?
│   │   └── DELIVERABLE: What feature produces this impact?
│   └── IMPACT: What negative behavior to prevent?
│       └── DELIVERABLE: What reduces this risk?
└── ACTOR: ...

关键见解： 从目标开始逆向推导。如果交付物无法关联到参与者行为的改变，就不要构建它。

3.5 — 类比思维

“[行业 X] 如何解决[类似问题 Y]？”

类比来源	在 HR 中的应用
Spotify Discover Weekly	个性化学习推荐
Uber surge pricing	动态奖金池分配
GitHub PR reviews	以证据为依据的同伴技能认可
Amazon recommendation engine	下一目标建议
Netflix "because you watched"	“和你相似的同事也达成了……”

阶段 3 的产出：

• SCAMPER 网格，包含 14 个以上创意
• Crazy 8s — 8 个解决方案方向
• 影响力地图（排名前 2 的目标）
• 受类比启发的创意（3–5 个）
• 原始创意总数：目标为 25–40 个

---

阶段 4：评估与收敛 — 第二颗钻石的收敛阶段

**目标：**将 25–40 个原始创意缩减为 3–5 个候选方案的排名短名单，用于假设测试。

4.1 — 点投票（第一轮）

评分前，快速凭直觉筛选：

• 每个创意标记为 ✅（保留）/ ❌（舍弃）/ 🔄（与另一个合并）
• 合并近似的创意
• 舍弃违反硬性约束（预算、技术、法律）的创意
• 目标：缩减至 10–15 个候选方案

4.2 — RICE 评分

为剩余候选方案排名：

RICE Score = (Reach × Impact × Confidence) / Effort

Reach:      Users affected per quarter (100 / 500 / 1000 / 5000+)
Impact:     0.25 minimal | 0.5 low | 1 medium | 2 high | 3 massive
Confidence: 0.5 low (gut feel) | 0.8 medium (some data) | 1.0 high (validated)
Effort:     Story Points — 1 trivial | 3 small | 5 medium | 8 large | 13 very large

为全部 10–15 个候选方案评分。按降序排序。前 5 个构成短名单。

4.3 — Kano 模型分类

为每个入选短名单的创意分类：

类别	描述	缺失时	提供时	示例
必备属性	基本预期	用户愤怒	用户无感	登录可用
绩效属性	越多越好	用户不满意	用户满意	加载更快
魅力属性	意料之外的价值	用户无感	用户惊喜	智能建议
无差异属性	无关紧要	用户无感	用户无感	图标颜色
反向属性	有些人想要，有些人不想要	细分群体不满	细分群体满意	自动填充

**策略：**必备属性 → 绩效属性 → 魅力属性。切勿为了魅力属性而跳过必备属性。

4.4 — 工作量 × 影响力 2×2 矩阵

快速可视化筛选：

HIGH IMPACT
    │  Quick Wins ★    │  Major Projects ⚙️
    │  (do first)      │  (schedule carefully)
────┼──────────────────┼────────────────────
    │  Fill-Ins 📋     │  Money Pits ⚠️
    │  (if time)       │  (avoid or cut)
LOW IMPACT
         LOW EFFORT         HIGH EFFORT

将每个入选短名单的创意标到图上。除非大型项目具有战略必要性，否则优先选择快速见效项。

4.5 — 用 MoSCoW 确定发布范围

为短名单中的每个创意分配发布优先级：

优先级	含义	阈值
必须有	缺少它，MVP 就无法正常运行	如果超过 80% 的价值依赖它，则纳入
应该有	很重要，但没有它 MVP 也能运行	如果 RICE 高于中位数，则纳入
可以有	有了更好，删减风险低	如果工作量 ≤ 3 SP，则纳入
不会有	明确不在本周期范围内	记录以供未来考虑

阶段 4 的产出：

• 点投票后的短名单（10–15 个创意）
• RICE 评分表（排名前 5）
• 每个入选短名单创意的 Kano 分类
• 2×2 矩阵位置
• 每个创意的 MoSCoW 分类

---

阶段 5：假设验证

**目标：**在决定构建之前，测试风险最高的假设。42% 的初创公司因没有市场需求而失败——先验证，再构建。

5.1 — 问题假设

**We believe** [target users/persona]
**Experience** [specific problem]
**Because** [root cause]
**We'll know this is true when** [validation metric/observable evidence]

示例：

We believe Operators
Experience frustration identifying high-priority orders during peak backlogs
Because order data is fragmented across 3 systems with no unified ranking
We'll know this is true when 3+ operators confirm they spend >2hrs per shift on manual data aggregation

5.2 — 价值假设

**We believe** [feature/solution]
**Will deliver** [specific value/outcome]
**To** [target users]
**We'll know we're right when** [measurable success metric]

5.3 — 风险最高假设测试（RAT）

找出那个一旦不成立就会让整个创意失败的唯一假设：

1. 列出所有假设：用户行为、技术可行性、市场需求、商业模式
2. 为每项打分：出错的概率（0–1）× 出错后的影响（0–1）
3. 最高分 = 风险最高的假设
4. 在完整构建之前，设计成本最低的测试来验证或证伪该假设：
   • 用户访谈（2–3 天）
   • 落地页 / 假门测试（1 周）
   • 原型点击体验（3–5 天）
   • 礼宾式 MVP（1–2 周）
   • 烟雾测试 / 预售（2–4 周）

5.4 — 构建-测量-学习循环

为每个头部创意定义循环：

BUILD: Minimum experiment to test the assumption (not a full product)
MEASURE: One metric that proves/disproves the hypothesis
LEARN: What decision do we make if metric is met / not met?
PIVOT: If hypothesis invalidated — which alternative from Phase 3 do we try next?

阶段 5 的产出：

• 为排名前 3 的每个创意准备问题假设卡
• 为排名前 3 的每个创意准备价值假设卡
• 确定每个创意风险最高的假设
• 设计成本最低的测试
• 定义构建-测量-学习循环

---

阶段 6：决策与建议

目标： 提出清晰、明确的建议，并说明其中的权衡。不是“这里列出了所有选项”，而是“这是我们的建议及其理由”。

6.1 — 前 3 个选项对比表

将最终候选名单整理为决策表：

选项	RICE	Kano	工作量	风险	RAT 测试	建议
选项 A	320	惊喜型	5 SP	中等	3 天访谈	⭐ 推荐
选项 B	180	绩效型	8 SP	低	原型	可行
选项 C	90	必备型	13 SP	高	预售	暂缓

6.2 — 建议陈述

RECOMMENDED: [Option Name]

Why: [1–2 sentences on RICE + Kano + strategic fit]
Risk: [Primary risk + mitigation]
First step: [Cheapest test to validate before full commitment]
Time to validation: [Days/weeks]

6.3 — 依赖项与排序检查

• 选项 A 是否依赖尚未构建的现有功能 / 数据 / 服务？
• 实验能否并行开展？
• 实现首次经验证的学习成果，关键路径是什么？

---

多机会发现模式

**当输入是横跨多个不同机会的原始产品愿景／问题陈述时，在第 0.1 阶段选择此模式。**这是一个附加模式，并非替代模式——其他所有情形仍采用第 6 阶段的单一建议默认流程。

适用情形：用户提交了一份宽泛的愿景、问题陈述，或“探索整个领域”简报，其中预期包含多个不同且可独立交付的机会——并且每个机会都应在下游成为一个独立的 PBI。这正是 workflow-idea-to-pbi 的多机会发现模式所驱动的流程。

收敛方式的区别（定义性差异）：默认流程收敛到一项明确的建议（第 6 阶段）。此模式不会这样做。相反，它使用相同的收敛技巧（第 4 阶段的 RICE／Kano／2×2），对 3–8 个不同机会进行排序并呈现机会图谱，而不是选出单一赢家。随后由用户多选要开发的机会。在此处选出一个赢家，会丢弃下游工作流旨在产出的其他 PBI。

**技巧流程：**照常执行第 1–4 阶段（问题界定 → 机会界定 → 构思 → 收敛），但在第 2 阶段侧重 JTBD／机会解决方案树，以呈现完整的机会全景（而非单一重点领域）；在第 4 阶段使用 RICE／Kano／2×2 为每个不同机会打分并排序，而不是缩减为一个最佳建议。

输出约定（必须符合 workflow-idea-to-pbi 的使用要求）：

• 一份包含 3–8 个不同机会的机会图谱，按 RICE 分数从高到低排序。
• 记录在 plans/{plan-dir}/brainstorm-opportunity-map.md 中。
• 每个机会都包含：一句话的问题／价值界定、RICE 组成项（Reach × Impact × Confidence / Effort）及 RICE 分数，以及（已知时）Kano 类别——以便为每个机会创建下游 PBI。

# Opportunity Map: [Vision/Problem]

| Rank | Opportunity | Problem/Value (1 line) | Reach | Impact | Confidence | Effort | RICE | Kano      |
| ---- | ----------- | ---------------------- | ----- | ------ | ---------- | ------ | ---- | --------- |
| 1    | ...         | ...                    | 1000  | 2      | 0.8        | 5      | 320  | Delighter |
| 2    | ...         | ...                    | ...   | ...    | ...        | ...    | ...  | ...       |

多选交接：直接询问用户“应该将哪些机会开发为 PBI？”，并通过 multiSelect: true 呈现排序后的机会图谱。选中的机会将进入 workflow-idea-to-pbi 的逐机会 PBI 循环（每个选中的机会 → 想法 → 细化 → 评审 → 故事 → 挑战 → DoR → 模拟稿，最后进行跨 PBI 优先级排序）。请勿在此技能中编写 PBI、规范或计划——发现模式的交付物仅为经评分并完成多选的机会图谱。

---

第 7 阶段：文档与交接

报告输出

使用注入上下文中 ## Naming 部分所规定的命名模式。

创建 Markdown 摘要报告：

# Brainstorm Session Report: [Topic]

## Session Context

- Scenario: [Problem-Solving / New Product / Enhancement]
- Role: [PO / BA / Mixed]
- Date: [YYYY-MM-DD]
- Input: [Original question/problem]

## Problem Statement

[POV format]

## Root Cause Analysis

[5 Whys or Fishbone — if Problem-Solving]

## Job Stories

1. [Job Story 1]
2. [Job Story 2]
3. [Job Story 3]

## HMW Questions

1. How might we...
2. How might we...

## Opportunity Map

[OST or Lean Canvas — per scenario]

## Raw Ideas Generated

[Total count: XX ideas across SCAMPER / Crazy 8s / Impact Mapping]

## Scored Shortlist (RICE)

| Rank | Idea | RICE | Kano | Effort | Priority    |
| ---- | ---- | ---- | ---- | ------ | ----------- |
| 1    | ...  | ...  | ...  | ...    | Must Have   |
| 2    | ...  | ...  | ...  | ...    | Should Have |

## Hypothesis Cards

### Top Recommendation: [Option Name]

- Problem Hypothesis: ...
- Value Hypothesis: ...
- Riskiest Assumption: ...
- Cheapest Test: ...
- Success Metric: ...

## Decision

[Recommendation + rationale]

## Next Steps

- [ ] [First concrete action]
- [ ] [Validation test]
- [ ] [Stakeholder alignment needed]

---

技法速查表

技法	阶段	适用场景	时间限制
POV 陈述	P1	始终使用	10 分钟
5 Why	P1	问题解决场景	15 分钟
鱼骨图	P1	系统性／复杂问题	20 分钟
JTBD／工作故事	P1	新产品或功能增强	20 分钟
HMW 问题	P1	始终使用——连接问题与构思	15 分钟
机会解决方案树	P2	功能增强场景	30 分钟
精益画布	P2	新产品场景	20 分钟
蓝海 ERRC	P2	需要差异化	20 分钟
价值主张画布	P2	产品与市场契合度不明确	25 分钟
SCAMPER	P3	始终使用——结构化构思	30 分钟
Crazy 8s	P3	需要快速产出大量想法	8 分钟
头脑写作 6-3-5	P3	多方参与者、异步协作	30 分钟
影响力映射	P3	以结果为先的思考	30 分钟
类比思维	P3	需要新颖／创意方向	15 分钟
点投票	P4	初步筛选	10 分钟
RICE 评分	P4	始终用于优先级排序	20 分钟
Kano 模型	P4	功能分类	15 分钟
2×2 工作量／影响矩阵	P4	可视化分流	10 分钟
MoSCoW	P4	确定发布范围	15 分钟
问题假设	P5	始终在做出承诺前使用	15 分钟
价值假设	P5	始终在做出承诺前使用	15 分钟
最大风险假设测试	P5	全面构建前	20 分钟
构建－测量－学习	P5	精益验证	20 分钟

---

角色专属指南

PO 模式（聚焦结果）

• 从以下内容切入：期望的业务结果 → 机会 → 实验
• 使用：OST、影响力映射、RICE、构建－测量－学习
• 提问：“我们希望看到用户行为发生怎样的变化？”
• 避免：在验证结果前就跳到功能方案

BA 模式（聚焦需求）

• 从以下内容切入：利益相关者需求 → 流程缺口 → 需求
• 使用：BABOK 需求引出方法（访谈、研讨会、文档分析）、鱼骨图、JTBD
• 提问：“系统需要做什么才能促成这种行为？”
• 避免：在 PO 验证机会前过度详细地定义需求

PO + BA 混合模式

• PO 负责：问题陈述、机会界定、优先级排序、假设
• BA 负责：需求引出、验收标准、边缘案例、流程映射
• 交接节点：第 4 阶段之后（评分后的候选清单）→ BA 为每个想法编写验收标准

---

协作工具

• planner Agent——研究特定领域的行业最佳实践
• docs-manager Agent——了解现有功能限制和领域背景
• WebSearch——为新产品场景提供市场／竞争对手背景
• docs-seeker 技能——获取外部插件／API 的最新文档
• visual analysis tooling 技能——分析视觉模型图、屏幕截图和竞争对手界面
• sequential-thinking 技能——分解需要结构化因果链的复杂问题
• web-research 技能——针对从零起步或竞争分析开展深入市场研究

---

场景速查

场景 A：问题解决

1. POV Statement → 2. 5 Whys / Fishbone → 3. HMW Questions
→ 4. SCAMPER on current solution → 5. RICE scoring
→ 6. Problem Hypothesis + RAT → 7. Recommend + cheapest test

场景 B：新产品

1. Job Stories (JTBD) → 2. Lean Canvas → 3. Blue Ocean ERRC
→ 4. HMW Questions → 5. Crazy 8s / Brainwriting
→ 6. Kano Classification → 7. Value Hypothesis + RAT → 8. MVP scope

场景 C：功能增强

1. Job Stories (JTBD) → 2. Opportunity Solution Tree
→ 3. HMW Questions → 4. SCAMPER on existing feature
→ 5. Impact Mapping → 6. RICE scoring → 7. 2×2 matrix
→ 8. Value Hypothesis + RAT → 9. Recommend + next experiment

场景 D：多机会发现

1. Job Stories (JTBD) → 2. Opportunity Solution Tree (FULL landscape, not one focus)
→ 3. HMW Questions → 4. SCAMPER → 5. RICE-score EVERY opportunity
→ 6. Rank into a 3–8-item opportunity map (do NOT pick ONE)
→ 7. Write plans/{plan-dir}/brainstorm-opportunity-map.md
→ 8. ask the user directly multiSelect → hand selected opportunities to the per-opportunity PBI loop

**与 A/B/C 的主要区别：**汇总为可多选的排名地图，绝不只给出单一推荐。请参阅多机会发现模式。

---

应避免的反模式

反模式	失败原因	更好的做法
尚未定义问题就跳到解决方案	会做出错误的东西	始终先完成阶段 1
生成创意时同时评估创意	扼杀创意产出，过早下结论	严格分离发散与收敛
只考虑一种利益相关者的视角	忽略任务、痛点和背景	从 6 种不同角色的视角进行脑力写作
构建前没有假设	42% 的功能会失败——因为没有市场需求	始终编写假设 + RAT
RICE 未包含信心分数	高估证据不足的创意	始终将信心作为乘数
忽视 Kano——只构建惊喜型需求	基本型需求未满足时，用户无法使用惊喜型功能	按基本型 → 期望型 → 魅力型的顺序确定优先级
未进行验证测试就认定“最佳创意胜出”	HiPPO 偏差（薪酬最高者的意见）	每个顶级创意都需要 RAT 测试设计
构思过程中范围蔓延	创意膨胀到团队无法验证的程度	严格限制每个阶段的时间
将 RICE 分数视为最终结论	RICE 仅用于判断方向，并不精确	结合使用 RICE、Kano 和战略背景

---

关键约束

• 不要实施解决方案——仅进行头脑风暴并提供建议
• 在认可任何方案前，务必验证假设
• 优先考虑长期可维护性，而非短期便利
• 兼顾技术卓越性与商业实用性
• 务必给出带评分的排名候选清单——绝不能只提供平铺的创意列表
• 务必设计成本最低的验证测试——先做 RAT，再编写完整规格

---

工作流集成

头脑风暴结束后，直接询问用户并展示后续步骤：

后续步骤	适用时机	技能/工作流
$idea	将顶级创意记录为待办事项条目	idea 技能
$refine	将顶级创意转化为包含 AC 的可执行 PBI	refine 技能
$web-research	需要先深入研究市场/竞争对手	web-research 技能
$plan	问题明确，方案已验证，准备实施	plan 技能
$design-spec	创意涉及大量 UI，需要先制作线框图再编写规格	design-spec 技能
$domain-analysis	创意涉及领域实体，需要先建立模型	domain-analysis 技能
继续头脑风暴	还有更多场景需要探索	保持在当前会话中

**多机会发现模式交接：**在发现模式下运行时，不要选择单一后续步骤；而应直接询问用户，展示排名靠前的 3–8 项 RICE 机会地图（写入 plans/{plan-dir}/brainstorm-opportunity-map.md），并设置 multiSelect: true，然后将选中的机会交给 workflow-idea-to-pbi 的逐机会 PBI 循环。workflow-idea-to-pbi 会直接使用此机会地图。

[IMPORTANT] 开始前，使用任务跟踪将所有工作拆分成小任务。这可以避免长时间工作导致上下文丢失。

---

防止 AI 犯错 — 每项任务都要避免以下失误：

上下文变化后重新阅读文件。 上下文压缩、恢复工作或长时间运行的任务都可能导致记忆过时；行动前请核实当前文件。 根据源证据核实生成内容。 AI 可能会幻觉出 API、名称、主张和文档事实。记录或引用前，请检查相关来源。 删除或重命名前检查下游引用。 删除某个产物可能导致文档、生成的镜像、配置和调用方失效；请先梳理引用关系。 编辑后追踪完整的影响链。 修改定义可能会遗漏派生输出和使用方。宣布完成前，请检查受影响的完整链路。 核实所有受影响的输出，而不只是第一个。 一项检查通过不代表所有检查都通过；请验证此次变更可能影响的每个输出界面。 假定现有值都是有意设置的——更改或标记缺陷前先问清原因。 更改或报告某个常量、限制、标志、阈值、措辞或模式前，请阅读相邻上下文和历史记录、调用方的执行顺序，以及 2 个或更多采用相同约定的同类调用点。文档说明了“是什么”却没有说明“为什么”，意味着缺少依据，而不能证明缺少防护条件。 行动前指出歧义——不要默默选择。 存在多种合理解释时，必须明确提问，或说明假设及其风险。 断言系统自身负责的结果，而非基础设施负责的中间状态。 验证异步工作时，应断言最终业务状态，绝不要断言共享基础设施中的投递或重试记录，因为任何同时运行的进程都能写入这些记录。这类检查单独运行时会通过，只要有其他进程共享该基础设施，就可能出现不稳定结果。 确保共享指导与接收者的职责相关。 通用指导必须对每个接收该指导的技能或 Agent 都有帮助；代码专属要求应只放在代码专属协议中。

批判性思维 — 运用批判性思维和顺序思维。采取行动前，每项主张都必须有可追溯的证据，置信度需超过 80%。 反幻觉： 绝不要把猜测说成事实——每项主张都要引用来源；坦诚承认不确定性；自行检查输出中的错误；独立交叉核对；对自己的判断保持怀疑——没有证据的确信是一切幻觉的根源。 Sequential Thinking Protocol — 面向复杂／模糊工作的结构化多步推理。在规划、审查、调试或完善想法时使用，尤其是一次性推理不安全的情况。

触发条件： 复杂问题分解 · 需要修订的自适应计划 · 需要纠正方向的分析 · 范围不明确／不断变化 · 多步解决方案 · 基于假设的调试 · 跨领域权衡评估。

格式（显式模式 — 可见的思考过程）：

1. Thought N/M: [aspect] — 每条思考聚焦一个方面，并说明假设／不确定性
2. Thought N/M [REVISION of Thought K]: ... — 先前推理失效时使用；说明原始内容／修订原因／影响
3. Thought N/M [BRANCH A from Thought K]: ... — 探索替代方案；以决策理由收敛
4. Thought N/M [HYPOTHESIS]: ... 然后 [VERIFICATION]: ... — 行动前先验证
5. Thought N/N [FINAL] — 仅在验证完成、所有关键方面均已处理且置信度 >80% 时使用

必须包含的结尾内容： 说明置信度百分比 · 列出假设 · 提出待解决问题 · 明确下一步行动。

停止条件： 对任何关键决策的置信度 <80% → 直接向用户询问并升级处理 · 同一条思考修订 ≥3 次 → 重新梳理问题 · 分支数 >3 → 拆分为子任务。

隐式模式： 在添加标记会使回复显得杂乱时（推理有助于提高准确性的常规工作），在内部应用该方法，不显示标记。

深入了解： 查看 $sequential-thinking 技能（.claude/skills/sequential-thinking/SKILL.md），获取完整示例（API 设计、调试、架构）、高级技术（螺旋式完善、假设检验、收敛）以及元策略（不确定性处理、修订级联）。

务必注意：运用批判性思维和顺序思维 — 每项声明都需要有适当的可追溯证据（仓库／代码声明使用 file:line；研究、产品、内容和文档声明使用来源 URL 或制品章节）；采取行动前置信度须 >80%，低于 60% 时切勿提出建议。防止幻觉：切勿将猜测当作事实陈述，坦诚承认不确定性，独立交叉核对，并对自己的判断保持怀疑。

务必注意：运用顺序思维 — 使用多步 Thought N/M、REVISION／BRANCH／HYPOTHESIS 标记，以及置信度百分比结尾；参见 $sequential-thinking 技能。

务必注意：防止 AI 出错 — 根据证据核验生成内容，删除或重命名前追踪下游引用，核验所有受影响的输出，上下文丢失后重新阅读文件，并在采取行动前指出歧义。

提示词增强：结束锚点

重要，务必注意： 必须遵循此技能声明的步骤顺序；未经用户明确批准，绝不跳过、重排或合并步骤 重要，务必注意： 每次执行步骤／子技能调用时，执行前设置为 in_progress，执行后设置为 completed 重要，务必注意： 每个跳过的步骤都必须说明明确原因；每个已完成的步骤都必须提供简洁的证据 重要，务必注意： 如果 Task 工具不可用，必须维护一个状态同步的等效逐步计划跟踪器

项目协议覆盖规则 — 执行此技能前，先解析叠加在其上的任何 PROJECT 覆盖规则：根据项目技能协议索引（默认路径为 docs/project-reference/skill-protocols-reference.md；docs/project-config.json 中的 referenceDocs 条目可覆盖此路径）的 Target 列，将此技能名称与之匹配，且只采用最具体的匹配层级——精确名称 > glob > *。此优先级仅用于排列覆盖规则之间的优先级，绝不凌驾于此技能本身。 只读取匹配条目的正文，路径解析为 <protocols-dir>/<Name>.md；条目的 Body 链接只是显示文本，绝不是读取路径。匹配到的正文若缺失或格式错误，则必须报告并跳过——绝不能根据索引中的 Description 重建。没有索引或没有匹配项 -> 不应用覆盖规则，且不作说明。完整约定见 .claude/skills/project-skill-protocol/references/registry.md。

覆盖规则仅可附加：它们只能在此技能自身协议的基础上增加规则，绝不能取代、覆盖、禁用或重新解释此技能已有的规则——移除所有覆盖规则后，此技能的行为必须与其文档所述完全一致。覆盖规则是简要补充，不是权限升级：绝不能豁免工作流关卡、Git 规范、审查关卡或用户确认关卡。若覆盖规则与技能本身存在实质冲突，或两个同等具体的覆盖规则直接矛盾，必须向用户说明双方内容；绝不能静默裁定。

务必注意： 执行此技能前，必须解析项目协议覆盖规则——只采用最具体的匹配层级（精确名称 > glob > *；此优先级仅用于排列覆盖规则之间的优先级，绝不凌驾于此技能本身）；只读取 <protocols-dir>/<Name>.md 中匹配的正文；正文缺失或格式错误时必须报告，绝不能重建。覆盖规则仅可附加（绝不取代此技能自身的规则），且只是补充，绝不是权限升级；同等具体的规则发生矛盾时，必须提交给用户处理。

结束提醒

• 重要，务必注意——目标： 提交一份经过评分和排序的候选创意清单，共 3–5 项；每项都应包含问题与价值假设、已识别的最大风险假设，以及设计好的最低成本验证测试——让团队在构建之前选定正确的问题和正确的解决方案，而不是面对一份未经验证的平铺创意列表。
• 重要，务必注意——主要步骤（按顺序执行并跟踪每一步）： P0 会话设置（识别场景 + 角色 + 已知信息）→ P1 问题框定／发散（观点 POV → 5 Whys／鱼骨图 → JTBD → HMW）→ P2 机会框定／收敛（OST／精益画布／ERRC／价值主张）→ P3 创意构思／发散（SCAMPER → Crazy 8s → Brainwriting → 影响力地图 → 类比法，25–40 个创意）→ P4 评估／收敛（点投票 → RICE → Kano → 2×2 → MoSCoW，筛选出 3–5 项）→ P5 假设验证（问题 + 价值卡片 + RAT + 最低成本测试 + 构建-测量-学习）→ P6 决策（只给出一项建议）→ P7 文档记录与交接——原因：技能自身的阶段是 AI 最容易忘记的步骤；在每个阶段开始前都要重新对照这些锚点。

当前生效的协议（此技能所含 SYNC／共享区块的简要摘要）：

• AI 错误预防： 根据证据验证生成内容，追踪下游引用，验证所有受影响的输出，在上下文丢失后重新阅读，并明确指出歧义。

• 批判性思维： 追踪到 file:line 的证据；置信度 >80% 才采取行动；绝不猜测。

• 序列思维： 采用多步骤 Thought N/M，并使用 REVISION/BRANCH/HYPOTHESIS 标记，逐步提高置信度。

• 强制重要必须注意 在 Phase 0 FIRST 中，直接询问用户以识别场景、角色和已知信息的多少——每种场景都会采用不同的技术序列——原因：误判场景会使所有后续阶段偏离方向。

• 强制重要必须注意 将发散（Phases 1 & 3，生成、“Yes, and…”，零评判）与收敛（Phases 2 & 4，缩小范围并评分）分开——生成想法时绝不评估想法——原因：混合这两种模式会违反黄金法则，扼杀创意产出。

• 强制重要必须注意 绝不停留在原始或平铺的想法列表上——每个排名前 3 的候选项都必须附带问题 + 价值假设卡、已识别的最高风险假设（RAT），以及在承诺开始构建前设计的单个最低成本验证测试——原因：42% 的功能因缺乏市场需求而失败；先验证，再构建。

• 强制重要必须注意 开始前使用任务跟踪将工作拆分成小型待办任务；每项任务完成后立即标记为 completed，并添加最终审查待办事项——原因：长时间的头脑风暴会丢失上下文，没有外部任务跟踪尤其如此。

• 强制重要必须注意 先搜索 3+ 个现有模式——构思前，领域问题（代码库）先阅读 docs/specs/，市场/竞争对手背景（从零开始）先使用 WebSearch——原因：缺乏领域或市场证据支撑的想法，评分依靠直觉而非契合度。

• 强制重要必须注意 每项主张都要引用证据，置信度 >80% 才建议；RICE Confidence 是乘数，不可省略——原因：缺乏证据的想法若没有 Confidence 分数，就会被过度优先排序。

• 强制重要必须注意 以一项明确的建议 + 权衡取舍收尾（Phase 6）——绝不提供平铺的选项菜单——原因：选项菜单会把决策推回给团队，并引发 HiPPO 偏见。例外——Multi-Opportunity Discovery mode（在 Phase 0 中选择）：不要只选一项；而是对 3–8 项机会绘制 RICE 排名图，将其写入 plans/{plan-dir}/brainstorm-opportunity-map.md，并直接询问用户 multiSelect: true，将其移交给 workflow-idea-to-pbi 的逐项机会 PBI 循环——原因：每项机会都会成为单独的下游 PBI，因此将其合并为一项会丢弃此发现工作流旨在产出的待办列表。

• 强制重要必须注意 对所有用户决策和移交流程路由（$idea、$refine、$plan）都使用直接询问用户的方式——绝不自动做决定——原因：场景、优先级和下一步选择由用户决定。

反合理化：

规避行为	反驳
“场景很明显，跳过阶段 0 检测”	场景分类错误会导致采用错误的技术序列。先直接询问用户。
“只要列出创意，评估可以稍后再做”	平铺直叙的创意列表不符合交付要求。为排名前 3 的创意评分、排序并进行假设测试。
“跳过 RAT——这个创意显然不错”	“显然不错”是 HiPPO 偏差。在承诺构建之前，先设计成本最低的测试。
“把发散和收敛合在一起做，节省时间”	混合两种模式会扼杀创意产出——这违反了黄金法则。将各阶段严格分开。
“不考虑 Confidence 的 RICE 也差不多”	缺少 Confidence 乘数会导致证据不足的创意排名过高。始终为 Confidence 评分。
“已经了解该领域，跳过上下文加载”	展示已读取 docs/specs/ 的证据或 WebSearch 证据。没有证据 = 缺乏依据的构想。

务必注意：先进行阶段 0 场景检测 · 严格区分发散与收敛 · 每个排名前 3 的创意都必须包含假设 + RAT + 成本最低的测试——这三点在长时间会话中依然适用；提出建议前，请重新确认这些要求。

无钩子提示词协议镜像（自动同步）

来源：.claude/.ck.json + .claude/skills/shared/sync-inline-versions.md（:full 块）+ .claude/scripts/lib/hookless-prompt-protocol.cjs

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] 工作流执行协议 — 强制要求，重要，必须执行，关键。任何情况下都不得跳过。

**通用可移植性边界：**可复用技能和协议文本应保持项目中立；从 docs/project-config.json 和 docs/project-reference/ 中了解项目特定约定。应用 shared/sdd-artifact-contract.md 中的共享 AI-SDD。阅读 docs/project-config.json 和 docs/project-reference/docs-index-reference.md，然后打开其中列出的项目参考文档。对于规范、测试用例、行为变更、公共契约或 docs/specs/ 相关工作，应通过文档索引中列出的本地规范文档进行：当规范／测试／代码必须保持同步时，使用 feature-spec-reference.md、spec-system-reference.md、spec-principles.md 和 workflow-spec-test-code-cycle-reference.md。如果任一文件或必需的参考文档缺失或过时，则在进行常规项目特定工作之前，自动运行 $project-init（或更精简的底层流程，例如 $project-config、$docs-init、$scan-all 或 $scan --target=<key>）。只要具备此共享上下文和本地文档，任何受支持的 AI 工具都可以执行。

1. **检测：**如果提示以明确的斜杠技能／工作流命令开头，则直接执行。否则，根据工作流目录和技能列表匹配提示。
2. **分析：**选择最佳方案：直接执行、调用技能、启动标准工作流，或组合自定义步骤。
3. **自动选择：**自行选择最佳方案。不要让用户在直接执行、技能、标准工作流或自定义工作流之间做选择。
4. **启动：**对于选定的工作流，调用 $start-workflow <workflowId>；对于选定的技能，调用该技能；对于自定义工作流，直接按顺序执行自定义步骤；对于直接执行，继续处理任务。
5. **创建任务：**如果选定路径包含多个步骤，则在执行前为所有工作流／技能／自定义步骤创建任务跟踪。
6. **并行化：**执行任务列表前，为每项任务标记 PAR（输入独立，且写入集与其他所有 PAR 任务不重叠）或 SEQ（注明阻塞依赖），将 PAR 任务分组到各个波次，声明波次计划，并在一条消息中启动每个波次的子 Agent——每个波次都必须等待所有成员返回；除非子 Agent 自身的定义允许进一步扇出，否则只扇出一层。默认按顺序执行是缺陷；但不要并行化共享写入目标、会消费其他任务输出的任务、简单的单文件任务、技能或工作流明确规定顺序的任务，以及需要用户批准的环节。
7. **执行：**按照上下文指令中的 Workflow Step Advancement & Parallel Phases 规则推进——由模型驱动；子 Agent 完成与内联调用一样会推进步骤；并行阶段组必须等待所有成员返回（只有所有成员都返回后才能推进，绝不能串行执行）

共享 AI-SDD 协议标记

来源：.claude/skills/shared/sync-inline-versions.md

SYNC:ai-sdd-artifact-contract

AI-SDD 工件契约 — 共享的规范驱动开发规则应保持可移植，并由源文件管理。

1. 将可复用的 AI-SDD 原则保存在 .claude 中；将特定于仓库的路径、命令、负责人、产品和格式放在项目配置／参考文档中。
2. 保持以下周期：spec -> plan -> tasks -> implement -> verify -> update spec/docs。
3. 通过决策、任务、TC／测试、源证据以及文档／规范更新，追踪每项要求或不变量。
4. 将从代码提取规范的内容仅视为参考，直到规范的权威负责人接受为止。
5. 任何受支持的 AI 工具都可基于同步的上下文进行规划、实现、审查或验证；使用多个工具是可选的。
6. 先更新 .claude 源文件，再同步生成的镜像；不要手动编辑 .agents、.codex 或 AGENTS.md。— 原因：镜像是生成的工件；下次同步时，手动修改会被覆盖
7. 如果 docs/project-config.json、根目录指令文件或必需的项目参考文档缺失或过时，则在进行常规项目特定工作之前，自动运行 $project-init 或范围更窄的底层流程。

当前参考文档： 当前技能根目录中的 shared/sdd-artifact-contract.md。

---

SYNC:ai-sdd-artifact-contract:reminder

• MANDATORY 应用 shared/sdd-artifact-contract.md；将可复用的 AI-SDD 保存在 .claude 中，并将本地规则保存在项目文档中。
• MANDATORY 从代码提取的规范仅供参考，直到权威规范获批；任何受支持的 AI 工具都可基于同步的上下文执行工作。
• MANDATORY 先更新 .claude 源文件，再同步生成的镜像；不要手动编辑 .agents、.codex 或 AGENTS.md。
• MANDATORY 如果项目配置、根目录指令文件或必需的参考文档缺失或过时，则应自动通过 $project-init 或范围更窄的设置流程来处理项目特定工作。 [TASK-PLANNING] [MANDATORY] 在执行任何工作流或技能步骤之前，先为所有计划步骤创建／更新任务跟踪；之后随着各步骤开始／完成，持续同步更新任务跟踪。

[LESSON-LEARNED-REMINDER] [BLOCKING] 任务规划与持续改进 — MANDATORY。不得跳过。

开始前将工作拆分为小任务（任务跟踪）。添加最终任务：“分析 AI 错误与经验教训”。

提取经验教训——仅关注根本原因，而非修复表象：

1. 指明失败模式（推理／假设失误），而非表面症状——“未阅读源代码就假设 API 存在”，而不是“使用了错误的枚举值”。
2. 通用性测试：此失败模式是否适用于 ≥3 种情境／代码库？如果不适用，则再向上抽象一层。
3. 写成通用规则——去除特定于项目的名称／路径／类。规则应适用于任何代码库。
4. 合并：多个错误若属于同一种失败模式，则合并为一条经验教训。
5. 复发门槛：“如果没有这条提醒，未来会话中是否会再次出现此问题？”——不会 → 跳过 $learn。
6. 自动修复门槛：“$code-review／$code-simplifier／$security-review／$lint 能否发现此问题？”——能 → 改进审查技能。
7. 两个门槛都通过 → 请用户运行 $learn。 [CRITICAL-THINKING-MINDSET] 运用批判性思维和序贯思维。每项断言都需要可追溯的证据；采取行动前，置信度须 >80%。 **反幻觉原则：**绝不将猜测当作事实——为每项断言引用来源，坦诚承认不确定性，自行检查输出错误，独立交叉核对，并对自己的信心保持怀疑——缺乏证据的确信是所有幻觉的根源。 **AI 注意力原则（首因－近因效应）：**在较长提示词／协议的开头和结尾都放置最关键的 3 条规则，以确保指令在较长的上下文窗口中仍能得到遵循。 **目标驱动执行：**先定义成功标准，持续循环直至验证完成；仅当可观察的检查均通过后才停止。 **测试验证意图：**测试必须保护业务规则／不变量，并在受保护的意图遭到破坏时失败，而不只是复现当前行为。

常见 AI 错误预防（系统经验）

• 上下文压缩后重新读取文件。 编辑前必须在同一上下文中先读取文件；上下文压缩会清除读取状态。编辑前重新读取。
• 批量替换后 grep 旧术语。 AI 过度相信查找/替换已覆盖所有内容。批量编辑后，对整个仓库执行 grep，检查文档/配置/目录中遗漏的引用。
• 删除前检查下游引用。 删除会连带导致文档/代码过时。移除前先梳理引用文件。
• 丢失记忆后，创建新内容前先检查现有状态。 上下文压缩会清除先前工作的记忆。查询当前状态以便继续——绝不要盲目重复创建。
• 根据实际代码验证 AI 生成的内容。 AI 会幻觉出 API、类名和方法签名。记录/引用前先用 grep 确认其确实存在。
• 编辑后追踪完整依赖链。 更改定义却漏掉下游使用方。追踪完整链路。
• 重命名时，对所有使用方文件类型执行 grep。 某些文件类型会静默忽略缺失的引用（不会产生编译错误）。搜索代码、模板、配置和生成文件。
• 验证正确性时追踪所有代码路径。 代码存在 ≠ 代码会执行。追踪提前退出、错误分支和条件跳过——不要只看正常路径。
• 源数据变更时，更新包含规范数据的文档。 内嵌派生数据（工作流、架构、配置）的文档会静默过时。源数据变更时，同时更新所有内嵌该数据的文档。
• 恢复上下文后验证子 Agent 的结果。 父 Agent 压缩上下文期间，后台 Agent 可能已经完成——用 grep 验证输出，不要相信对任务已完成的假设。
• 将完整目标列表与子 Agent 的分配任务交叉核对。 按类别并行分配子 Agent 会漏掉边界项。继续前，将各分配任务的并集与目标列表核对。
• 子 Agent 只能从其 Agent 的 .md 定义继承知识——使用自定义 Agent 类型，不要使用内置 Explore。 采用工具 = 权限 + 知识 + 执行（编号工作流步骤）。
• 逐步记录子 Agent 的发现，不要等最后一次性提交。 长时间运行的子 Agent 可能在最终写入前达到截断限制——导致发现丢失。指示其按章节追加到报告文件。
• 调试时，修复前先问“责任在谁？” 追踪调用方（数据错误）还是被调用方（处理错误）。在责任层修复——绝不要只修补症状出现的位置。
• 测试失败 → 先记录暂定结论，再追踪/编辑，然后调查。 使用完整的五类分类：SOURCE-WRONG（生产代码违背意图）、TEST-WRONG（断言/设置已过时）、TEST-NOT-OPTIMAL（测试有效但脆弱或信号弱）、ENVIRONMENT-BLOCKED（外部状态阻止得出结论），或 AMBIGUOUS（意图/证据不足以安全判断）。然后追踪根因，并对照规范依据（如果存在，查看 docs/specs/**）和源代码进行交叉验证。绝不要只为让测试变绿而削弱断言、添加跳过、放宽超时或更改源代码。
• 提取/重构后，对所有已移除名称执行 grep。 主文件“完成” ≠ 次要文件干净。宣布完成前，在整个范围内搜索每个已移除的符号。
• 假定现有值是有意设定的——更改或将其标记为缺陷前先问为什么。 仅凭模式匹配判定“错误”会忽略上下文。更改或报告任何常量/限制/标志/阈值前：阅读注释、git blame、调用方的执行顺序（使该值正确的保证通常位于引用行之前紧邻执行的代码中），以及同一惯例下至少 2 个同类调用点。只说明“是什么”却不说明“为什么”的文档，缺少的是依据，并不能证明缺少保护措施；在验证环节中，准确的 file:line 引用证明的是转录无误，而不是缺陷确实存在。
• 验证所有受影响的输出，而不只是第一个。 一个构建成功 ≠ 全部成功。涉及多个技术栈的变更（后端/前端/测试/文档）要求验证每一项输出。
• 复制相近模式前，先评估是否适用。 最接近的示例 ≠ 前提相同——确认新上下文具有相同的约束、基类、作用域和生命周期。
• 整体优先的调试方式——抵制注意力就近陷阱。 不要一头扎进第一个看似合理的原因。列出所有前提（配置、环境变量、路径、数据库、端点、凭据、版本、DI、数据）。用证据（grep/查询——而非推理）逐项验证。问“什么证据可以推翻这个假设？”——如果没有，那就不是假设。代价最高的失败：在“显而易见”的层继续深挖，而 Bug 实际位于从未质疑过的层。
• 精准修改——应用 diff 测试（结合上下文判断）。 两种模式：（1）Bug 修复 → 每一行都能追溯到该 Bug；不做样式调整；只清理因你的修改而变得未使用的孤立内容。（2）审查/增强 → 实施改进，并声明为“超出主要请求的增强：[内容]”。绝不要悄悄扩大范围。Diff 测试：“如果我没有被要求做 X，这一行还会存在吗？”——如果不会，就删除或明确说明。
• 编码前先指出歧义——不要默默自行选择。 存在多种有效解释时，逐一列出并说明工作量：“[请求] 可能指 (1) [N 小时]、(2) [N 小时]。哪一个更重要？”先列出范围/格式/数量/约束方面的假设。如果有更简单的方案，也要说明。绝不要默默自行选择。
• [MANDATORY FIRST ACTION] 回复前务必先启用合适的技能或工作流。 将任务与工作流目录和技能列表进行匹配；通过技能调用或 $start-workflow <workflowId> 启用。检查之前绝不要回答或编写代码。跳过 = 违反协议。
• Why-Review 对抗性思维——审查任何计划、决策或设计时都要运用。 默认持怀疑态度，而非验证者态度：充分论证被否决的替代方案，将每项既定理由反向审视（“它牺牲了什么？”），对最重要的 2-3 项假设进行压力测试，开展事前验尸（“已发布，3 个月后失败——什么会出问题？”），并指出作者遗漏的 1-2 种替代方案。章节齐全 ≠ 质量过关；质量取决于因果推理、具体缓解措施和证据，而不是“这样更好”或“密切关注”。
• 大型审查的子 Agent 提示词应优先安排报告写入。 处理许多文件的子 Agent 可能在最终写入前耗尽预算——导致发现丢失。设计提示词时应确保：（1）报告写入是第一个明确的交付项，（2）按文件/章节逐项追加（不要批量写入），（3）限定范围，避免读取耗尽预算。若输出在句中被截断且没有报告文件 → 启动范围更窄的任务，不要原样重试相同提示词。
• 上下文压缩后，继续前重新验证此前各阶段的所有结果。 摘要描述的是意图，不是环境状态（git 索引、文件系统、进程）。恢复时，首先审查：git status、重新读取修改过的文件、验证文件系统。每一项“已完成”的声明，在证据确认前都是未经验证的假设。
• OOM/内存：先检查行数，再检查行大小。 排查顺序：（1）无界查询——触发条件是否没有数据库筛选？将筛选推到数据库端；这可消除 OOM。（2）行是否很大？投影可按比例减少数据量。减少行数比投影的收益更大。
• 断言系统自身负责的结果，绝不要断言基础设施负责的中间状态。 测试任何异步行为（队列/代理传递、重试、后台任务、缓存、复制）时，应断言最终业务/实体状态。绝不要断言传递记录——消费/发送状态、尝试次数、最后错误、代理、调度程序或 outbox/inbox 表中的行存在与否或数量。这些记录属于共享基础设施，任何同时运行的进程（同伴 Worker、第二个副本、遗留的本地容器）都可能写入，且通常使用确定性的共享键；因此，断言会悄悄测试开发者的环境，而不是系统：单独运行时通过，一旦有其他进程共享该代理和数据库就会不稳定。每个断言都要问：“无论哪个进程执行了这项工作，该断言都会成立吗？”——如果不会，就改为断言已收敛的数据状态。推论：进程本地的故障注入和进程内遥测不能用于控制任何进程都可能执行的工作——将它们用作压力放大器（启用 → 限定时间窗口 → 停用 → 断言收敛），绝不要用作前置条件。
• 不要让领域概念进入通用/共享/基础设施层。 可复用层（共享库、框架、基础设施模块）不得引用任何特定使用方的领域概念——租户/客户/产品 ID、业务实体、功能规则。泄漏进来后，代码能够编译并运行，因此会悄无声息地通过审查，同时让“可复用”层与某个使用方耦合。保持共享类型与领域无关；通过子类/组合将领域字段/逻辑下放到使用方。——原因：与某个使用方的领域耦合的层不再可复用。