先把话撂这儿：多 skill 协作的体系里，最难查的 bug 从来不在某个 skill 内部，而在那张没人正眼瞧过的路由表。skill 自己跑得好好的，能力齐、模板全、测试用例一条不落，结果它一辈子收不到活儿——这种「死技能」比崩溃的技能难受多了，因为它连报错都不给你。
我做的雷达鸭 App 里就有一条定时同步 loop，每天固定点抓一轮案例源、比对、落库，靠的就是这套 loop 编排思路。所以 tri-loop 坏没坏，我是有体感的。
现象：我明明说了「loop」，活儿却被别人接走了
那天我随口丢了一句「帮我在知识库起一个 monitoring loop」。tri-intent 照常出快照，L2 判成 I14 操作执行，没毛病。然后我盯着快照最下面那行：
下游路由建议: tri–action
tri-action 是通用操作执行 skill，它当然也「能做」——建个文件夹，写点东西，回报一句完成了。但它建出来的东西，没有 charter，没有 ## Timeline，没有往 LOG.md 追加任何一条记录，更没有那次真实测试运行。说白了就是一具空壳，看着像 loop，实际上是个空文件夹加一段自然语言。
tri-loop 就装在隔壁目录里，安安静静，一次都没被叫醒过。
tri-loop 到底管什么，值不值得单独一条路由
我先说清楚它不是「tri-action 的马甲」，不然这个 bug 根本没有修的必要。
tri-loop 处理的是知识库里的 loop / domain 创建，走的是一条固定闭环：检测 substrate → 收集 charter → scaffold README → 真实测试运行 → Timeline + LOG.md 记录 → 回报。这里头有两块是通用执行怎么也长不出来的。
一块是 substrate bootstrap。它会去知识库仓库根目录查 ARCHITECTURE.md、LOG.md，还有那个得包含 “Knowledge base” 章节的 CLAUDE.md；缺哪个补哪个，idempotent，绝不覆盖已有文件。连 signals/、docs/、domains/ 三个目录和它们各自的 README 都一并铺好——那些 README 本身就是 schema。
另一块是它的铁律：没有 charter 的 loop 不启动。charter 是五项输入，name、goal、cadence、做什么、工具/数据，缺一项都不给 scaffold。这条规矩我一开始觉得有点轴，后来真香。我见过太多所谓的「自动化流程」，建的时候豪情万丈，三周后没人记得它每天几点跑、跑出来的东西该往哪放。cadence 和 goal 写死在 frontmatter 里，起码半年后你还知道这玩意儿是干嘛的。
还有一条我个人最偏爱的设计：真实测试运行。scaffold 完不算完，得真跑一次小规模的——分诊几张真工单、拉一条真 SERP、抓一次收件箱都行；凭证不齐就做到能做的最远那步，然后把差距写下来。产出 artifact 是可选的，但 Timeline 一行 + LOG.md 一条必须有。这一步把「文件夹存在」和「loop 能跑」彻底分开了，我觉得这才是整个 skill 最值钱的地方。
产物落在哪也是分得清清楚楚的。知识库的实际内容（substrate 文件、domains/<name>/README.md、LOG.md 里那条追加记录）躺在知识库仓库根目录，因为它们本来就是知识库的一部分；而 tri-loop 这次执行的链路文档，落到 .tribro/loops/<命名>/result.md，跟 tri-intent 的 .tribro/snapshots/、tri-action 的 .tribro/actions/ 平级。命名沿用快照那套 <问题类型>_<日期>_<时间>_<会话ID>，比如 I14_20250211_143022_6a5c037d。内容文件可以随时覆盖更新——README 是实时状态，LOG 是追加日志；链路文档写完就不再改，留着审计。这套「内容归内容、审计归审计」的分家我挺认可的，翻旧账的时候不用在一堆临时产物里刨。
安全约束也按可逆性分了级：新建 domain、追加 Timeline、bootstrap 缺失文件都算 L1，直接干，不问；覆盖已存在的 domain、动已有的 CLAUDE.md 算 L2，必须先问一句，而且改 CLAUDE.md 只允许追加 Knowledge base 章节，其余部分一根手指都不许碰。
这么一套东西，硬塞进通用执行里就是灾难。它该有自己的入口。
漏在哪：默认路由 + 子类覆写的老毛病
tri-intent 的 I14 是有默认下游的，就是 tri-action。想拐到别的地方去，得靠「子类覆写」机制——L2 编码不动，只把 下游路由建议 这个字段改掉。
工作流那条子类早就配好了：任务要点里出现「工作流 / 流水线 / 审批流 / CI-CD / 编排 / pipeline」，覆写成 tri-workflow，配套还有一份 doing/workflow-design.md 讲清楚判定边界。
loop 这条呢？tri-loop 的 SKILL.md 里写得明明白白，触发时机是「tri-intent 快照中下游路由建议指向本 skill」。它在门口等着，等一个永远不会来的字段值。上游压根没有任何一处把 loop / domain / 循环 / 知识库 / charter / cadence 这些词跟 tri-loop 关联起来。
这就是典型的单向契约：下游写了自己怎么被激活，上游不知道有这么个下游。我个人特别讨厌这种设计，两边各自看都毫无破绽，合起来就是断的。
修法：一个新文件 + 三处映射
改动不大，但得改齐。
新建 tri-intent/doing/loop-design.md，跟 workflow-design.md 平起平坐，把识别特征、邻近边界、路由规则、判定流程全写死：
## 路由规则
| 字段 | 取值 |
|—|—|
| L1_交互类型 | B.Doing |
| L2_核心意图 | I14 操作执行（loop/domain 创建子类） |
| 下游路由建议 | tri-loop（覆写默认的 tri-action） |
| 落盘 | 快照（snapshot.md） |
## 路由判定流程
1. **L2 判定**：按常规流程判定 L2 = I14
2. **子类检测**：扫描 `任务要点` 是否含 loop/domain 创建语义关键词
3. **路由覆写**：
– 命中关键词 → `下游路由建议` = tri-loop，L2 保持不变
– 未命中关键词 → `下游路由建议` = tri-action，保持默认
4. **快照标注**：在快照 §三 `任务要点` 中保留 loop/domain 创建语义关键词，供 tri-loop 激活时校验
然后是 tri-intent/SKILL.md 里的判定规则和下游检测表，两处都得挂上：
6. **loop/domain 创建子类路由**：若 L2 判定为 I14，且任务要点含 loop/domain
创建语义（loop/domain/循环/知识库/beat/workstream/charter/cadence），
`下游路由建议` 覆写为 tri-loop，L2 保持 I14 不变，详见 `doing/loop-design.md`
| I14 | tri-action | `tri-action/`（默认）；工作流编排子类→`tri-workflow/`；loop/domain 创建子类→`tri-loop/` |
以及 I14-execute.md 末尾补一段子类路由说明，跟工作流那段并列。
改完再跑一遍同样的输入，快照那行终于变了：
intent:
L1_交互类型: B.Doing
L2_核心意图: I14 操作执行（loop/domain 创建子类）
任务要点:
– 在知识库中创建名为 monitoring 的 loop
– cadence 为 daily，消费监控告警，产出 signal
交付预期: 一个可验证运行的 monitoring loop（README + Timeline + LOG 记录）
下游路由建议: tri–loop
tri-loop 醒了，substrate 补齐，charter 五项收全，README 落盘，跑了一次 dry run，Timeline 和 LOG.md 各记一笔。生成的 loop README frontmatter 长这样：
—
kind: domain
domain: monitoring
status: active
goal: 每天分诊监控告警，把重复噪音沉淀成 signal
cadence: daily
—
从「说了没人听」到「说了有人接」，中间隔的就是这么几行映射。这坑我盯了小半个下午，最气人的是全程没有任何一条错误日志。
边界：别把什么都往 loop 里塞
修完路由我立刻担心另一件事——关键词命中太宽，会不会把不该走的活儿也拽过来。
「循环」「知识库」这类词日常出现频率不低。loop-design 里划的线是：跟 tri-workflow 比，工作流产出的是可执行的工作流定义（DAG、CI 配置），loop 产出的是知识库 domain 加一次真实运行记录；跟 tri-god 比，I21 蒸馏造物产出的是能独立调用的 skill，loop 产出的只是知识库里的一个 domain，不造 skill。语义不同，各走各的。
tri-loop 自己那边也留了后手：它激活时会校验 L2 是不是 I14、路由建议是不是指向自己、任务要点里有没有 loop 语义，三条同时满足才开工，L2 越界就停下来退回 tri-intent 重新路由。加上它自带的上游依赖检测三态（快照模式 / 引导安装 / 降级模式），单独装也能用，降级模式下内联问你五项 charter 就接着跑。双向都设了卡，比单靠一边的关键词匹配踏实。
补一句收尾。写这篇时 doing/SKILL.md 二级判定表 I14 那行还只列着 workflow-design、漏着 loop，当时是文档态残留；这茬后来已经补上（循环/Loop 子类→loop-design），如今主路由、检测表、I14-execute 三处对得齐。上次的教训没白挨——看着无所谓的地方，最容易埋雷。
如果让我重来，我会在建 skill 的第一天就写一张双向的路由对照表，两边都签字，而不是等到某个 skill 在门口站了两周才发现没人叫它。
关于我
老三，十来年软件开发经验，软件设计师、人工智能应用工程师，主攻鸿蒙 ArkTS 北向开发和 Web 前端，业余折腾 AI 自动化。技术文章不定期发在 CSDN，鸿蒙和 AI 两个方向为主。
本文遵循 MIT 协议，转载请注明出处。 项目仓库：TrisighT-Bingo/tri-skills
提示词：请根据 https://skillhub.cn/install/skillhub.md，安装 @user_989eb8f0/tri-loop。
