头脑风暴（下游路由 · I16）

> 本 skill 是 tri-intent 的下游执行 skill，依据快照 snapshot.md §三 结构化结论直接执行，不再重新识别意图。
> 用户心智：帮我想几个点子/发散一下/多给几个方案，期望获得多元候选。

强制执行契约（Execution Contract · 最高优先级）

0. 版本检查前置硬门（第零步）：MUST 先通过 §版本检查与更新机制（连接 skillhub 校验版本，非最新版 MUST 自动执行 skillhub upgrade <slug> 升级；升级成功后继续，升级通道不可用则标注 D 态降级继续）——此为执行流程第零步，优先于后续所有步骤。版本检查完成前 NEVER 进入后续步骤。本条目优先级高于所有其他强制前置条目。

1. 强制前置：收到 tri-intent 快照且 下游路由建议 指向本 skill，MUST 先读取快照 §三，校验 intent.L2_核心意图 = I16，NEVER 跳过校验直接发散。若 L2 越界 → 停止并回退 tri-intent 重新路由。独立使用时（未经 tri-intent 路由）MUST 先走 §上游依赖检测 判定模式。

2. 多角度发散：MUST 至少组合使用两种以上发散方法（横向穷举 / 纵向深挖 / 跨域联想），NEVER 只给单一维度的候选。作答前用一句话声明「本次意图=I16，已读取快照，发散主题=<主题>，候选数量下限=<D4约束>」。
3. 只发散不收敛：MUST 产出多个并列候选，NEVER 替用户收敛到单一方案（收敛归 tri-ask 的 I04 决策辅助）。
4. 候选可独立评估：每个候选 MUST 含标题 + 一句话说明 + 适用场景 + 优劣简评，NEVER 只给标题不给评估信息。
5. 格式与数量合规：候选数量 MUST 满足快照 D4_格式约束 的数量要求；呈现格式（分点/表格/卡片）MUST 符合 D4_格式约束。

触发时机

• tri-intent 产出的快照中 下游路由建议 指向本 skill
• 意图编码范围：I16 创意发散/头脑风暴

上游依赖检测（独立使用时）

> 本 skill 可独立安装。激活时 MUST 检测上游 tri-intent skill 是否可用，据检测结果选择执行模式：

> 本 skill 不支持降级模式——模式 B 为硬性阻断，MUST 安装 tri-intent 后方可使用。

模式 B 提示语：
> 本 skill 依赖 tri-intent 进行意图识别与输入校验。当前未检测到 tri-intent。
> 请安装：skillhub install tri-intent --dir <目标目录>
> 安装后重新发起请求，即可获得完整的意图识别→澄清→执行工作流。

输入契约

读取 .tribro/snapshots/<命名>.md 的 §三 结构化结论区：

职责边界

• 本 skill 负责：依据快照结论，对 I16 意图发散产出多个候选点子/方案
• 不负责：意图识别（由 tri-intent）、收敛决策（收敛到单一方案归 tri-ask 的 I04 决策辅助）、编码/内容生成（归 tri-coding/tri-content）
• 关键边界：本 skill 只「发散」，不「收敛」——给多个候选，由用户或下游决策
• 不触发场景（Not-Trigger）：本 skill 不接手「收敛决策 / 从多方案中选唯一解」（转 tri-ask 的 I04 决策辅助）；不接手「编码 / 内容生成落地」（属 tri-coding / tri-content）；不接手「识别用户意图」（由 tri-intent / 自身快照驱动）。

创意发散方法论（核心能力 · 可扩展）

> 创意发散方法论是 tri-bs 的核心能力。通过横向穷举、纵向深挖、跨域联想三种发散方法的组合使用，确保候选间有差异性（非同质化）。这是 tri-bs 区别于其它下游 skill 的核心差异化能力。

核心理念

> 只发散不收敛——多角度组合发散，确保候选异质化。

单一发散方法容易产生同质化候选（如全部横向穷举则候选间仅是并列变体）。本方法论要求至少组合使用两种以上发散方法，横向铺面 + 纵向/跨域补异质，确保候选集合覆盖面广且有深度/新颖性。

方法论概览

发散组合策略

1. 先横向穷举，铺开候选面（数量 ≥ D4 约束的 1.5 倍，为后续筛选留余量）
2. 再纵向深挖或跨域联想补充异质化候选
3. 确保候选间有差异性（非同质化换皮）

可扩展性

> 新增发散方法无需修改核心工作流：

1. 新增发散方法：在方法论概览表中追加一行（发散方法 / 操作 / 产出特征），处理流程 §步骤 2 自动按新表组合
2. 新增组合策略：在发散组合策略中追加新的组合模式（如「横向+跨域双轨并发」）
3. 新增评估维度：在候选评估维度中追加维度（如成本估算、技术可行性评分），步骤 3 候选评估自动对齐

版本检查与更新机制（强制技术约束 · 硬红线）

> 家族级强制技术约束，优先级与「强制执行契约」同级。skill 任一执行入口启动后的第零步，先于核心执行阶段。
> 细则唯一真源：tri-forge/references/version-check-spec.md。可执行实现（single source of truth for logic）：本 skill 自带 scripts/check_update.py（与 tri-intent 同源一致，按 --slug 自动适配）。
> 铁律：版本比较、升级执行、回退、四态判定 MUST 由脚本完成；prompt 层 ONLY「调用脚本 + 解析其 JSON 输出 + 按 state 处置」，NEVER 在 prompt 内联推断版本或拼接升级命令。修订规则只改真源一处，脚本与真源保持同步。

执行方式（MUST）

1. 任一执行入口启动后、核心执行前，运行脚本并取 JSON：
   bash python scripts/check_update.py --slug tri-bs --json
   - 节流：结果持久化缓存（默认 1440 分钟 / 24h 仅校验一次），--force 强制重查，--dry-run 只判定不真升级。
   - 脚本自动定位 skill 目录（默认脚本上级目录），--slug 显式指定自身 slug（如上）。
2. 解析 JSON 的 state 字段，按态处置：
   - A 校验通过 / B 离线降级 / C 通道降级 / D 升级降级 → 一律放行，进入后续阶段；并据 warnings / notes / actions 在交付物或日志标注对应口径（如「版本校验未完成（离线）」「版本陈旧·自动升级失败」）。
   - BLOCK → 绝对禁止执行，按 block_code（P2/P3/P4）输出结构化恢复指引（手动命令见 actions 字段）。
3. 退出码语义（供 shell 编排）：0=A 放行；10=B；11=C；12=D；20=阻断。判定规则：<20 放行，>=20 阻断。脚本自身异常时兜底降级放行（退出码 11），NEVER 因版本门自身故障导致 skill 无法启动。

执行要点

1. 端点取自配置：API 主机 MUST 读自 ~/.skillhub/metadata.json，NEVER 硬编码域名。营销官网 skillhub.cn 与 API 主机 api.skillhub.cn 是两个站点——官网对任意路径都返回 200 + HTML 兜底页，绝不可作校验端点。读不到配置即判通道不可用。
2. 校验请求：GET {api_host}/api/v1/skills/{slug}，超时 ≤ 5s，失败重试 1 次，会话内仅校验一次。
3. 最新版取值：latestVersion.version，缺失时回退 skill.tags.latest。平台不提供 min_compatible / deprecated / checksum_sha256 / signature，NEVER 依赖这些字段。
4. 响应有效性（三条件同时成立）：HTTP 200 且 Content-Type 含 application/json 且 能解析出版本字段。仅看状态码会被 SPA 兜底页击穿。
5. 版本比较：按 SemVer 逐段整数比较，NEVER 字符串比较。
6. 四态判定：
   - A 校验通过（响应有效且 current >= latest）→ 放行。
   - B 离线降级（网络不可达）→ 标注「版本校验未完成（离线）」后以当前版本继续。
   - C 通道降级（可达但响应无效 / 404 / 405 / 读不到配置）→ 标注「版本校验未完成（通道不可用）」+ 输出通道异常告警后继续。
   - D 升级降级（陈旧且已真实尝试自动升级但未完成）→ 标注「版本陈旧·自动升级失败」+ 输出手动升级指引后继续。
   - 四态 NEVER 用于绕过「已检出陈旧却不尝试升级」——MUST 先真实执行一次自动升级，失败方可落 D 态。
7. 更新通道（自动执行）：检出陈旧 MUST 自动执行 skillhub upgrade <slug> → skillhub verify <slug>，升级前备份、签名明确不一致则回滚。CLI 不在 PATH 时回退 python ~/.skillhub/skills_store_cli.py upgrade <slug>；CLI 缺失或升级失败 → 落 D 态降级继续，NEVER 阻断。以 junction 指向源码树的 source: local skill 跳过自动更新，改为提示维护者手动同步。命令细则、CLI 定位顺序与已知陷阱见真源。
8. 阻断条件 P1–P4 与四处版本同步点见真源；发布前 MUST 通过 python tri-forge/scripts/sync_registry.py --check。

处理流程

> 执行顺序固定：§版本检查与更新机制（第零步）→ 上游依赖检测 → 读取快照 §三 → 核心执行。版本检查未通过前 NEVER 进入以下任一执行步骤。

> 轻量工作流，无审批门；多角度发散后按格式组织候选，单轮即交付。

步骤 1：快照校验与发散定界

1. 读取快照 §三，校验 intent.L2_核心意图 = I16
   - L2 越界 → 停止，回退 tri-intent 重新路由
2. 提取发散语境要素：
   - D1_任务领域 → 发散的专业域（技术/产品/运营/通用等）
   - D5_确定性 → 通常为「开放发散」，决定发散广度
   - D4_格式约束 → 候选数量下限 / 呈现格式
   - 任务要点 → 发散须覆盖的方向与约束
3. 明确发散主题、边界、约束；若 任务要点 缺失关键约束 → 回退 tri-intent 的 clarify-gate 澄清
4. 声明自检句：「本次意图=I16，已读取快照，发散主题=<主题>，候选数量下限=<D4约束>」

步骤 2：多角度发散

> 三种发散方法与组合策略见 §创意发散方法论。至少组合使用两种发散方法，确保候选间有差异性（非同质化）。先横向穷举铺面，再纵向深挖或跨域联想补充异质化候选。

步骤 3：候选评估与组织

1. 对每个候选拟定四要素：标题 + 一句话说明 + 适用场景 + 优劣简评
2. 候选评估维度（用于优劣简评）：
   - 可行性（落地难度）
   - 新颖性（是否常规思路）
   - 与 任务要点 约束的契合度
3. 按 D4_格式约束 组织：分点列表 / 表格 / 卡片式
4. 候选数量满足 D4 约束下限；超出时保留评估较高的

步骤 3.5：任务要点覆盖核对

1. 逐项核对快照 任务要点 清单，确认每条已在候选集合中体现
2. 若某条未体现 → 补充对应候选，或显式标注「该条无法发散」并说明原因（如「该条要求具体实施步骤，属收敛范畴非发散范畴」）
3. 输出核对结果，确认全覆盖或标注未覆盖项

步骤 4：交付

1. 输出候选集合（含每个候选的完整评估信息）
2. 交付末尾明确声明「本 skill 只发散不收敛；若需收敛到单一方案，请触发 tri-ask 的 I04 决策辅助」
3. 若用户后续追问 → 由 tri-meta 接住 M03 追加细化信号，重路由回本 skill 补充候选

交付产物

> 轻量 skill，无链路文档；候选集合即交付物。

一、候选集合结构

每个候选 MUST 含以下字段：

二、呈现格式

• 按 D4_格式约束 选择：分点列表 / 表格 / 卡片式
• 候选间用编号或标题清晰分隔，便于用户逐个独立评估
• 候选数量满足 D4 约束下限

三、发散声明

• 交付末尾 MUST 声明「本 skill 只发散不收敛」
• 收敛路径指引：触发 tri-ask 的 I04 决策辅助

质量标准

落盘规则

• 快照由 tri-intent 已落盘于 .tribro/snapshots/
• 本 skill 为轻量发散，候选集合不落盘（即时对话回应）
• 若用户明确要求保存候选集合 → 按用户指定路径落盘（非 .tribro/）

目录结构

tri-bs/
├── SKILL.md              # 主入口：头脑风暴工作流定义 + 创意发散方法论 + 候选四要素
├── README.md             # skill 简介与使用说明
├── CHANGELOG.md          # 版本变更历史
├── _meta.json            # 发布元数据（slug / version / ownerId / publishedAt）
└── tests/                # 测试用例
    └── tri-bs-full-testcases.md   # 全场景全能力测试用例

> 本 skill 为轻量发散型，无 templates/（候选集合不落盘，即时对话回应）。