User-invoked skills
定义
User-invoked skills 是一类只能在用户显式输入时才能触达的技能。
它们不是代理在后台根据任务自行挑选的默认能力，而是需要用户用明确指令启动，例如文中给出的 /grill-me 这类命令形式。
这类技能的核心职责是 orchestrate，即“编排”整个流程：决定当前应走哪条工作流、按什么阶段推进、何时拉起其他更专门的技能完成某个子任务。
与之相对，model-invoked skills 更偏向“可复用的纪律”或“标准化能力单元”；而 user-invoked skills 负责把这些能力单元组织成一条可执行路径。
在本文档中的语境
在该技能体系里，技能被明确分成两类：User-invoked skills 与 model-invoked skills。
- User-invoked：只有当用户亲自输入时才会触发。
- Model-invoked：既可以由用户主动调用，也可以在任务匹配时被代理自动选用。
这种划分不是按主题区分，而是按触发方式与职责层级区分。
在 Engineering 语境下，user-invoked skills 承担的是较高层的工作流入口，例如：
- 选择当前问题最适合走哪条流程；
- 把一次对话整理成 spec 或 tickets；
- 组织实施、分阶段推进，并在约定的节点调用更细的能力；
- 为大块工作建立路线图、调查项或状态流转机制。
也就是说，user-invoked skills 更像“用户点名启动的流程控制器”，而不是单个具体技术动作本身。
关键机制
1. 只能由用户显式触发
User-invoked skills 的第一条规则是：只有在用户输入时才能触达。
文中直接给出的例子是 /grill-me。这说明它们通常作为明确命令、入口技能或工作流开关存在，而不是代理自行默默选用的内部工具。
这条规则带来的含义是：
- 代理不会仅因为“看起来合适”就自动进入某个 user-invoked flow；
- 是否启动这类流程，控制权在用户手里；
- 这类技能往往对应一次更重、更长、更有结构的协作过程，因此需要用户明确授权进入。
2. 职责是编排，而不是沉淀底层纪律
文中对 user-invoked skills 的职责描述非常直接：their job is to orchestrate。
这里的 orchestrate 不是泛泛地“帮忙做事”，而是强调它们负责：
- 组织阶段顺序；
- 决定下一步该调用什么能力；
- 连接多个子流程；
- 把一次复杂任务收束成可执行的路径。
因此，user-invoked skills 通常位于更上层；它们本身不一定承载最细颗粒度的方法论，而是调度那些已经标准化的能力模块。
3. 可以调用 model-invoked skills
User-invoked skills 可以调用 model-invoked skills。
这是它们能完成“编排”职责的关键前提：高层流程必须能够在需要时下沉到低层能力。例如，一个实现型流程可以在某个预先约定的接缝调用 tdd，并在收尾阶段调用 code-review。
这类调用关系体现出一个清晰结构：
- 上层：user-invoked skill 负责整体工作流；
- 下层：model-invoked skill 提供可复用的具体纪律。
因此，user-invoked skill 并不是孤立执行，而是通过组合下层技能来完成复杂目标。
4. 不能调用另一个 user-invoked skill
边界同样被写得很清楚：user-invoked skill 不能再调用另一个 user-invoked skill。
原文表述是：A user-invoked skill may invoke model-invoked skills, but never another user-invoked one.
这条限制的作用是防止高层入口之间互相嵌套，避免出现：
- 一个入口流程偷偷跳到另一个入口流程；
- 多个顶层工作流互相转发，造成控制权混乱；
- 用户以为自己只启动了一个大流程，实际上系统在内部层层切换其他顶层流程。
换句话说，user-invoked skills 是“顶层入口”，顶层入口之间不能彼此套娃。
结构理解：顶层入口与底层能力
从这套规则可以把技能体系理解为两层：
- 顶层入口层：User-invoked skills
- 能力纪律层：model-invoked skills
前者回答“这次协作整体要怎么走”；后者回答“其中某一步应该按什么纪律执行”。
例如：
- 一个 user-invoked skill 可以负责把需求推进成实现流程；
- 在实现过程中，再调用 tdd 完成测试驱动的垂直切片开发；
- 在提交前，再调用 code-review 进行标准与 spec 两个维度的审查。
这种分层让复用发生在下层，而把用户入口保持在上层，既减少重复，又保留清晰的人机控制边界。
文中出现的 user-invoked 技能实例
在 Engineering 列表中，被归为 User-invoked 的技能包括：
ask-matt：用于询问当前情境适合哪种 skill 或 flow，本质上是 user-invoked skills 之间的路由入口；grill-with-docs：进行 grilling，同时建立项目领域模型，并内联更新CONTEXT.md与 ADR；triage：按一套 triage 角色状态机推进 issue；improve-codebase-architecture：扫描代码库中的深层改进机会，产出可视化 HTML 报告，再围绕选中的项继续 grill；setup-matt-pocock-skills：为仓库配置工程技能所需环境，例如 issue tracker、triage labels、领域文档布局；to-spec：把当前对话整理成 spec 并发布到 issue tracker，不做额外访谈；to-tickets：把计划、spec 或对话拆成 tracer-bullet tickets，并声明阻塞边；implement：根据 spec 或 tickets 落地实现，在约定接缝驱动 tdd，并在提交前走 code-review；wayfinder：为超出单次 agent session 承载范围的大块工作建立共享调查地图，并逐个解决调查 ticket。
这些例子共同说明：user-invoked skills 面向的不是单一步骤，而是一个相对完整的入口工作流。
细节与边界
用户控制是硬边界
只要某个技能属于 user-invoked，它就不能被代理因为“任务合适”而自动触发。是否进入该流程，必须由用户明确输入决定。
编排不等于包办所有执行
user-invoked skill 的职责是组织流程，不代表它必须亲自承载所有执行细节。相反，它通常需要把某些步骤下放给 model-invoked skills。
调用方向是单向的
允许的典型调用方向是：
- 用户 → user-invoked skill
- user-invoked skill → model-invoked skill
不允许的方向是：
- user-invoked skill → 另一个 user-invoked skill
这种单向性确保体系中始终只有一个显式的顶层入口。