规划拆解（下游路由 · I13）

> 本 skill 是 tri-intent 的下游执行 skill，依据快照 snapshot.md §三 结构化结论直接执行，不再重新识别意图。
> 用户心智：把 AI 当参谋，期望拿到可执行的计划/方案/任务清单。

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

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

1. 强制前置：收到 tri-intent 快照且 下游路由建议 指向本 skill，MUST 先读取快照 §三，再按规划工作流串行推进，NEVER 跳过直接给计划。核心铁律：没有明确的目标与验收标准，就没有任务拆解——目标含糊时拆得越细越偏离。 独立使用时（未经 tri-intent 路由）MUST 先走 §上游依赖检测 判定模式。

2. 规划确认门 + 任务清单硬性规则：I13 属规划类，MUST 严格串行经过规划方向确认门 + 规划审计门 + 交付前确认，禁止直接给最终计划：
   - 门①（规划方向确认）：先产出 plan-brief.md（规划纲要），向用户结构化复述供确认；通过后方可进入深度拆解。目标或范围含糊时 MUST 在此门澄清，不得带着含糊目标进入拆解。
   - 门②（规划审计）：据已确认的 plan-brief.md 产出 plan.md（完整规划文档），再交用户审计；通过后方可产出 task-checklist.md。
   - 门③（交付前确认）：门②通过后产出 task-checklist.md（可执行任务清单+验收标准+依赖标注），交付前 MUST 主动询问用户两件事：① 是否需要调用其它 skill 协同（如 tri-coding 编码实现、tri-action 操作执行、tri-content 文档产出等）；② 是否有需要补充的约束/素材。用户确认无补充 → 交付；用户提出补充 → 据反馈更新 task-checklist.md（涉及规划缺陷则回退门②更新 plan.md）后再次确认，通过后方可交付，禁止跳门抢跑。
   - 任务清单复选框规则：task-checklist.md 中每个任务条目均含「完成状态」复选框字段，形如 `- [ ] **完成状态**：未确认`（- [ ] 必须位于行首，否则 GFM 渲染成纯文本而非可勾选控件）。此处的「完成」指规划交付确认，非任务本身执行完成（执行由下游 skill 负责）。
   - 完整链路：plan-brief.md → ①→ plan.md → ②→ task-checklist.md → ③→ 交付。任一门未通过则携反馈回炉，不得跳门或抢跑。阶段—产物—门—关键动作的完整对应见 §阶段速查表（唯一事实源），本条不再复述。
3. 职责边界：本 skill 负责「读取快照 → 明确目标 → 结构化拆解 → 产出规划文档 → 交付任务清单」全链路。意图识别（由 tri-intent）、编码实现（由 tri-coding）、真实操作执行（由 tri-action）、内容文本产出（由 tri-content）不属于本 skill。本 skill 只出方案不写代码不执行操作。
4. 自检：作答前用一句话声明「本次意图=I13，已读取快照，当前阶段=<阶段>」，若与上述规则冲突则停止并纠正。

> 若快照 澄清门状态 = 待澄清，本 skill 不应激活。

触发时机

• tri-intent 产出的快照中 下游路由建议 指向本 skill
• 意图编码范围：I13 规划拆解（默认规划拆解子类）
• L3 让渡：I13 存在 L3 子类，命中以下语义时 MUST 让渡对应 skill，本 skill 不接管——
• 工作流设计（流水线/审批流/自动化流程/编排）→ tri-workflow
• sdlc 全生命周期（L3_子意图 = sdlc，端到端项目交付）→ tri-sdlc

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

> 本 skill 可独立安装。激活时 MUST 检测上游 tri-intent skill 是否可用，据检测结果选择执行模式（A / A0 / B 三态；A0 是「有 tri-intent 但无可用快照」的中间态）：

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

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

输入契约

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

职责边界

• 本 skill 负责：依据快照结论，对 I13 意图产出规划类成果物（计划/方案/任务清单/排期/里程碑）
• 不负责：意图识别（由 tri-intent）、编码实现（由 tri-coding）、真实操作执行（由 tri-action）、内容文本产出（由 tri-content）
• 关键边界：本 skill 只出「方案/计划」，不「动手做」——动手执行归 tri-action 或 tri-coding
• 与 tri-coding 的协作：tri-plan 产出的 task-checklist.md 可作为 tri-coding 的执行输入；tri-plan 只拆解任务不规定代码实现细节，技术实现方案归 tri-coding 的 design.md
• 与 tri-action 的协作：tri-plan 产出的任务清单中标注「建议执行 skill=tri-action」的任务，由 tri-action 读取并执行
• L3 让渡边界：I13 有 L3 子类分流，本 skill 只处理默认的 I13 规划拆解（产出计划/方案/任务清单/排期等规划文档本身）：

> 命中 L3 子类却路由到本 skill 时，MUST 停止并回退 tri-intent 重新路由，NEVER 越界接管。

• 不触发场景（Not-Trigger）：本 skill 不接手「编码实现 / 动手执行」（转 tri-coding / tri-action）；不接手「工作流设计、全生命周期编排」（属 tri-workflow / tri-sdlc，I13 L3 分流）；不接手「内容文本产出」（属 tri-content）；不接手「识别用户意图」（由 tri-intent / 自身快照驱动）。

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

> 家族级强制技术约束，优先级与「强制执行契约」同级。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-plan --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 进入以下任一执行步骤。

> 基于 WBS（Work Breakdown Structure）方法论，形成「目标 → 阶段 → 任务 → 验收标准 → 风险」的结构化拆解链路。
> 链路一览：快照 §三 → plan-brief.md → 门① → plan.md → 门② → task-checklist.md → 门③ → 交付（可视化流程图见 README.md §使用）。

阶段速查表（阶段 ↔ 产物 ↔ 门 ↔ 关键动作 · 唯一事实源）

> 本表是「阶段—产物—审批门—关键动作」对应关系的唯一事实源，§强制执行契约 与 §交付产物 均引用本表，不再另立映射。

目标拆解方法论（核心能力 · 可扩展）

> 不要含糊，要可度量。不要堆砌，要可独立。不要遗漏，要有兜底。

第一步：目标定义（plan-brief.md 阶段）

从快照 §三 提取规划目标，按 SMART 原则校准：

> 目标含糊时 MUST 在门①澄清，不得带着含糊目标进入拆解。

第二步：WBS 任务分解（plan.md 阶段）

按「目标 → 阶段 → 任务 → 子任务」逐层分解：

目标（Goal）
├── 阶段 1（Phase）
│   ├── 任务 1.1（Task）
│   │   ├── 子任务 1.1.1
│   │   └── 子任务 1.1.2
│   └── 任务 1.2
├── 阶段 2
│   └── ...
└── 阶段 N

分解原则：
- 可独立执行：每个叶子任务可被独立分配和执行，不依赖同层其它任务的中间产物
- 粒度适中：单个任务的工作量可预估，过大则继续拆分，过小则合并；定界判据——一个任务是能独立承载自己那轮验证循环、且值得一次独立审查把关的最小单元，每个任务以一个可独立验证的交付物结束
- 100% 覆盖：同层任务之和 = 父项全部范围，无遗漏无重叠（MECE）
- 验收可判：每个叶子任务有明确的完成判定标准

计划缺陷禁令（占位符零容忍）——以下均属计划缺陷，plan.md 与 task-checklist.md 中 MUST 绝不出现：
- 「待定」「TODO」「后续实现」「补充细节」「类似任务 N」
- 「添加适当的错误处理」「处理边界情况」类空泛要求（必须写明具体是什么）
- 只描述做什么而不给出怎么做要素的步骤
- 引用了未在任何任务中定义的类型、接口或文件路径

计划自检三查（门②审计前的自检清单，发现问题直接内联修复）：
1. 覆盖度：逐条核对快照 任务要点 与 plan.md，每条都能指出承接它的任务；列出遗漏并补任务
2. 占位符扫描：按上方缺陷禁令逐类扫描 plan.md 与 task-checklist.md，命中即修复
3. 一致性：跨任务引用的类型/接口/文件名前后一致（任务 2 叫 clearLayers() 任务 7 不能变成 clearFullLayers()）；依赖标注与任务顺序不矛盾

第三步：依赖关系标注

为每个任务标注依赖：

依赖图无环校验：MUST 验证依赖关系无循环，若检测到环则重构拆解以消除环。判定与环定位由脚本完成（确定性算法下沉，见 family-spec 约束 18），NEVER 凭印象填「通过」：

python scripts/dep_lint.py .tribro/plans/<命名>/plan.md        # 人类可读报告
python scripts/dep_lint.py .tribro/plans/<命名>/plan.md --json # 供编排读取

脚本读 plan.md §6.1 依赖关系列表，输出「可排出序列 + SELF_LOOP（自环）+ CYCLE（含环路径）+ DANGLING（引用了不存在的任务编号）」四类结果：无缺陷退出码 0，任一缺陷退出码 1。门②审计前 MUST 实跑一次，把脚本输出抄进 plan.md §6.2「无环校验」行；FAIL 时按环路径重构拆解后重跑，NEVER 带着环进 task-checklist.md。

第四步：里程碑设定

按阶段交付物设定里程碑：

• 里程碑 = 阶段交付物 + 验收节点 + 预估时间
• 里程碑应可验收（有明确的完成判定）
• 关键路径上的里程碑标记为「关键里程碑」

第五步：风险登记

风险质量标准：每个风险 MUST 有缓解措施；高可能性+高影响的风险 MUST 有应对策略（规避/转移/减轻/接受）。

可扩展性

> 新增拆解维度或校准规则无需修改核心工作流：

1. 新增拆解步骤：在第一~五步中插入新步骤（如「资源分配」「质量门设定」），plan-brief.md / plan.md / task-checklist.md 模板自动对齐
2. 新增依赖类型：在依赖关系标注表中追加行（依赖类型 / 标记 / 含义），依赖图无环校验自动覆盖
3. 新增风险维度：在风险登记表中追加列或行（如「合规风险」「技术债风险」），风险质量标准自动适用

交付产物

一、文件命名规范

沿用 tri-intent 快照命名：<问题类型>_<日期>_<时间>_<会话ID>

• 示例：I13_20250211_143022_6a5c037d

二、存放目录

.tribro/                    # 若不存在则先创建
├── snapshots/              tri-intent 产出（已存在）
│   └── <命名>.md
└── plans/                  tri-plan 链路文档
    └── <命名>/
        ├── plan-brief.md     # 规划纲要（门①载体）
        ├── plan.md           # 完整规划文档（门②载体）
        └── task-checklist.md # 可执行任务清单（门③载体+最终交付物）

三、产物清单

四、产物结构规格

plan.md（完整规划文档）结构：
1. 规划目标（SMART 校准）
2. 范围边界（包含/排除）
3. 约束条件（技术/资源/时间/外部）
4. 阶段拆解（WBS 树状图）
5. 任务清单（含编号/描述/预估/负责域）
6. 依赖关系图（标注依赖类型，无环）
7. 里程碑（含关键路径标记）
8. 风险登记（含缓解措施与应对策略）
9. 验收标准（逐任务可判定）

task-checklist.md（可执行任务清单）结构：
- 文件头部含「全局约束」节：来自 plan.md §3 约束条件的项目级硬要求（版本下限/依赖限制/命名规则/平台要求），数值逐字照抄、每条一行——每个任务的验收都隐含包含本节，执行 skill 无需回读 plan.md 即可对照
- 每个任务条目含：编号 / 描述 / 验收标准 / 依赖标注 / 建议执行 skill / 完成状态复选框
- 按阶段分组，标注阶段间依赖

五、质量标准

落盘规则

• 快照由 tri-intent 已落盘于 .tribro/snapshots/
• 本 skill 链路文档落盘于 .tribro/plans/<命名>/
• 链路文档可覆盖更新（以最新一轮为准），确认/审计记录留痕于各文档对应章节
• 最终规划成果物（plan.md + task-checklist.md）落盘至 .tribro/plans/<命名>/，供下游 skill（tri-coding/tri-action 等）读取作为执行输入

目录结构

tri-plan/
├── SKILL.md              # 主入口：规划工作流定义 + 规划确认门 + 目标拆解方法论
├── README.md             # 使用说明 + 可视化流程图（§使用）
├── CHANGELOG.md          # 版本变更记录
├── scripts/
│   ├── check_update.py   # 版本检查门可执行实现（第零步，家族同源）
│   └── dep_lint.py       # 依赖图无环校验（拓扑排序/环路径/自环/悬引用）
├── templates/
│   ├── plan-brief.md     # 规划纲要模板（门①载体）
│   ├── plan.md           # 完整规划文档模板（门②载体）
│   └── task-checklist.md # 可执行任务清单模板（门③载体+最终交付物）
└── tests/
    └── tri-plan-full-testcases.md  # 全量测试用例