Skill 分层调用规则

定义

Skill 分层调用规则 是一种面向 Agent Skill 系统的分工与调度约束：

• 一类是用户唤起型，也可视为统筹型 Skill，由用户显式输入命令后启动，负责组织一段较完整的高层工作流。
• 另一类是模型唤起型，也可视为纪律型 Skill，由 Agent 在判断当前情境合适时自行调用，负责执行具体、可复用、带有工程纪律的动作。

这套规则的核心不是“Skill 越多越好”，而是把“谁负责总控、谁负责落地动作”分层。文章给出的明确约束是：统筹型可以调用纪律型，但两个统筹型之间不能互相调用。

在本文语境中的含义

这个概念来自 Matt Pocock 开源的 mattpocock skills 体系。该体系不是把 21 个 Skill 当成 21 条彼此平铺的命令，而是把它们组织成一套从想法澄清、规格整理、工单拆分、实现、测试到审查的工程方法。

在这套语境里，Skill 不只是“提示词模板”，而是工程流程中的可执行节点。于是，一个关键问题变成：当 Skill 数量增长到 21 个时，Agent 应该如何调用它们，才不会让系统编排迅速失控。

Skill 分层调用规则 正是对这个问题的回答。它试图避免多个高层工作流彼此嵌套、互相跳转，让整个系统像一堆会相互递归的“总控指令”一样失去边界。

两类 Skill 的区分

用户唤起型：统筹全局流程

用户唤起型 Skill 必须由人手动触发。文章举的例子是像 /grill-me 这一类入口；在同一套工作流里，/grill-with-docs、/prototype、/to-spec、/to-tickets、/implement、/triage、/diagnosing-bugs、/wayfinder 也都属于这种“从外部进入一段工作流”的入口型角色。

这类 Skill 的共同点是：

• 它们承担的是流程统筹，而不是单一动作执行。
• 它们往往对应一个完整阶段，比如澄清需求、做一次原型验证、把对话整理为规格、把规格拆成工单、处理外部 bug 反馈、规划雾很大的大工程等。
• 它们通常需要用户提供目标、背景或授权，因此适合由用户显式发起，而不是由 Agent 任意决定切换。

模型唤起型：执行纪律动作

模型唤起型 Skill 由 Agent 根据上下文自主拿取，用来执行更具体、更局部、可嵌入其他流程的动作。文章明确给出的例子包括 tdd、code-review。

这类 Skill 的共同点是：

• 它们不是新的总入口，而是某个高层流程中的执行动作。
• 它们承载的是工程纪律，例如测试驱动、代码审查、风格约束、检查是否偏题等。
• 它们适合在特定时机被自动调用，而不是要求用户每走一步都手动记忆并触发。

例如文中提到，/implement 在实现一张工单时，会内部驱动 /tdd，并在结束前自动跑一次 /code-review。这里 implement 是统筹型入口，而 tdd 与 code-review 是被纳入其内部的纪律型动作。

核心规则

规则内容

Skill 分层调用规则 的核心只有一条：

• 统筹型可以调用纪律型。
• 统筹型之间不能互相调用。

换句话说，高层入口可以在自己的工作流内部拿取底层纪律动作，但不能再去跳转、嵌套、拼接另一个高层入口。

为什么要禁止统筹型互调

如果允许两个统筹型 Skill 互相调用，系统很容易出现以下问题：

• 高层工作流彼此套娃，用户难以理解当前到底处于哪个阶段。
• Agent 在多个“总控器”之间跳转，责任边界变得模糊。
• 同一个任务可能被不同入口重复拆解、重复提问、重复产出文档。
• 一旦出现偏航，很难判断是哪个入口的决策导致了混乱。

因此，这条规则本质上是一种控制编排复杂度的机制。它通过限制高层流程之间的互相嵌套，把复杂系统压回到“少数入口 + 若干可复用纪律动作”的结构。

使用体验上的直接效果

这条分层规则带来的一个非常具体的结果是：用户不必记住全部 21 条命令，只需要掌握少数几个入口。

文章明确指出，这也是为什么这套系统“用起来不像要背下 21 条命令”。因为大部分时候，用户只需要知道自己现在要从哪个入口进入：

• 需求不清楚时，从澄清类入口进入；
• 要把想法沉淀成规格时，从规格类入口进入；
• 要拆工单时，从拆解类入口进入；
• 要实现时，从实现类入口进入；
• 碰到外来 bug、模糊需求或疑难问题时，再走对应入口。

一旦进入入口，Agent 会在合适时机自行调用像 tdd、code-review 这样的纪律型 Skill。用户记住的是“去哪里进门”，而不是“每一步该手敲哪条内部纪律命令”。

这使 Skill 体系更接近一个分层工具箱，而不是一张必须死记硬背的命令清单。

在工作流中的具体体现

文章用 idea → ship 主线展示了这种分层的实际运作方式：

• 先通过 /grill-with-docs 把模糊想法问清楚；能从代码库查到的事实先自己查，查不到的才问用户，直到双方对齐。
• 某些问题如果靠对话无法确认，例如交互是否顺手，则临时分岔到 /prototype，写一次性代码验证，验证后丢弃。
• 想清楚后，用 /to-spec 把对话整理为规格文档，再用 /to-tickets 切分成带有依赖或卡点关系的工单。
• 每张工单交给 /implement 处理；而 /implement 内部再驱动 /tdd 进入红绿重构循环，并在结束前自动执行 /code-review。

这里可以清楚看到分层：

• /grill-with-docs、/prototype、/to-spec、/to-tickets、/implement 是统筹型入口；
• tdd、code-review 是纪律型动作；
• 高层入口负责定义阶段目标与产物，底层动作负责保证执行质量。

特别是 /code-review，文中还补充了它并不是泛泛地“看一眼代码”，而是并行走两条线：一条检查代码坏味道，内置了命名混乱、重复代码等 12 条经典问题；另一条检查实现有没有偏离原目标。这个例子说明纪律型 Skill 不是抽象口号，而是可插入、可复用、带检查标准的具体动作。

这条规则解决的是什么问题

解决的是调度与职责分工

Skill 分层调用规则 主要解决的是：

• 谁来负责一段流程的总控；
• 谁来负责流程中的纪律性动作；
• 这些角色之间允许怎样的调用方向；
• 如何避免多层工作流相互嵌套造成混乱。