mattpocock/skills: A complete AI Coding workflow, end-to-end

从零开始安装与选择官方技能包

Matt Pocock 的 mattpocock/skills 仓库目前拥有 162,000 个星标和 750 万次下载，但此前缺乏系统的入门教程。为了演示如何在新项目或现有代码库中配置该工具，他使用了自己的 AI Hero CLI 仓库作为案例。安装过程极其简便，只需在终端执行 npx skills@latest add mattpocock/skills 命令。这一命令依赖于 Node.js 环境，通过 Vercel 的 CLI 安装器从 GitHub 拉取技能包。安装程序会自动检测并列出需要安装的依赖包，用户确认后即可完成基础环境的搭建。

安装完成后，系统会识别出 38 个可用技能，这些技能被分为两类：mattpocock/skills 和 other skills。前者是 Matt 认为足够成熟、适合公开使用的官方技能，后者则是他正在实验中的技能，未来可能会被删除。为了简化选择，Matt 建议在安装界面中按空格键 全选所有官方技能，然后回车确认。尽管他对 Vercel CLI 的滚动交互体验略有微词，但这套流程足以让用户快速获得一套经过验证的高质量技能集。

配置 AI 代理与安装作用域

mattpocock/skills 的一大优势是其 通用性，它支持多种 AI 代理工具，如 Cursor、Codex、Claude 等。然而，对于使用特定技能协议（如 Claude Skills）的代理（例如 Claude Code），用户需要手动进行配置。在安装向导中，用户可以选择支持的技能类型，Matt 演示了如何将其配置为与 Claude Code 兼容。这一步骤确保了技能能够被代理正确识别和调用。

接下来是 安装作用域（Installation Scope） 的选择，分为项目级（Project）和全局级（Global）。Matt 建议团队开发者优先选择项目级安装，以确保团队成员使用 统一的标准技能集，便于协作和贡献。而对于个人开发者，全局安装则更为便捷。在存储方式上，推荐使用 符号链接（Symlink） 而非复制文件，这种方式更简洁且易于维护。安装程序会生成一份摘要，确认所有配置无误后，即可将技能安装到指定目录，完成整个初始化过程。

技能调用机制与上下文优化

安装完成后，用户可以在 AI 代理中通过斜杠命令（如 /）查看可用的技能列表，包括 grill me、way finder 等。Matt 强调，他的技能设计哲学是 用户主动调用（User Invoked），而非被动监听上下文。这意味着大多数技能不会自动侵入 AI 的描述或上下文窗口，只有当用户明确输入命令时，相关技能才会被激活。这种设计极大地降低了 上下文负载（Context Load）。

"Even though we've downloaded all of my skills, the skills only take up 660 tokens here. So, it's very, very light in terms of context load."

通过这种轻量级设计，即使下载了全部技能，它们在上下文中的占用仅为 660 个 token。这种高效性使得 AI 代理在处理复杂任务时，能够保持更高的响应速度和更低的成本，同时避免因上下文过载导致的性能下降。用户只需掌握基本的调用命令，即可享受强大的自动化辅助，而无需担心配置复杂性对工作流程的干扰。

初始化配置与问题追踪器集成

安装技能包后，用户必须运行 setup mattpocock/skills 命令来完成最终配置。这一步骤至关重要，因为它会根据用户的实际需求，在仓库中生成必要的配置文件。Matt 指出，这套技能系统高度依赖于 问题追踪器（Issue Tracker），用于保存规范（specs）、工单（tickets）等关键信息。用户可以选择多种追踪工具，如 GitHub、Jira、Linear 或本地 Markdown 文件。

"All you need to do is just run setup mattpocock and just say, 'Set it up with Jira.'"

Matt 特别强调，系统已经内置了对多种追踪工具的支持。用户只需在配置过程中告知代理希望使用的工具（例如 "Set it up with Jira"），代理便会自动完成相应的配置。在演示中，Matt 选择了 本地 Markdown 作为追踪方式，并接受了默认的 分类标签（Triage Labels） 设置。这些标签用于规范工单的信息结构，虽然对初学者来说可能略显复杂，但遵循默认设置即可满足大多数需求。通过这一配置，技能系统便与用户的工作流程无缝集成，为后续的自动化开发奠定了坚实基础。

仓库配置与单上下文策略

在构建基于 AI 的编码工作流时，仓库的上下文配置是基础。视频演示了如何初始化一个名为 claw.md 的配置文件，其中包含指向 Issue Tracker、Triage Labels 和 Domain Docs 的链接。这些链接分别指向 docs/agents、docs/domain 和 docs/issue-tracker 等目录。系统会将所有问题和规范保存在一个 scratch file（临时文件）中，从而完成仓库的设置。对于绝大多数用户，单上下文（Single Context） 是最佳选择，只有在大型单体仓库（Mono Repo）需要多个有界上下文时，才考虑多上下文方案。

"I think single context is the way to go here. Multi-context is if you have a big mono repo and you need lots of different bounded contexts within it. But for 99% of people, a single context is going to be fine."

启动工作流：Ask Matt 技能

为了帮助用户快速上手，视频介绍了一个名为 Ask Matt 的技能，它本质上是将作者的知识库封装为一个 AI 技能。当用户询问如何开始代码变更时，Ask Matt 会引导用户遵循 Idea to Ship（从想法到发布）的主流程。核心原则是：在一个不间断的上下文窗口中，从主流程顶部向下执行。这强调了意识化地管理 上下文窗口（Context Window） 和 Token 使用量 对于高效使用 AI 至关重要。用户应首先使用 Grill with Docs 技能，通过对话 sharpen（打磨）想法，并利用仓库的状态特性，将学习到的信息记录在 context.md 和 ADRs（架构决策记录）中。

"Being conscious about the context window that you're using, the tokens that you're using is essential to using AI well."

Grill with Docs：深度访谈与计划制定

Grill with Docs 是一个交互式访谈工具，它会根据用户提出的模糊想法（例如“移除 CLI 的内部工具，只保留公开接口”）提出一系列跟进问题。视频演示中，作者使用 Claude Code（Opus 4.8 模型，Medium 效率，自动模式）进行了这次访谈。AI 首先扫描了整个仓库，识别出内部命名空间中的 11 个子命令。经过 6 个问题 的交互（通常可能需要 20 个左右），双方达成了 Shared Understanding（共同理解）。最终生成的计划包括：删除 10 个命令文件、删除 3 个测试文件、重新连接共享模块。这一过程将模糊的意图转化为 Defensible Plan（可辩护的计划）。

"Grill with docs is going to do the heavy lifting by asking you a bunch of follow-up questions... We've reached a shared understanding. Let me lay out the plan."

上下文窗口管理与多会话分拆

在制定计划后，用户面临一个关键决策：是否需要在多个会话中执行任务。作者指出，LLM 的 Smart Zone（智能区）大约在 140k Token 左右，超过此阈值会出现注意力降解和幻觉。在当前案例中，剩余上下文预算约为 100k Token，足以在单次会话中完成删除 10 个命令的任务。然而，为了演示多会话工作流，视频假设任务超出当前窗口限制，因此选择调用 Spec 技能而非直接执行 implement。

通过调用 to spec，系统将 46.1k Token 的对话记录压缩为本地 Markdown 文件，存入 Issue Tracker。这生成了两个关键文档：Spec（描述最终状态）和 Tickets（描述如何到达该状态），从而支持后续的 Multi-Ticket Sprint（多票据冲刺）。

从规格说明书到实施计划

在开始编码之前，详细的规格说明书（Spec）是确保AI代理准确理解需求的关键。作者展示了一个包含问题陈述、解决方案、用户故事、实施决策和测试决策的详细文档。这种结构化的文档不仅有助于人类理解，更能作为后续验证实现的基准。随后，作者在同一会话中指示AI将规格转化为实施计划（Tickets）。AI会将工作拆分为多个票证，每个票证的大小应控制在单个上下文窗口或单个智能区域（Smart Zone）的范围内，以确保AI能够高效处理。虽然AI有时会将工作拆分为过多的小块，但作者会根据实际情况调整，例如将三个票证合并为一个更合理的切片，并将其保存为tickets.md文件。这种拆分方式将庞大的工作任务转化为AI可管理的独立单元。

真实案例：大规模代码清理

为了展示该工作流的实际效果，作者分享了一个近期在仓库中进行的大规模代码清理案例。在这个案例中，AI生成了11个子问题（Sub-issues），每个子问题对应一个独立的上下文窗口会话。这些票证非常简洁，主要关注当前会话需要构建的具体内容，而详细的验收标准则保留在主规格说明书中。这种设计确保了每个会话都有清晰的目标，同时避免了上下文窗口的过载。作者强调，这种将大块工作拆解为可管理片段的方法，是AI代理能够成功执行复杂任务的核心。通过这种方式，即使面对复杂的重构或清理任务，也能保证每一步的准确性和可控性。

自动化实施与代码审查

在准备好规格和票证后，作者清空上下文并启动实施脚本。该脚本不仅执行代码实现，还自动运行类型检查、构建过程以及内部帮助文档检查。特别值得注意的是，实施过程中嵌入了代码审查（Code Review）环节。审查基于两个维度：一是将完成的工作与原始规格说明书进行比对，确保没有遗漏任何验收标准；二是检查代码是否符合编码标准文档（若仓库中无特定标准，则使用Martin Fowler的经典标准）。为了获得更客观的审查结果，作者采用子代理（Sub-agents）进行审查，而非让主代理自我审查。这是因为主代理往往倾向于认可自己刚编写的代码，而独立的子代理拥有清晰的上下文窗口，能更有效地识别代码异味（Code Smells）和潜在问题。最终，审查通过后，代码被提交到当前分支，整个工作流闭环完成。