@mattpocockuk: 提案:一项 /research 技能 非常简单——只需启动一个后台代理,查找高信任来源,并将其保存到 markdown 文件中
摘要
Matt Pocock 提出了一项 /research 技能,该技能可启动后台代理,搜索高信任来源,并将结果保存为 markdown 文件,这是他面向编码代理的开源技能集合的一部分。
查看缓存全文
缓存时间: 2026/07/01 18:11
提议: /research 技能 这个技能非常简单——只需启动一个后台代理去查阅高可信度的来源,并将结果保存为一个 markdown 文件。值得保留吗?还是纯粹的无操作?https://t.co/ZAcNurngFV —
mattpocock/skills
来源:https://github.com/mattpocock/skills
真正工程师的技能
skills.sh (https://skills.sh/mattpocock/skills)
我每天用来做真正工程工作的代理技能——不是 vibe coding。开发真正的应用程序很困难。像 GSD、BMAD 和 Spec-Kit 这类方法试图通过掌控流程来提供帮助,但这样做却剥夺了你的控制权,并使得流程中的错误难以解决。
这些技能设计得小巧、易于调整且可组合。它们能与任何模型一起使用。它们基于数十年的工程经验。随意摆弄它们,让它们成为你自己的。玩得开心。
如果你想跟上这些技能的更新以及我创建的任何新技能,可以加入我的通讯,已有约 6 万名开发者订阅: 注册通讯 (https://www.aihero.dev/s/skills-newsletter)
快速开始(30 秒设置)
- 运行 skills.sh 安装器:
bash npx skills@latest add mattpocock/skills - 选择你想要的技能,以及你想将它们安装到哪些编码代理上。确保你选中了
/setup-matt-pocock-skills。 - 在你的代理中运行
/setup-matt-pocock-skills。它会:- 询问你想使用哪个问题跟踪器(GitHub、Linear 或本地文件)
- 询问你在分类时对工单应用哪些标签(
/triage使用标签) - 询问你想将我们创建的文档保存在哪里
- 搞定——你可以开始了。
为什么会有这些技能
我创建这些技能是为了修复我在使用 Claude Code、Codex 和其他编码代理时常见的失败模式。
#1: 代理没有按照我的意愿行事
“没人确切知道自己想要什么。”
David Thomas & Andrew Hunt,《程序员修炼之道》(https://www.amazon.co.uk/Pragmatic-Programmer-Anniversary-Journey-Mastery/dp/B0833F1T3V)
问题。 软件开发中最常见的失败模式是信息不一致。你认为开发者知道你想要什么。然后你看到他们构建的东西——才发现他们根本没有理解你。这在 AI 时代也是一样。你与代理之间存在沟通鸿沟。
解决方法是一次 深入追问——让代理就你正在构建的内容向你提出详细问题。
解决方法是使用:
/grill-me——适用于非代码场景/grill-with-docs——与/grill-me相同,但增加了更多好东西(见下文)
这些是我最受欢迎的技能。它们能帮助你在开始之前与代理对齐,并深入思考你正在做的更改。每次你想要做出更改时都要使用它们。
#2: 代理过于啰嗦
有了通用语言,开发者之间的交流以及对代码的表达都源自同一个领域模型。
Eric Evans,《领域驱动设计》(https://www.amazon.co.uk/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215)
问题: 在项目开始时,开发者和他们所构建软件的服务对象(领域专家)通常说着不同的语言。我在我的代理身上也感受到了同样的紧张。代理通常被丢进一个项目,然后要求边做边理解术语。所以它们用 20 个词来表达本来 1 个词就能说清楚的事情。
解决方法是共享语言。这是一个帮助代理解码项目中使用的术语的文档。
示例
这是我的 course-video-manager 仓库中的一个 CONTEXT.md(https://github.com/mattpocock/course-video-manager/blob/076a5a7a182db0fe1e62971dd7a68bcadf010f1c/CONTEXT.md)示例。
哪一个更好理解?
- 之前:“当课程中的某个章节下的课程被设为‘真实’(即在文件系统中被分配了一个位置)时,会出现一个问题。”
- 之后:“实体化级联存在问题。”
这种简洁性在每个会话中都得到回报。这被内置到 /grill-with-docs 中。它是一个深入追问会话,但能帮助你与 AI 建立共享语言,并将难以解释的决策记录在 ADR 中。很难解释这有多强大。它可能是这个仓库中唯一最酷的技术。试试看,你会明白的。
[!提示] 共享语言除了减少啰嗦之外,还有许多其他好处:
- 变量、函数和文件命名一致,使用共享语言
- 因此,代理更容易浏览代码库
- 代理在思考上花费更少的 token,因为它能使用更简洁的语言
#3: 代码不工作
“始终采取小而谨慎的步骤。反馈率就是你的速度限制。永远不要承担太大的任务。”
David Thomas & Andrew Hunt,《程序员修炼之道》(https://www.amazon.co.uk/Pragmatic-Programmer-Anniversary-Journey-Mastery/dp/B0833F1T3V)
问题: 假设你和代理已经对齐了要构建的内容。当代理仍然产生糟糕的代码时怎么办?是时候看看你的反馈循环了。如果没有关于它生成的代码实际运行情况的反馈,代理将盲目飞行。
解决方法: 你需要通常的反馈循环:静态类型、浏览器访问和自动化测试。对于自动化测试,红-绿-重构循环至关重要。这就是代理首先编写一个失败的测试,然后修复测试。这有助于给代理提供一致的反馈水平,从而产生更好的代码。
我构建了一个 /tdd 技能,你可以将其插入任何项目中。它鼓励红-绿-重构,并为代理提供大量关于好测试和坏测试的指导。
对于调试,我还构建了一个 /diagnosing-bugs 技能,将最佳调试实践封装成一个简单的循环。
#4: 我们构建了一个泥球
“每天都要投入系统设计。”
Kent Beck,《解析极限编程》(https://www.amazon.co.uk/Extreme-Programming-Explained-Embrace-Change/dp/0321278658) “最好的模块是深层的。它们允许通过简单的接口访问大量功能。”
John Ousterhout,《软件设计哲学》(https://www.amazon.co.uk/Philosophy-Software-Design-2nd/dp/173210221X)
问题: 大多数用代理构建的应用都复杂且难以更改。因为代理可以极大地加快编码速度,它们也加速了软件熵。代码库以前所未有的速度变得复杂。
解决方法是一种激进的 AI 驱动开发新方法:关注代码的设计。这被内置到这些技能的每一个层面:
/to-prd在创建 PRD 之前询问你正在触及哪些模块
而且,至关重要的是,/improve-codebase-architecture 可以帮助你挽救一个已经变成泥球的代码库。我建议每几天在你的代码库上运行一次。
总结
软件工程基础比以往任何时候都更重要。这些技能是我将这些基础浓缩成可重复实践的最佳尝试,以帮助你交付职业生涯中最优秀的应用。享受吧。
参考
这些技能按照一个轴划分——谁能调用它们。
用户调用的技能只有在你输入它们时才可访问(例如 /grill-me);它们的作用是编排。
模型调用的技能可以由你调用,也可以在任务合适时由代理自动调用;它们承载着可复用的规范。一个用户调用技能可以调用模型调用技能,但不能调用另一个用户调用技能。
工程技能
我每天用于编码工作的技能。
用户调用
- ask-matt ——询问适合你情况的技能或流程。本仓库中用户调用技能的路由器。
- grill-with-docs ——深入追问会话,同时构建项目的领域模型,精炼术语并更新
CONTEXT.md和 ADR。 - triage ——通过一个分类角色的状态机来推动问题。
- improve-codebase-architecture ——扫描代码库以寻找深度化机会,将其呈现为可视化的 HTML 报告,然后针对你选中的一项进行深入追问。
- setup-matt-pocock-skills ——为本仓库配置工程技能(问题跟踪器、分类标签、领域文档布局)。在使用其他工程技能之前,每个仓库运行一次。
- to-issues ——使用垂直切片将任何计划、规范或 PRD 分解为可独立抓取的问题。
- to-prd ——将当前对话转换为 PRD 并发布到问题跟踪器。没有面试——只是综合你已经讨论过的内容。
模型调用
- prototype ——构建一个一次性原型来回答设计问题——用于状态/逻辑问题的可运行终端应用,或几个从一条路由切换的截然不同的 UI 变体。
- diagnosing-bugs ——针对困难错误和性能回归的规范诊断循环:复现 → 最小化 → 假设 → 工具检测 → 修复 → 回归测试。
- tdd ——带有红-绿-重构循环的测试驱动开发。一次构建一个垂直切片的功能或修复错误。
- domain-modeling ——主动构建并精炼项目的领域模型——对照术语表质疑术语,用边界案例场景进行压力测试,并内联更新
CONTEXT.md和 ADR。 - codebase-design ——设计深层模块的共享规范与词汇:一个小接口背后的许多行为,放置在干净的接缝处,可通过该接口进行测试。
- code-review ——自某个固定点以来的差异的双轴审查:标准(它是否遵循仓库的编码标准,加上 Fowler 的代码坏味基线?)和规范(它是否忠实地实现了原始问题/PRD?),作为并行子代理运行,以免相互污染。
生产力技能
通用工作流程工具,不特定于代码。
用户调用
- grill-me ——就一个计划或设计接受无休止的提问,直到决策树的每个分支都被解决。
- handoff ——将当前对话压缩成一个交接文档,以便另一个代理可以继续工作。
- teach ——在多个会话中向用户教授新技能或概念,使用当前目录作为有状态的教学工作区。
- writing-great-skills ——编写和编辑优秀技能的参考:使技能可预测的词汇和原则。
模型调用
- grilling ——就一个计划或设计无休止地提问用户,直到决策树的每个分支都被解决。
grill-me和grill-with-docs背后的可复用循环。
相似文章
@lastbtnotleast: 我刚刚发现了@mattpocockuk的技能仓库,对/grill-with-docs这个技能着迷了。我喜欢它的简洁性……
发现了Matt Pocock的技能仓库,重点介绍了用于AI工作流的/grill-with-docs技能,赞赏其简洁性,但指出从markdown文件中丢失了结构化数据的问题。
@mattpocockuk: 昨天,我发布了mattpocock/skills的v1版本,包括:- /ask-matt: 直接在智能体中向我询问如何最好地使用技能
Matt Pocock 发布了 mattpocock/skills 的 v1 版本,这是一个用于创建和管理 AI 智能体技能的工具,具有 /ask-matt 和编写最佳实践等功能。
@mattpocockuk: 技能如下:
一个包含官方Cursor插件(用于开发者工具)的GitHub仓库,涵盖代理工作流、代码审查、文档和CI集成。
我厌倦了维护 skill.md 文件,所以构建了一个开源 CLI,通过 GitHub 仓库来创建、管理和观察技能。你可以在任何智能体的会话之间监控、追踪和共享技能,同时迭代改进/版本化它们。
一个开源 CLI 工具,通过 GitHub 仓库创建、管理和版本化智能体技能,支持跨会话的可靠共享和观察。
mattpocock/skills
该开源仓库提供了一套可组合的 AI 代理技能与提示词,专为 Claude Code 和 Codex 等编程助手打造,旨在提升模型对齐效果、减少冗长输出,并优化整体工作流。