观点来源：Matt Pocock 于 2026 年 3 月 16 日发布的 5 Agent Skills I Use Every Day。
Coding Agent 可以快速读取仓库、修改代码和运行命令，却不会自然继承另一个会话里已经确认的全部背景。即使运行环境提供长期记忆，需求边界、领域术语、测试位置和架构决定仍需要稳定载体，否则同一任务换一个会话就可能得到另一套做法。
Agent Skills 的作用，是把反复使用的工程方法写成可调用的指令。这 5 个 Skill 分别处理需求澄清、规格整理、任务拆分、测试反馈和代码结构，让 Agent 每次都沿着同一组检查点工作，具体取舍仍由项目负责。
5 个 Skill 分别约束什么
| Skill | 处理的问题 | 主要产物 |
grill-me | 想法仍有分支，双方理解不一致 | 已确认的决定与待验证问题 |
to-spec | 长对话难以跨会话复用 | Spec、User Stories 与测试决定 |
to-tickets | Spec 太大，无法直接交给单个 Agent | 可独立验收的纵向 Tickets 与依赖关系 |
tdd | 实现过程缺少短反馈 | 通过公开接口验证行为的测试与最小实现 |
improve-codebase-architecture | 模块过浅、测试 seam 模糊、理解成本持续增加 | 架构候选报告与后续设计讨论 |
它们可以组成一条工作流，也可以按任务需要单独调用。
1. grill-me：沿设计树澄清问题
grill-me 最初只有三句话：持续访谈、逐个处理设计树的分支，并优先从代码库查找可以直接验证的答案。这个短 Prompt 通过持续提问，抑制 Agent 在达成共识前给出方案。
以搜索页面为例，「简单输入框还是高级搜索」只是第一层决定。选择高级搜索后，还要继续确认筛选条件、排序方式、空结果、权限、URL 状态和移动端布局。设计树没有走完就开始实现，后面的每个未决分支都会变成返工或隐含假设。
访谈也有明确边界。仓库里已经存在的路由、数据结构和组件行为应直接读取，不能反过来询问开发者；产品取舍、风险容忍度和范围优先级才需要由负责决定的人确认。这样可以把讨论集中在代码无法回答的问题上。
在 v1.2.3 中，grill-me 已经缩成调用通用 grilling Skill 的入口，具体规则位于可复用的底层 Skill。实际使用时应读取当前 SKILL.md，不直接套用早期的三句 Prompt。
2. to-spec：把共识压缩成终点定义
需求讨论完成后，长对话里通常混有尝试、否定、补充和重复解释。to-spec 会读取当前对话和代码库，直接把已经确认的内容整理成可以跨会话使用的 Spec，避免重复访谈。
当前版本会先确定测试 seam，也就是通过哪个公开接口观察功能行为。它优先复用已有 seam，并要求在写 Spec 前确认这些位置是否符合预期。随后才生成 Problem Statement、Solution、User Stories、Implementation Decisions、Testing Decisions、Out of Scope 和 Further Notes，并发布到项目配置的 Issue tracker。
Spec 删除过程噪声，同时保留关键决定。它应描述模块、接口、契约和测试策略，但通常不写容易失效的文件路径或实现代码。另一个会话接手时，需要知道终点和约束，不需要重放此前的整段聊天。
3. to-tickets：用纵向切片安排旅程
Spec 定义终点，单个 Agent 仍可能无法在一个上下文窗口内完成全部工作。to-tickets 会把目标拆成 tracer-bullet Tickets：每张 Ticket 都交付一条窄而完整的行为，必要时同时经过 Schema、API、UI 和测试，避免按数据库层、接口层和界面层进行水平拆分。
纵向切片有两个直接结果。第一，Ticket 完成后可以独立演示或验证；第二，后一个 Agent 可以从已经运行的真实路径继续工作，不必等所有层都分别完成。每张 Ticket 还会声明 blocking edges，没有前置依赖的任务可以进入执行队列，有依赖的任务则等待 blocker 完成。
当前 Skill 先列出每张 Ticket 的标题、依赖和交付行为，请开发者确认粒度与依赖关系，确认后再写入本地文件或真实 Issue tracker。并行只适用于依赖已经解除的 frontier，不能因为存在多个 Agent 就忽略共享文件、Schema 或接口契约之间的顺序。
大范围机械重构属于例外。共享字段改名或公共类型迁移很难保持每个纵向切片单独通过，此时应采用 expand-contract：先兼容新旧形式，再分批迁移调用方，最后删除旧形式。
4. tdd：让每一步都得到行为反馈
这套 TDD 方法从 red-green-refactor 起步：先写失败测试，再用最小实现让测试通过，随后整理结构。它强调测试公开行为、为可测试性设计接口，并按一个测试、一个实现的节奏推进。
v1.2.3 对流程做了更严格的拆分。当前 tdd Skill 只负责 red → green，refactor 被放到 review 阶段。每一轮先确认测试 seam，再写一个会失败的行为测试，只实现足以让它通过的代码，不提前实现后续测试可能需要的功能。
这种限制主要防止三类无效测试：绑定内部实现的测试会在正常重构时破裂；用相同算法重新计算 expected value 的测试无法独立发现错误；一次写完全部测试则容易验证想象中的接口，而不是实现过程中逐步确认的行为。
TDD 也不是提高覆盖率的机械动作。测试 seam 选错后，测试数量越多，重构阻力可能越大。公开接口、关键行为和独立预期值比私有方法、内部调用次数和大面积 snapshot 更值得验证。
5. improve-codebase-architecture：定期寻找模块深化机会
代码生成速度提高后，结构问题也会积累得更快。大量小模块、为测试而抽出的纯函数、跨文件跳转和泄漏的内部细节，会让开发者与 Agent 都难以判断一项行为真正属于哪里。
improve-codebase-architecture 使用 deep module 作为主要判断标准：模块应通过较小的 interface 提供较多能力，让实现复杂度留在内部。当前版本会先读取 Git 历史，把近期频繁变化的区域作为重点，再检查浅模块、缺少 locality 的调用方式、耦合关系和难以测试的 seam。
它会先生成一份临时 HTML 报告，不会自动重构。每个候选项包含涉及文件、问题、方案、收益、前后结构图和建议强度。开发者选中一个候选项后，Skill 才会进入访谈，继续确认约束、模块形状和测试方式。
这项检查适合在一轮密集开发后运行，也适合定期查看热点模块。它不应变成按日程强制改架构的任务。只有结构摩擦已经影响理解、测试或修改时，模块深化才有实际收益。
按任务规模组合 Skill
5 个 Skill 可以按任务规模组合，每次修改只调用解决当前问题所需的部分。
| 任务类型 | 建议组合 | 原因 |
| 边界清楚的小修复 | tdd → 验证与审查 | 已知问题不需要重新写 Spec |
| 存在产品分支的小功能 | grill-me → tdd → 验证与审查 | 先解决少量决策，再保持短反馈 |
| 跨多个会话的功能 | grill-me → to-spec → to-tickets → 分 Ticket 实现 | 用文档和依赖关系保存跨会话状态 |
| 一轮开发后的结构维护 | improve-codebase-architecture → 选择候选 → 单独规划重构 | 先取得证据，再决定是否投入 |
仓库初始化、安装范围和完整的 idea → ship 路由，可以继续阅读 Matt Pocock 的 AI Coding Skills 工作流。那篇文章覆盖 setup-matt-pocock-skills、grill-with-docs、implement 和双轴 code-review，与本文的日常使用视角互为补充。
Skill 需要像代码一样维护
从 2026 年 3 月到 v1.2.3，这 5 个 Skill 的名称和流程已经出现变化：to-prd 改为 to-spec，to-issues 改为 to-tickets，grill-me 变成通用访谈能力的入口，TDD 的 refactor 阶段也被重新划分。Skill 是版本化的工程资产，不能把一次复制的 Prompt 当作永久规则。
采用外部 Skill 时，需要先读它的实际行为和副作用。例如，to-spec 与 to-tickets 会写入 Issue tracker，架构检查会生成并打开 HTML 报告，其他实现 Skill 还可能执行 commit。项目的 AGENTS.md 或同类文件应明确 Git、文件写入、外部系统和破坏性操作的授权边界。
团队也不必原样接受所有规则。可以保留方法，调整载体：没有 Issue tracker 的项目可以写本地 Markdown；不适合自动 commit 的仓库可以在项目规则中要求人工确认；已有测试层次的项目应复用现有 seam。项目需要保留问题澄清、上下文压缩、纵向切片和反馈循环。
流程不能替代证据
Skill 可以约束 Agent 如何工作，不能证明实现正确。Spec 可能遗漏边界，Tickets 可能拆错依赖，测试可能选错 seam，架构报告也可能把个人偏好包装成结构建议。
每个阶段都要回到对应证据：需求由负责决定的人确认，代码事实从仓库和运行环境读取，行为由测试与真实操作验证，类型检查和 lint 处理静态问题，最终变更由独立审查检查范围与实现质量。
