Agent Skills 收集

Agent Skills 收集

这页放在 docs 里。原因很直接：skills 更像长期更新的工具索引，适合放安装命令、适用场景和使用顺序。博客更适合写完整经验和复盘。

这一组都是写代码时用的 skills。我会按三条线理解：

• DDD / docs：先拷问方案，把项目语言、领域词、决策背景收清楚。
• PRD / delivery：把已经对齐的上下文收成 PRD，再拆成可验证的垂直切片。
• TDD / architecture：先定模块接口和测试 seam，再用测试和架构反馈推进实现。

一次性安装

npx skills add https://github.com/mattpocock/skills --skill grilling
npx skills add https://github.com/mattpocock/skills --skill domain-modeling
npx skills add https://github.com/mattpocock/skills --skill grill-with-docs
npx skills add https://github.com/mattpocock/skills --skill codebase-design
npx skills add https://github.com/mattpocock/skills --skill improve-codebase-architecture
npx skills add https://github.com/mattpocock/skills --skill to-prd
npx skills add https://github.com/mattpocock/skills --skill tdd
npx skills add https://github.com/mattpocock/skills --skill to-issues
npx skills add https://github.com/multicul-silver-wolf/agent-docs-system-skill --skill project-docs-system

DDD / docs

grilling

来源：mattpocock/skills

用来对一个 plan 或 design 做连续追问。它的重点是沿着设计树一层层问下去，每次只问一个问题，并给出推荐答案，直到方案边界和依赖关系讲清楚。

我会在这些场景用它：

• 方案还停在“感觉可行”，需要被具体问题压实。
• 设计里有多个互相依赖的选择，需要逐个拆开。
• 想先做纯讨论，不急着写文档或改代码。

domain-modeling

来源：mattpocock/skills

用来主动维护项目领域模型。它会挑战模糊术语、补 edge-case 场景、交叉检查代码和现有 glossary，并在术语或决策定下来时更新 CONTEXT.md 或 ADR。

我会在这些场景用它：

• 项目里的业务词还不稳定，或者同一个词被多个意思复用。
• 需要把用户语言和代码里的概念对齐。
• grill-with-docs 要落地 glossary 或 ADR 时，需要它来维护领域模型。

grill-with-docs

来源：mattpocock/skills

用来把一个方案放到项目已有领域模型里拷问。它可以理解成 grilling 加 domain-modeling 的组合：一边追问术语、边界、场景和决策依据，一边把确定下来的 glossary 或 ADR 写回文档。

我会在这些场景用它：

• 新功能概念还没讲清楚。
• 业务词和代码里的词可能冲突。
• 需要补 CONTEXT.md、glossary 或 ADR。

project-docs-system

来源：multicul-silver-wolf/agent-docs-system-skill

用来建立和维护项目文档系统。它强调把知识按项目级、领域级、子领域级分层放好，避免所有规则都堆进一个 README。

我会在这些场景用它：

• 新仓库需要 agent 可读的文档入口。
• 某个模块出现长期约束，需要沉淀到文档。
• 用户纠正了项目惯例，需要记录给后续 agent 使用。

PRD / TDD / delivery

to-prd

来源：mattpocock/skills

用来把当前对话和代码库上下文整理成 PRD。它适合放在讨论已经收敛之后，把问题、方案、用户故事、实现决策、测试决策和排除范围沉淀下来。

我会在这些场景用它：

• 需求已经讲清楚，但还缺一份能交给 agent 执行的 PRD。
• 需要在拆 issue 之前先统一问题、方案和范围。
• 想把测试边界提前写进需求，而不是等实现时临时补。

to-issues

来源：mattpocock/skills

用来把 plan、spec 或 PRD 拆成 issue。重点是按 tracer bullet 垂直切片拆，避免按数据库、API、UI 这种横向层级拆。

我会在这些场景用它：

• 一个需求太大，需要拆成可独立领取的任务。
• 想把每个 issue 都做成可验证、可 demo 的小闭环。
• 需要区分哪些切片能 AFK 执行，哪些切片需要 HITL 决策。

codebase-design

来源：mattpocock/skills

用来给模块设计和测试边界提供共享词汇。重点是 deep module、interface、seam、adapter、locality 这些概念，适合在进入 TDD 前先决定测试应该穿过哪个接口。

我会在这些场景用它：

• 准备写测试，但还不确定测试 seam 应该放在哪里。
• 模块接口太浅、太散，想先收敛成更深的模块。
• tdd 或架构讨论需要统一 module、interface、seam、adapter 这些词。

tdd

来源：mattpocock/skills

用来按红绿灯推进实现。重点是一次只写一个行为测试，通过公开接口验证行为，再补最小实现，最后重构。

我会在这些场景用它：

• 修 bug 时需要先复现行为。
• 新功能有清楚的核心契约。
• 重构前需要一组能守住行为的测试。

improve-codebase-architecture

来源：mattpocock/skills

用来找架构加深机会。它会关注模块是否太浅、接口是否暴露太多、复杂度是否散在调用方，以及测试面是否真正落在公开接口上。

我会在这些场景用它：

• 代码能跑，但越来越难测、难改、难让 agent 理解。
• 逻辑被拆得很碎，理解一个概念要跳很多文件。
• 想把关键模块做成更深的模块，让小接口承接更多稳定行为。

推荐使用顺序

实际使用时不要一次把所有 skill 都打开。先看任务阶段：

1. 只是想拷问 plan 或 design：用 grilling。
2. 术语、领域词、决策记录需要沉淀：用 domain-modeling。
3. 要把方案放进现有领域模型里边问边写文档：用 grill-with-docs。
4. 项目缺少长期文档承接：用 project-docs-system。
5. 需求方向已经对齐，但还缺 PRD：用 to-prd。
6. PRD 或计划已经成型，需要拆任务：用 to-issues。
7. 要进入 TDD，但测试 seam 还没定：用 codebase-design。
8. 已经进入实现或修 bug：用 tdd。
9. 代码结构开始拖慢交付：用 improve-codebase-architecture。

这组 skills 和我的 Harness Engineering 配方 是同一条线：让 agent 不只会写补丁，还能沿着拷问、领域建模、文档、PRD、issue、模块 seam、测试和架构反馈持续推进。