Skills For Real Engineers：把工程基本功装进 AI Agent
很多 AI 编程工具的问题，不是“不会写代码”，而是太快了。
它可以很快写出一大段实现，也可以很快把一个误解放大成一整套错误设计。需求没对齐、领域语言没讲清、测试反馈不足、架构边界松散，这些老问题到了 Agent 时代不会消失，只会被加速。
Skills For Real Engineers 正是冲着这些问题来的。Matt Pocock 把自己日常使用的 Claude Code skills 开源出来，项目副标题写得很直白：给真实工程师用的 skills，不是 vibe coding。
这句话提醒工程师：别因为 Agent 能写代码，就把工程环节省掉。
它解决的是 Agent 开发里的四类失控
README 里把项目动机拆成几个很典型的失败模式。
第一类是对齐失败。你以为 Agent 明白了需求，等它交付出来才发现它理解的是另一个问题。grill-me 和 grill-with-docs 的作用，就是在开工前让 Agent 追问细节，把含糊的计划逼到足够明确。
第二类是语言失配。人和系统里的概念没有统一，Agent 就会用很多泛泛的描述绕来绕去。grill-with-docs 会把会话里的领域语言沉淀到 CONTEXT.md 和 ADR 里，让后续任务能复用同一套词汇。
第三类是反馈不足。Agent 写了代码，但没有可靠方式知道它是否真的工作。tdd 把红绿重构循环变成一个明确工作流，要求先写失败测试，再实现，再重构。diagnose 则把疑难 bug 和性能问题拉回到复现、最小化、假设、插桩、修复、回归测试的诊断循环里。
第四类是架构失控。Agent 能加速编码，也能加速软件熵。zoom-out 让 Agent 在修改陌生代码前先解释它在整个系统里的位置；improve-codebase-architecture 则用已有领域语言和 ADR 来寻找代码库里的“加深模块”机会。
这些 skill 看起来分散，背后连着同一条工程主线：先做判断，尽快得到反馈，把经验写进仓库。
小而可组合，而不是接管整个流程
Matt 在 README 里提到，GSD、BMAD、Spec-Kit 这类方法试图接管流程来帮助你交付，但也可能把控制权拿走，让流程自身的 bug 更难修。Skills For Real Engineers 选择了另一个方向：每个 skill 都尽量小，容易改，能和其他 skill 组合。
这个选择很实际。
一个“全自动开发框架”往往会假设你接受它的流程、术语和交付形态。Skills For Real Engineers 更像工具箱：你可以只用 tdd，也可以先 grill-with-docs，再 to-prd，再 to-issues，最后让 triage 帮你把 issue 推进到合适状态。
项目目前把 skills 分成几类：
engineering：日常代码工作，比如diagnose、tdd、to-prd、to-issues、triage、zoom-out。productivity：通用工作流，比如grill-me、handoff、teach、write-a-skill。misc：不常用但实用的工具，比如git-guardrails-claude-code、setup-pre-commit、migrate-to-shoehorn。personal、in-progress、deprecated：个人绑定、实验中或已废弃的 skill，不作为主推入口。
这种组织方式也反映了一个成熟工程库的习惯：公开推荐的能力、个人私货、实验草稿和废弃内容要有边界。Agent 读取能力清单时，边界越清楚，越不容易误用。
/setup-matt-pocock-skills 是入口，不是装饰
项目的快速开始很短：
| |
安装时选择需要的 skills 和目标 coding agents，然后运行 /setup-matt-pocock-skills。这个 setup skill 会问三个问题：你用哪个 issue tracker，triage 时使用哪些标签，文档要保存在哪里。
这些问题看起来琐碎，却决定了后续 skill 能不能落地。
to-issues、to-prd、triage 这些能力都需要知道 issue 写到哪里；triage 需要知道真实标签和 triage role 怎么映射；grill-with-docs 和架构类 skill 需要知道 CONTEXT.md、ADR、agent 文档该放在哪里。
setup 不只是安装向导。它在给仓库建立一层 Agent 可读的项目配置。
flowchart TD
A[setup-matt-pocock-skills] --> B[选择 Issue tracker]
A --> C[配置 triage 标签词汇]
A --> D[确定 docs/agents 与 ADR 位置]
B --> E[to-prd / to-issues / triage]
C --> E
D --> F[grill-with-docs / zoom-out / improve-codebase-architecture]
很多团队把 Agent 规则写成一大段“请你遵守最佳实践”。这类规则容易失效，因为它没有连接到仓库里的具体结构。Skills For Real Engineers 的做法更工程化：先把 issue、标签、文档位置这些约束落成文件，再让其他 skill 消费这些约束。
共享语言是它最有价值的设计之一
这个项目很重视 CONTEXT.md。在它自己的 CONTEXT.md 里，Matt 明确定义了 “Issue tracker”“Issue”“Triage role” 等术语，还标出哪些词应该避免。
这不是文档洁癖。Agent 在代码库里工作时，最怕同一个概念有三种叫法。今天叫 ticket，明天叫 backlog item，后天叫 issue，模型每次都要猜它们是不是一回事。猜错了，代码、文档和 issue 状态都会漂移。
grill-with-docs 的意义就在这里：它不只问需求，也会把问出来的领域语言写进仓库。下一次你让 Agent 处理同一类问题，它不必重新从聊天记录里推断上下文。
这和 DDD 里的 ubiquitous language 很接近。区别是，过去它主要服务人类协作；现在它也服务 Agent 协作。
真正的卖点是“工程基本功可执行”
Skills For Real Engineers 里最值得借鉴的，不是某个单独 skill 的提示词，而是它把工程基本功拆成可执行动作的方式。
“开工前想清楚”变成 grill-me。
“别只靠模型自信”变成 tdd 和 diagnose。
“先理解系统再改代码”变成 zoom-out。
“把大计划拆成能独立交付的任务”变成 to-issues。
“不要让架构变成泥球”变成 improve-codebase-architecture。
这些动作都不新。变化在于，它们可以被打包成 Agent 每次都能调用的工作流，不再只依赖工程师临场提醒。
它适合什么团队
如果你只是想让 Agent 快速生成一个 demo，这个项目可能显得有点“重”。它关心的问题不是第一次跑通，而是第十次、第百次修改之后，代码库还能不能被理解、测试和演进。
它更适合三类场景：
- 已经在用 Claude Code、Codex 或类似 coding agent，并开始感到上下文、规则和反馈回路不够稳定。
- 团队有 issue、ADR、测试和代码评审流程，希望 Agent 接入现有工程系统，而不是另起一套流程。
- 个人开发者想把自己的工程习惯沉淀为可复用 skill，而不是每次都靠口头提示。
它也有一个前提：你得愿意维护这些 skill 和文档。小而可组合不等于零成本。CONTEXT.md 会过期，ADR 会漏写，标签词汇会变，skill 描述也需要随着项目演化调整。
这正是“real engineers” 这个名字的含义。真实工程不是让 Agent 替你逃离复杂性，而是让复杂性有位置、有名字、有反馈。
对 Codex 用户的启发
虽然这个仓库来自 Matt 的 .claude 目录，但它的很多思想同样适用于 Codex。
第一，别把 AGENTS.md 写成百科全书。它更适合当路标，告诉 Agent 去哪里找项目规则、领域语言、测试方式和架构决策。
第二，把高频工程动作做成 skill。比如需求追问、TDD、问题诊断、PRD 到 issue 的拆分、架构审视。这些动作越稳定，Agent 的输出越可控。
第三，让 skill 消费项目事实，而不是只靠泛泛提示。issue tracker、标签、文档目录、测试命令、ADR 位置，这些信息都应该变成明确配置。
第四，保留人的控制权。Skills For Real Engineers 没有承诺“全自动写完整个产品”，它更像一套让工程师继续掌舵的放大器。
结语
AI 编程的下一个分水岭，可能不是谁的模型更会写代码，而是谁更会把工程系统设计成 Agent 能稳定参与的样子。
Skills For Real Engineers 给出的答案很朴素：需求要问清楚，语言要统一，测试要先行，诊断要有循环，架构要持续投资。
这些都是老基本功。只是在 Agent 时代，它们需要从人的习惯，变成仓库里可执行的技能。