意图识别总路由（第一层：顶层意图三分法）
> 依据 OpenAI《How People Use ChatGPT》三分法 + 学术界问题意图分类学构建的 MECE 分类体系入口。任何一次用户提问必然落入且仅落入一个大类。
强制执行契约（Execution Contract · 最高优先级）
> 本节定义 skill「被激活后必须做什么」，优先级高于 Agent 的通用默认行为。引用/读取本文件即视为激活本工作流，不得仅将其当作参考文档。
- 版本检查前置硬门（第零步）：MUST 先通过 §版本检查与更新机制（按
tri-forge/references/version-check-spec.md契约连接 skillhub 官方通道校验版本，非最新版 MUST 自动执行skillhub upgrade <slug>升级；升级成功后继续，升级通道不可用则标注 D 态降级继续）——此为执行流程第零步，优先于后续所有步骤。版本检查完成前 NEVER 进入路由步骤。本条目优先级高于所有其他强制前置条目。端点 MUST 读取自配置，NEVER 硬编码skillhub.cn官网域名（营销 SPA 非校验端点，实测 API 主机为api.skillhub.cn）。 - 强制前置：收到任何新用户提问，MUST 先执行「路由步骤」完成意图识别，再产出快照交接下游，NEVER 跳过直接给成果物。
- 唯一交付产物：非「不落盘」类意图，MUST 产出
.tribro/snapshots/<命名>.md（模板见templates/snapshot.md），并同时覆盖写.tribro/LATEST.md指针文件（格式见 §快照定位契约），供下游 skill 无歧义定位。快照是本 skill 的唯一交付产物——内含用户原始提问、意图分析过程、结构化结论数据（intent + 置信度 + dimensions + 任务要点 + 下游路由建议 + 下游 slug）。若.tribro/目录不存在，MUST 先创建该目录再落盘。禁止产出 requirements.md、design.md、tasks.md、implements.md、reports.md 等任何下游交付物——那些由下游 skill 依据快照自行产出。 - 可选轻量复述：识别完成后，可至多一次将快照中的结构化结论复述给用户，供其发现明显误识别即可。不设回炉循环、不设多轮审批。当 clarify-gate 已完成澄清、需求已充分时，连这一次复述都可跳过。原则上无需再次向用户确认真实意图。
- 职责边界：本 skill 仅负责「识别意图分类（L1/L2）→ 标注正交维度（D1–D5）→ 需求模糊时主动澄清（clarify-gate）→ 产出快照 → 交接下游 skill」。设计、拆解、执行、测试、审批等一切下游职责均不属于本 skill。
- 置信度强制：MUST 为本次识别给出 0–1 置信度自评并写入快照（见 §置信度机制）。置信度 <0.60 时 NEVER 直接交接下游，MUST 回退 clarify-gate；<0.85 或存在竞争意图时 MUST 执行一次轻量复述。
- 下游分发强制：产出快照后 MUST 执行 §下游依赖检测——脚本判定未安装时 MUST 走两道确认门（门① 安装确认 → 发送安装 prompt → 复检 → 门② 执行确认），NEVER 未经门① 同意擅自安装，NEVER 未经门② 同意擅自执行下游，NEVER 因下游缺失就由本 skill 越界代答。
- 自检：作答前用一句话声明「本次意图=<L2>，置信度=<数值/档位>，版本检查=<已通过/离线降级/通道降级/升级降级>，已产出快照+LATEST 指针，路由建议=<下游 slug>，下游检测=<已安装/未安装>，分发=<直接交接/门①待确认/门①已拒/已安装-门②待确认/门②已拒>」，若与上述规则冲突则停止并纠正。
| 若命中 | 落盘 | 下游路由建议 |
|---|---|---|
| I01–I05（Asking 咨询求解） | 快照 | 咨询作答 skill |
| I06–I10（内容生成/改写/翻译/总结/分析） | 快照 | 内容处理 skill |
| I11（编码开发） | 快照 | 编码开发 skill（tri-coding；全生命周期子类→tri-sdlc） |
| I12（调试修复） | 快照 | 调试修复 skill（tri-fix） |
| 代码审查（review/审查/CR） | 快照 | 代码审查 skill（tri-review） |
| I13（规划拆解） | 快照 | 规划拆解 skill（工作流设计子类→tri-workflow；全生命周期子类→tri-sdlc） |
| I14（操作执行） | 快照 | 操作执行 skill（工作流编排子类→tri-workflow；loop/domain 创建子类→tri-loop；全生命周期子类→tri-sdlc） |
| I15（多媒体生成） | 快照 | 多媒体生成 skill |
| I16（头脑风暴） | 快照 | 头脑风暴 skill |
| I21（蒸馏造物） | 快照 | 蒸馏造物 skill（tri-god） |
| I17–I20（Expressing 表达陪伴） | 不落盘 | 表达陪伴 skill（直接自然回应） |
| M01–M04（Meta 元操作） | 快照 | 元操作处理 skill |
| M05（中止确认） | 不落盘 | 即时叫停/放行 |
| 需求模糊/矛盾/缺关键信息 | 先澄清 | 先走 clarify-gate 补齐后再识别 |
触发时机
- 任何新用户提问进入工作流的第一步
- 需要将模糊、复合的用户输入路由到精确处理链路时
不触发场景（Not-Trigger）
本 skill 不接手以下情形（命中即转出，仅产出快照后交接，不越界产出）：
- 「意图已被上游指定 / 快照已存在」——直接由对应下游 skill 读取快照执行，本 skill 不重识别。
- 「产出需求/设计/任务清单/实现报告/最终回答」——识别后由各下游 skill 依据快照自行产出，本 skill 不代做。
- 「轻量咨询作答 / 具体领域执行（编码、翻译、写作等）」——属各 L2 落点 skill（tri-ask / tri-coding / tri-content 等），本 skill 只做识别与路由。
第一层判定（四选一，互斥穷尽）
| 大类 | 判定信号 | 用户心智 | 占比 | 下钻目录 |
|---|---|---|---|---|
| A. Asking 咨询求解 | 问「是什么/为什么/怎么办/哪个好」，期望获得知识、建议、判断 | 把 AI 当顾问/信息源 | ~49% | asking/ (I01–I05) |
| B. Doing 委托执行 | 说「帮我写/做/改/算/查代码」，期望拿到可直接用的成果物 | 把 AI 当执行者 | ~40% | doing/ (I06–I16 + I21 + 代码审查) |
| C. Expressing 表达陪伴 | 倾诉、闲聊、扮演、表态，不追求明确产出 | 把 AI 当倾听者/伙伴 | ~11% | expressing/ (I17–I20) |
| Meta 元操作 | 针对「上一轮回复」或「AI 本身」发问 | 关于对话本身 | 边缘补全 | meta/ (M01–M05) |
路由步骤
> 执行顺序固定：§版本检查与更新机制（第零步）→ 下游依赖检测 → 路由识别 → 产出快照 → 交接下游。版本检查未通过前 NEVER 进入以下任一路由步骤。
- 版本检查（第零步）：MUST 先执行 §版本检查与更新机制，通过后方可进入核心路由流程。版本检查未通过前 NEVER 进入后续步骤。
- 提取核心动词：识别用户「想让 AI 做什么动作」，这是主分类键
- 一层判定：按上表信号定位到 A/B/C/Meta 之一（若跨界如「头脑风暴」，取用户最终期望产出动作，见
doing/I16-brainstorm） - 二层下钻：进入对应目录，激活匹配的二级意图 skill 精准识别
- 代码审查特殊路由：若核心动词为「审查/review/CR/code review」，L2 标注为「代码审查」（Doing 大类特殊路由项），
下游路由建议指向 tri-review，详见doing/code-review.md - 全生命周期（SDLC）子类路由：若 L2 判定为 I11、I13 或 I14，且任务要点含全生命周期语义（全生命周期/SDLC/研发流程/立项到上线/端到端交付/完整开发流程/从需求到发布/阶段门禁），
L3_子意图标注为sdlc，下游路由建议覆写为 tri-sdlc，L2 保持 I11/I13/I14 不变，详见doing/sdlc-design.md。本子类优先级高于第 6、7 步的 workflow / loop 子类：同时命中时以「交付对象是一个真实项目，还是一份流程定义/一个长期循环体」判定归属。 - 工作流设计子类路由：若 L2 判定为 I13 或 I14，且任务要点含工作流设计语义（工作流/流水线/审批流/自动化流程/CI-CD/编排/pipeline），且未命中第 5 步 sdlc 子类，
下游路由建议覆写为 tri-workflow，L2 保持 I13/I14 不变，详见doing/workflow-design.md - loop/domain 创建子类路由：若 L2 判定为 I14，且任务要点含 loop/domain 创建语义（loop/domain/循环/知识库/beat/workstream/charter/cadence），且未命中第 5 步 sdlc 子类，
下游路由建议覆写为 tri-loop，L2 保持 I14 不变，详见doing/loop-design.md - 蒸馏造物路由：若核心动作为「蒸馏/提炼/萃取/distill/造一个skill/把XX做成skill/复刻某人/复刻工作流」且期望产出为「一个可复用的新 skill」，L2 判定为 I21 蒸馏造物，
下游路由建议指向 tri-god，详见doing/I21-distill.md。注意与 I11 编码开发边界：I11 产出的是「业务代码/程序」，I21 产出的是「可独立调用的 skill（含方法论蒸馏）」。 - 多意图消歧：一句含多意图时，取「最终期望产出」为主意图，其余降为辅助标签
- 边缘兜底：无法归入任一 I/M 项时，落
expressing/I19-chitchat，确保 100% 有落点 - 澄清前置：若需求模糊/矛盾/缺关键信息，先激活
clarify-gate对齐后再继续 - 动作泛化降级：若判为 B.Doing 但核心动作过于泛化（如「搞定」「搞一下」「处理一下」），无法映射到具体 I06–I16 或 I21 产出动作，降级归
asking/I03 建议咨询（本质是求助如何处理），并强制走clarify-gate澄清后再重路由。
- 关键边界：降级判定以「动作能否映射到具体 I06–I16 或 I21」为唯一标准，非「对象是否缺失」。
- 动作明确但对象缺失（如「优化一下」「翻译一下」「改写一下」）：动作可映射到 I07/I08 等，不降级，直接走clarify-gate补齐对象后保持原意图。
- 动作泛化无法映射（如「帮我搞定那件事」「搞一下」）：降级归 I03。
MECE 保证
- 完全穷尽：任一提问 = 第一层(A/B/C/Meta) × 第二层(I01–I21、CR 或 M01–M05) × 第三层(D1–D5 标签)
- 相互独立：以「核心动作」为唯一主键判定，杜绝类别重叠
- 兜底闭环：I19 闲聊娱乐为 Expressing 兜底，保证零覆盖空白
- 落点总数：27 个（I01–I21 共 21 个 + CR 代码审查 1 个 + M01–M05 共 5 个）。
CR 为无数字编码的特殊路由项，在机器可读字段中统一以CR表示，确保编码体系闭合可枚举。
置信度机制（识别可靠性量化）
> 意图识别必须给出可量化的自评置信度，据此决定「直接交接 / 强制复述 / 回退澄清」，
> 避免低可靠性识别静默流入下游造成错误执行。阈值与 hooks/intent-gate.py 常量保持单一事实源。
一句话摘要：四维加权打分（动词明确性 0.35 / 语料匹配度 0.25 / 邻近意图排除强度 0.25 / 上下文完备度 0.15）得出 0–1 置信度，按三档处置——高 ≥0.85 直接交接可跳过复述、中 0.60–0.85 交接但强制复述一次、低 <0.60 禁止交接强制回退 clarify-gate；主次分差 < 0.15 时即使高档也强制复述。
> 📖 详见 references/confidence-mechanism.md——含四维权重表、三档阈值处置表、竞争意图规则、Expressing 例外、未评估兜底、置信度三字段落盘约定与 hooks/intent-gate.py 校验命令。
目录结构
tri-intent/
├── SKILL.md 主入口（本文件）：三分法判定 + 路由步骤 + 落盘规则 + 下游依赖检测
├── README.md skill 说明与快速上手
├── CHANGELOG.md 版本变更记录
├── asking/ I01 信息查询 / I02 概念解释 / I03 建议咨询 / I04 决策辅助 / I05 推理计算
├── doing/ I06–I16 生成/改写/翻译/总结/分析/编码/调试/规划/执行/多媒体/头脑风暴 + I21 蒸馏造物 + 代码审查特殊路由 + 工作流设计/loop/全生命周期（SDLC）子类路由
├── expressing/ I17 角色扮演 / I18 情感陪伴 / I19 闲聊娱乐 / I20 观点表达
├── meta/ M01 澄清追问 / M02 纠错反馈 / M03 追加细化 / M04 能力询问 / M05 中止确认
├── clarify-gate/ 澄清对齐门（G1 苏格拉底式 / G2 批判式反问）
├── hooks/ intent-gate.py（识别结果呈现器，可选轻量复述）
├── references/ 静态参考资料（非流程逻辑）
│ ├── confidence-mechanism.md 置信度机制完整参考（四维权重 + 三档阈值）
│ ├── snapshot-contract.md 快照定位契约与异常处置表（下游必读）
│ └── intent-confirm-card.md 意图确认卡 v2 完整 YAML 模板与填充规则
├── templates/ snapshot.md（唯一交付产物模板）
└── tests/ 测试用例
版本检查与更新机制（强制技术约束 · 硬红线）
> 家族级强制技术约束，优先级与「强制执行契约」同级。skill 任一执行入口启动后的第零步，先于核心执行阶段。
> 细则唯一真源：tri-forge/references/version-check-spec.md。可执行实现（single source of truth for logic）：tri-intent/scripts/check_update.py。
> 铁律：版本比较、升级执行、回退、四态判定 MUST 由脚本完成；prompt 层 ONLY「调用脚本 + 解析其 JSON 输出 + 按 state 处置」，NEVER 在 prompt 内联推断版本或拼接升级命令。修订规则只改真源一处，脚本与真源保持同步。
执行方式（MUST）
- 任一执行入口启动后、核心执行前，运行脚本并取 JSON：
bash python tri-intent/scripts/check_update.py --json
- 节流：结果持久化缓存（默认 1440 分钟 / 24h 仅校验一次），--force强制重查，--dry-run只判定不真升级。
- 脚本自动定位 skill 目录（默认脚本上级目录），可用--slug/--skill-dir显式指定。 - 解析 JSON 的
state字段，按态处置：
-A校验通过 /B离线降级 /C通道降级 /D升级降级 → 一律放行，进入后续阶段；并据warnings/notes/actions在交付物或日志标注对应口径（如「版本校验未完成（离线）」「版本陈旧·自动升级失败」）。
-BLOCK→ 绝对禁止执行，按block_code（P2/P3/P4）输出结构化恢复指引（手动命令见actions字段）。 - 退出码语义（供 shell 编排）：
0=A 放行；10=B；11=C；12=D；20=阻断。判定规则：<20放行，>=20阻断。脚本自身异常时兜底降级放行（退出码 11），NEVER 因版本门自身故障导致 skill 无法启动。
行为约束（细则与字段语义见真源，NEVER 在 prompt 重述）
- 端点 MUST 读自
~/.skillhub/metadata.json，NEVER 硬编码；营销官网skillhub.cn与 API 主机api.skillhub.cn是两站，官网 SPA 兜底页 NEVER 作校验端点。 - 响应有效性三条件（§2.4）、SemVer 逐段比较（§2.6）、四态判定（§四）、junction/
source:local单源跳过自动升级（§三）、四处版本同步（§六）、P1–P4 阻断（§五）均由脚本忠实实现。 - 发布前 MUST 通过
python tri-forge/scripts/sync_registry.py --check。
意图确认卡（通用主模板 · 识别结果结构化呈现）
> 用法：意图识别完成后，用识别结果填充意图确认卡 v2 模板，作为快照 §三 结构化结论区的内容。
> - 对用户：用「一句话复述」+「待确认项」让用户 3 秒看懂自己的需求
> - 对 LLM：intent / dimensions 等结构化字段可被下游 skill 直接读取执行，无需再次意图识别
> - 各分类目录下有该组的专属细化模板，字段更贴合场景，优先使用专属模板
一句话摘要：确认卡含五段——一句话复述 + intent 机器执行区（L1/L2/L3/辅助意图/置信度三字段）+ dimensions 正交标签区（D1–D5）+ 任务要点/澄清门状态/待确认项/交付预期 + 下游路由建议/下游 slug；填充遵循「必填不留空、复述先行、机器区自洽、澄清优先」四条规则。
> 📖 详见 references/intent-confirm-card.md——含完整 YAML 模板、四条填充规则与字段-下游消费对照表。
产出物机制（意图识别的最终交付）
> 意图识别完成后，产出唯一交付产物——快照（snapshot.md），交接下游 skill。不产出任何下游交付物。
一、文件命名规范
统一格式：<问题类型>_<日期>_<时间>_<会话ID>
- 问题类型：取 L2 意图编码，如
I08、I11、M01 - 日期：
YYYYMMDD，如20250211 - 时间：
HHMMSS，如143022 - 会话ID：取当前对话会话 ID（
chat_session_id，由 IDE 通过 system reminder 提供）的前 8 位，如6a5c037d，用于区分同秒内的多次提问并关联同一会话内的多次产出 - 示例：
I08_20250211_143022_6a5c037d
二、存放目录
.tribro/ # 若不存在则先创建
├── snapshots/ 快照（唯一交付产物，溯源+交接，永不覆盖）
│ └── <命名>.md
└── LATEST.md 指针文件（始终指向本会话最新快照，覆盖写）
快照定位契约（下游 skill 必读）
> 快照「永不覆盖」会导致目录持续堆积，且文件名含会话 ID——下游 skill 无法凭空推算该读哪个文件。
> 故 tri-intent MUST 在落盘快照的同时维护指针文件（.tribro/LATEST.md，覆盖写）。
一句话摘要：下游 skill 按四级优先级定位快照——① 读 .tribro/LATEST.md 的 snapshot_path（推荐）→ ② 会话 ID 匹配的最新快照 → ③ 全局最新且修改时间 ≤ 30 分钟（超时即过期不得使用）→ ④ 读到后 MUST 校验 intent.L2_核心意图 属于本 skill 认领范围，越界即停止并回退重路由。快照缺失/过期/损坏/字段不全/意图越界/低置信度六类异常均有统一处置动作，NEVER 静默按空上下文执行或猜测性修补。
> 📖 详见 references/snapshot-contract.md——含四级定位优先级细则、LATEST.md 最小格式示例、六类快照异常处置表，以及与下游「上游依赖检测」三态（A/A0/B/C）的对应速查。
三、快照内容
| 产出物 | 文件名 | 内容 | 用途 |
|---|---|---|---|
| 快照 | <命名>.md |
① 用户原始提问原文 ② 意图分析过程（L1/L2/D1–D5 逐步判定推导） ③ 结构化结论（意图确认卡完整字段 + 下游路由建议） | 供用户后续溯源 + 供下游 skill 直接读取执行 |
> 模板文件见 templates/snapshot.md。快照是 tri-intent 的唯一产出，下游 skill 读取快照 §三 结构化结论后自行产出需求文档、设计文档、任务清单等链路文档。
落盘规则
> Flow 三态（意图识别的落盘去向枚举）：落盘快照 | 不落盘 | 先澄清
- 先澄清（
clarify-gate命中优先）： - 需求模糊/矛盾/缺关键信息 → 先经
clarify-gate（G1/G2）反问补齐 - 流程：反问补齐 → 回填意图确认卡 → 产出快照
- 例外：Expressing（I17–I20）即使需对齐（如复杂/敏感人设 Gate=是），也仅在对话内即时对齐设定，不走落盘的「先澄清」流程，Flow 仍为「不落盘」
- 落盘快照（默认）：
- 除 Expressing/M05 外的所有意图
- 流程：识别完成 → 填充意图确认卡 → 产出快照
snapshot.md→ 可选轻量复述一次 → 交接下游 skill - 落盘路径：
.tribro/snapshots/<命名>.md+ 指针.tribro/LATEST.md；.tribro/目录不存在时 MUST 先创建（见 §强制执行契约 第 2 条） - 不落盘（免打断/即时响应）：
- Expressing（I17–I20，默认）、Meta 的 M05 中止确认
- 流程：直接自然回应，不生成快照
四、可选轻量复述（识别结果呈现器）
意图识别产出快照后，可选将快照中的结构化结论复述给用户一次：
- 复述内容：一句话复述 + L2 意图 + 任务要点 + 下游路由建议
- 目的：供用户发现明显误识别，而非审批执行计划
- 不设回炉循环：用户指出误识别时，更新快照即可，不设多轮审批门
- 可跳过：当 clarify-gate 已完成澄清、需求已充分时，连这一次复述都可跳过
> 复述渲染由 hooks/intent-gate.py 提供（可选调用），定位为「识别结果呈现器」而非「执行前闸门」。
下游依赖检测（产出快照后）
> 本 skill 产出快照后，MUST 检测 下游路由建议 指向的下游 skill 是否已安装。仅对「落盘快照」类意图执行检测——「不落盘」类（Expressing I17–I20、M05）直接自然回应，无下游 skill 需交接，跳过检测。
一、路由映射表
| L2 意图 | 下游 skill slug | skill 目录名 |
|---|---|---|
| I01–I05 | tri-ask | tri-ask/ |
| I06–I10 | tri-content | tri-content/（默认）；文章撰写子类→tri-article/（见下）；PM 产物子类→tri-pm/（见下）；格式转换子类族（I08）→ tri-pdf2md/、tri-docx2md/、tri-pptx2md/、tri-xlsx2md/、tri-html2md/（见下）；知识库搭建子类（I08）→tri-wiki/（见下）；架构可视化子类（I10）→tri-html/；审计清单子类（I10）→tri-checklist/；深度剖析子类（I10）→tri-code-analyzer/（见下） |
| I11 | tri-coding | tri-coding/（默认）；前端设计方向子类→tri-frontend-design/（见下）；动效实现子类→tri-lottie/（见下）；全生命周期子类→tri-sdlc/ |
| I12 | tri-fix | tri-fix/ |
| 代码审查（CR） | tri-review | tri-review/ |
| I13 | tri-plan | tri-plan/（默认）；工作流设计子类→tri-workflow/；全生命周期子类→tri-sdlc/ |
| I14 | tri-action | tri-action/（默认）；工作流编排子类→tri-workflow/；loop/domain 创建子类→tri-loop/；全生命周期子类→tri-sdlc/ |
| I15 | tri-mm | tri-mm/（默认）；音乐创作子类→tri-mm/ 委派 tri-music/（二跳，见下） |
| I16 | tri-bs | tri-bs/ |
| I21 | tri-god | tri-god/ |
| M01–M04 | tri-meta | tri-meta/ |
| I17–I20 | tri-express | 「不落盘」类，跳过检测 |
| M05 | — | 「不落盘」类，跳过检测 |
> I15 音乐创作子类说明（二跳路由）：当任务要点含音乐创作语义（写歌/作词/AI 音乐/Suno/海绵音乐/抖音神曲 等）时，
> L3_子意图 标注为 music，下游路由建议 仍指向 tri-mm，由 tri-mm 依其 §子意图委派 章节转交 tri-music。
> tri-intent 不直接路由到 tri-music，以保持「一个 L2 意图对应一个一跳下游」的 MECE 约束。
> 下游依赖检测在此场景需同时检测 tri-mm/ 与 tri-music/，任一缺失均提示安装。
> I06 文章撰写子类说明（子类路由）：当 L2=I06 内容生成，且任务要点含文章撰写语义（写文章/去 AI 化文章/技术文章/博客/个人风格长文/爆款图文）时，
> L3_子意图 标注为 article，下游路由建议 直接覆写为 tri-article（一跳，无需中介 skill）。
> 此设计与 I15 音乐子类保持一致：「一个 L2 意图（I06）对应一个一跳下游」，仅由 L3_子意图 区分 tri-content（通用内容）与 tri-article（去 AI 化长文）。
> 下游依赖检测在此场景仅需检测 tri-article/，缺失即提示安装。
> I06 PM 产物子类说明（子类路由）：当 L2=I06 内容生成，且任务要点含 PM 产物语义（写 PRD/需求文档/战略画布/产品路线图/OKR/GTM/竞品分析/产品数据分析）时，
> L3_子意图 标注为 pm，下游路由建议 直接覆写为 tri-pm（一跳，无需中介 skill）。
> 此设计与 I06 article 子类保持一致：仅由 L3_子意图 区分 tri-content（通用内容）、tri-article（去 AI 化长文）与 tri-pm（PM 领域产物），三者互斥不重叠。
> 下游依赖检测在此场景仅需检测 tri-pm/，缺失即提示安装。tri-pm 的上游依赖检测为三态逻辑（快照/引导/降级），与本表覆写路由对称。
> I10 架构可视化子类说明（子类路由）：当 L2=I10 分析处理，且任务要点含项目架构可视化语义（分析项目架构/生成架构可视化 HTML/画项目架构图/项目全貌报告/架构师视角分析项目）时，
> L3_子意图 标注为 arch-viz，下游路由建议 直接覆写为 tri-html（一跳）。
> 此设计与 I06 article 子类保持一致：「一个 L2 意图（I10）对应一个一跳下游」，仅由 L3_子意图 区分 tri-content（通用分析）与 tri-html（架构可视化）。
> 下游依赖检测在此场景仅需检测源码树 tri-html/，缺失即提示安装。详见 doing/I10-analyze.md §子类路由。
> I10 审计清单子类说明（子类路由）：当 L2=I10 分析处理，且任务要点含项目审计清单语义（生成审计 checklist/项目自检清单/改动审查测试清单/质量保障 checklist/commit 提交前检查清单）时，
> L3_子意图 标注为 audit-checklist，下游路由建议 直接覆写为 tri-checklist（一跳）。
> 此设计与 I10 arch-viz 子类保持一致：「一个 L2 意图（I10）对应一个一跳下游」，仅由 L3_子意图 区分 tri-content（通用分析）、tri-html（架构可视化）与 tri-checklist（审计清单）。
> 下游依赖检测在此场景仅需检测源码树 tri-checklist/，缺失即提示安装。详见 doing/I10-analyze.md §子类路由。
> I10 深度剖析子类说明（code-analyzer · 子类路由）：当 L2=I10 分析处理，且任务要点含代码库深度剖析语义（剖析代码库/帮我读懂这个项目/接手项目全维度分析/代码级深度剖析/吃透代码库/代码库 onboarding）时，
> L3_子意图 标注为 code-analyzer，下游路由建议 直接覆写为 tri-code-analyzer（一跳）。
> 与 arch-viz 子类 MECE：产出物是可视化 HTML 图表（画架构图/可视化）→ tri-html；产出物是深度剖析 Markdown 报告（代码级证据+上手指南）→ tri-code-analyzer；同时命中按用户指定输出物形态判定（详见 doing/I10-analyze.md §冲突消解）。
> 下游依赖检测需检测源码树 tri-code-analyzer/ 或 .tribro/skills/tri-code-analyzer/，缺失即提示安装。
> I11/I13/I14 全生命周期子类说明（子类路由）：当 L2 ∈ {I11, I13, I14}，且任务要点含全生命周期语义（全生命周期/SDLC/研发流程/立项到上线/端到端交付/完整开发流程/从需求到发布/阶段门禁）时，
> L3_子意图 标注为 sdlc，下游路由建议 覆写为 tri-sdlc（一跳）。三个 L2 共用同一子类键，因为「按完整流程做个项目」可能以编码（I11）、规划（I13）或推进执行（I14）为表层动词，但交付对象同为「一个走完九阶段的真实项目」。
> 优先级：sdlc 子类高于 workflow 子类与 loop 子类；同时命中时以「交付对象是真实项目 / 流程定义产物 / 长期循环体」判定，详见 doing/sdlc-design.md。
> 下游依赖检测在此场景仅需检测 tri-sdlc/，缺失即提示安装。tri-sdlc 的 9 个阶段子SKILL 位于 tri-sdlc/children/，随包分发，不是顶层 skill，不参与本表路由。
> I11 前端设计方向子类说明（子类路由）：当 L2=I11 编码开发，且任务要点为「界面设计方向/风格锚点选定/配色字体结构方案/动效设计与评审/多变体探索」等设计语义而非代码实现时，
> L3_子意图 标注为 frontend-design，下游路由建议 直接覆写为 tri-frontend-design（一跳）。
> 判定要点：产出物是设计方向与令牌规格（CSS 令牌/动效基线/多变体方案）→ tri-frontend-design；产出物是可运行代码实现 → tri-coding 默认。「实现这个页面」仍走 tri-coding，仅设计先行场景覆写。
> 下游依赖检测在此场景仅需检测 tri-frontend-design/，缺失即提示安装。
> I11 动效实现子类说明（motion · 子类路由）：当 L2=I11 编码开发，且任务要点含「生成动画/动效代码、Lottie 集成、转场/微交互/加载态实现、动画代码审查修复」等动效实现语义时，
> L3_子意图 标注为 motion，下游路由建议 直接覆写为 tri-lottie （一跳）。
> 与 frontend-design 子类 MECE：产出设计方向与令牌规格 → tri-frontend-design；产出动画代码/集成/审查 → tri-lottie；一般编码 → tri-coding 默认。
> 下游依赖检测在此场景需同时检测 .tribro/skills/tri-lottie/ 或源码树 tri-lottie/，缺失即提示安装。
> I08 PDF 转换子类说明（子类路由）：当 L2=I08 翻译转换，且任务要点含 PDF 转 Markdown 语义（PDF 转 MD/转成 Markdown/pdf2md/PDF 无损转换/把这份 PDF 转成 md）时，
> L3_子意图 标注为 pdf2md，下游路由建议 直接覆写为 tri-pdf2md（一跳，无需中介 skill）。
> 此设计与 I06 article 子类保持一致：「一个 L2 意图（I08）对应一个一跳下游」，仅由 L3_子意图 区分 tri-content（通用转换/翻译）与 tri-pdf2md（PDF→MD 专用编排+质量保障）。
> 下游依赖检测在此场景仅需检测源码树 tri-pdf2md/，缺失即提示安装。详见 doing/I08-translate.md §PDF 转换子类。
> I08 格式转换子类族说明（x2md 族 · 子类路由）：当 L2=I08 翻译转换，且任务要点含 Word/PPT/Excel/HTML 转 Markdown 语义（Word 转 MD/docx2md、PPT 转 MD/pptx2md、Excel 转 MD/xlsx2md、HTML 转 MD/html2md；扩展名族：.docx/.docm/.doc、.pptx/.pptm/.pps/.pot/.ppsx/.ppsm/.ppt、.xlsx/.xlsm/.xls/.xlsb/.csv、.html/.htm；.wps 同格式兼容；五格式 SKIP 语义见下游 preflight）时，
> L3_子意图 分别标注为 docx2md / pptx2md / xlsx2md / html2md，下游路由建议 直接覆写为对应 x2md skill（一跳，无需中介 skill）。
> 与 pdf2md 子类同构：一个 L2 意图（I08）对应一个一跳下游，仅由 L3_子意图 区分目标格式；五个 x2md skill 之间 MECE 不重叠（各认领一种源格式）。
> 下游依赖检测在此场景仅需检测源码树对应的 tri-<fmt>2md/，缺失即提示安装。详见 doing/I08-translate.md §格式转换子类族。
> I08 知识库搭建子类说明（wiki · 子类路由）：当 L2=I08 翻译转换，且任务要点含知识库搭建语义（搭建知识库/建知识库/把文档整理成知识库/构建 wiki/知识库生成/批量文档转知识库）时，
> L3_子意图 标注为 wiki，下游路由建议 直接覆写为 tri-wiki（一跳，无需中介 skill）。
> 与 pdf2md 子类同构：仅由 L3_子意图 区分——单文档转换走 x2md 族单技能，文档集→知识库（信息架构/组织/MOC/索引）走 tri-wiki；tri-wiki 在 C 阶段反向委派 x2md 族完成批量转换，两层不竞争。
> 下游依赖检测在此场景仅需检测源码树 tri-wiki/，缺失即提示安装。详见 doing/I08-translate.md §知识库搭建子类。
> I08 翻译与 tri-translate 边界说明：I08 翻译转换统一路由到 tri-content（通用内容处理），tri-translate 为横向方法论 skill（意译优先/直译次之/不译兜底），
> 不由 tri-intent 依 L2 直接路由；tri-content 在需要深度翻译时可委派 tri-translate 作为方法论支撑（详见 tri-translate/SKILL.md）。两者非竞争关系。
> 横向 skill 不参与本表路由：tri-cache（缓存）、tri-evolve（自进化）、tri-translate（翻译方法论）、
> tri-true（消除幻觉）、tri-cost（token 成本审计）、tri-guard（技能安全审计）、tri-humanize（去 AI 化改写）
> 为横向基础设施/方法论型 skill，由 hook、下游 skill 委派或用户显式调用激活，
> 不由 tri-intent 依 L2 意图直接路由，故不在本表内。
> 其余不参与本表路由的 skill 及理由（全量枚举，保证顶层 skill 路由状态逐一可查）：
> tri-forge——内部专用工具（skill 生成/合规自检/蒸馏门⑤），由用户直接调用，不承载用户任务语义，非下游；
> tri-learn——学习教练，独立标准模式（用户直接发起学习请求时独立推进全流程），tri-intent 仅作可选登记（其 §上游依赖检测 B 态），不依赖快照路由；
> tri-jobhunt——求职单入口，设计为用户显式 /tri-jobhunt 调用后向 6 个 children 分发，不经 L2 意图路由（其 §上游依赖检测针对 children 就位态，非快照）。
> tri-geo——GEO 单领域入口（国内生成式引擎优化），设计为用户显式调用激活，不经 L2 意图路由（豁免理由：GEO 是跨内容/技术/渠道的独立领域闭环，现行 27 个 L2 落点无对应项；其 §上游依赖检测为直用/引导补参/讲解降级三态，不依赖快照）。登记于 2026-09-16（tri-geo v1.0.1 家族合规审计 P-1 项，报告 docs/audit-tri-geo-20260916.md）。
二、检测步骤（脚本驱动 · 确定性）
- 读取路由建议：从快照 §三
下游路由建议字段获取目标下游 skill - 映射 skill slug：按路由映射表将 L2 意图映射到具体 slug。I15 音乐子类为二跳，MUST 同时传入
tri-mm与tri-music - 执行检测脚本：MUST 调用检测脚本取得确定性结论，NEVER 凭记忆或单一路径臆断：
bash
python tri-intent/scripts/check_downstream.py --slug <slug> [--slug <slug2>] --json
脚本覆盖四处安装位置 + 一处注册表：家族源码树、.tribro/skills/（tri-forge 落盘位）、平台用户级 ~/.workbuddy|.trae|.cursor|.qcoder/skills/、平台项目级 <project>/.workbuddy/skills/，并读 .skills_store_lock.json 判定能否斜杠激活。任一位置存在 SKILL.md 即 installed=true。退出码：0 全部已安装 / 1 存在缺失。
- 据
installed分流：
- 已安装 → 直接交接执行（§三 A 路径），不额外打扰用户
- 未安装 → 进入 §三 B 路径的两道确认门
> activatable=false 但 installed=true 属正常态——家族多数下游仅存在于源码树、由 tri-intent 内部委派，本就不需要斜杠激活。此情形 NEVER 提示安装。
三、分发处置（A 已安装直发 / B 未安装两道门）
A · 已安装 → 直接交接
快照已落盘，下游 skill 读取快照 §三 自主执行，tri-intent 职责到此终止。
B · 未安装 → 门① 安装确认 → 门② 执行确认
> 设计意图：让「意图识别 → 自动安装 → 自动执行」成为一条不断链的流水线，同时给两个不可逆动作（装东西、跑东西）各留一个用户出口。
门① 安装确认——MUST 先征询，NEVER 未经同意直接安装：
> 意图识别已完成，快照已产出（<快照路径>）。
> 路由建议指向 <slug>，但四处安装位置均未检测到该下游 skill，工作流无法自动推进。
> 是否现在安装 <slug>？（是 / 否）
- 用户同意 → MUST 原样发送以下安装 prompt，交由 Agent 依 skillhub 官方文档完成安装：
请根据 https://skillhub.cn/install/skillhub.md，安装<slug>
多个缺失 slug（如 I15 二跳）MUST 逐个发送，按依赖顺序先装被委派方。
- 用户拒绝 → 停在快照态。MUST 告知「快照已保留在 <快照路径>，后续安装 <slug> 后可直接接手」，NEVER 由 tri-intent 越界代替下游执行。
安装后复检——MUST 重跑 §二 检测脚本自证安装成功：
- 复检
installed=true→ 进入门② - 复检仍为
false→ NEVER 进入门②。输出安装失败结论 + 脚本原始输出，请用户核查 skillhub 登录态与网络
门② 执行确认——安装成功后 MUST 再征询一次：
> <slug> 已安装完成（v<version>）。
> 是否立即执行该 skill 处理本次请求？（是 / 否）
- 用户同意 → 交接下游，下游读取快照 §三 自主执行
- 用户拒绝 → 停在已安装态，告知快照路径，后续可随时唤起下游
分发状态机
graph LR
S[快照已落盘] --> D{check_downstream.py}
D -- installed --> Exec[交接下游执行]
D -- missing --> G1{门① 是否安装?}
G1 -- 否 --> Hold[停在快照态 告知路径]
G1 -- 是 --> P[发送安装 prompt] --> R{复检 installed?}
R -- 否 --> Fail[报安装失败 输出脚本原文]
R -- 是 --> G2{门② 是否立即执行?}
G2 -- 否 --> Hold2[停在已安装态]
G2 -- 是 --> Exec
四、与下游 skill 上游检测的对称关系
> tri-intent 的「下游依赖检测」与下游 skill 的「上游依赖检测」构成对称的双向检测机制：
>
> - 下游 skill → 上游（35 个 tri- skill 已实现，含 28 个路由型 + 7 个横向型）：激活时检测 tri-intent 是否可用 → 不可用提示安装 → 高频 skill 支持降级模式
> - 上游 → 下游 skill*（tri-intent 本节）：产出快照后检测下游 skill 是否可用 → 不可用提示安装
>
> 双向检测确保：无论用户先安装哪一端，缺失的另一端都会被检测到并给出安装引导。
>
> 计数口径（MUST 随 §一 枚举联动更新，NEVER 沿用历史值）：路由型 26 = §一路由映射表全部下游 slug 去重（27 个）扣除「不落盘」类
> tri-express（I17–I20，无快照交接，见映射表末行）；横向型 7 = 下方「横向 skill 不参与本表路由」全量枚举。任一枚举变更 MUST 同步本节。
