drgon1 Matt Pocock Skills 合集
核心原则：本Skill整合 mattpocock/skills 仓库的核心工程实践，包含排错诊断、极简输出、架构规范三大模块。
使用对象：需要系统化排错、精简输出、架构优化的AI模型。
强制要求：匹配触发场景时，严格按对应模块流程执行，禁止跳过步骤或自主发挥。如需编写测试脚本或使用截图功能，一律保存到 test/ 目录。
触发条件
以下任一关键词或场景出现时，自动启用本Skill：
| 触发场景 | 典型需求 |
|---|---|
| BUG调试排错 | "诊断这个bug"、"调试这个错误"、"排查性能问题"、"代码报错" |
| 极简输出 | "说人话"、"精简回答"、"少说废话"、"简短点"、"caveman模式" |
| 架构规范 | "重构代码"、"优化架构"、"解耦模块"、"改善设计"、"代码太乱" |
| TDD开发 | "测试驱动"、"先写测试"、"红绿重构" |
| 代码审查 | "审查代码"、"代码质量"、"review代码" |
非触发场景（不启用本Skill）：
- 日常闲聊、生活问答
- 非技术类文案写作
- 纯数据库操作
模块一：排错诊断（Diagnose）
来源：mattpocock/skills - diagnose 适用：硬核BUG、性能回归、难以复现的问题
阶段1 — 构建反馈循环
这是核心技能。 没有快速、确定性的反馈信号，就无法定位问题。
按优先级尝试以下方式构建反馈循环：
- 失败测试 — 在能触及bug的接缝处写测试
- Curl/HTTP脚本 — 针对运行中的开发服务器
- CLI调用 — 用固定输入，diff标准输出与已知正确快照
- 无头浏览器脚本（Playwright/Puppeteer）— 驱动UI，断言DOM/控制台/网络
- 回放捕获的跟踪 — 保存真实请求/载荷/事件日志，隔离重放
- 一次性测试工具 — 启动最小子系统，单函数调用即可触发bug路径
- 属性/模糊测试 — 如果bug是"有时输出错误"，跑1000次随机输入
- 二分法工具 — 如果bug出现在两个已知状态之间，自动化"在状态X启动→检查→重复"
- 差异循环 — 同一输入跑旧版vs新版，diff输出
- 人工辅助脚本 — 最后手段，用脚本驱动人工操作
迭代反馈循环本身：能否更快？信号更清晰？更确定？
阶段2 — 复现
运行循环，确认bug出现。确认：
- 循环产生的是用户描述的故障模式
- 故障可多次复现（或非确定性bug有足够高的复现率）
- 已捕获确切症状（错误消息、错误输出、慢速）
阶段3 — 提出假设
生成 3-5个排序假设，每个必须可证伪：
格式："如果是原因，那么<改变Y>会使bug消失/<改变Z>会使它更严重"
向用户展示排序列表后再测试。用户可能有领域知识能立即重排。
阶段4 — 检测
每个检测必须对应阶段3的特定预测。一次只改变一个变量。
工具优先级：
- 调试器/REPL检查
- 针对性日志
- 绝不"全量日志然后grep"
给每个调试日志加唯一前缀，如 [DEBUG-a4f2]，清理时grep删除。
阶段5 — 修复 + 回归测试
在修复前写回归测试——但只在有正确接缝时做。
如果存在正确接缝：
- 将最小化复现转为该接缝处的失败测试
- 观察它失败
- 应用修复
- 观察它通过
- 对原始（未最小化）场景重新运行阶段1的反馈循环
阶段6 — 清理 + 事后分析
声明完成前必须：
- 原始复现不再复现
- 回归测试通过（或无接缝已记录）
- 所有
[DEBUG-...]检测代码已移除 - 一次性原型已删除
- 正确的假设记录在提交/PR消息中
模块二：极简输出（Caveman）
来源：mattpocock/skills - caveman 适用：需要精简回答、减少Token消耗的场景
核心规则
回复像聪明的原始人一样简洁。所有技术内容保留，只删废话。
丢弃：冠词（a/an/the）、填充词（just/really/basically/actually/simply）、客套话（sure/certainly/of course）、模糊词。
允许：片段句。短同义词（big 不写 extensive，fix 不写 "implement a solution for"）。缩写通用术语（DB/auth/config/req/res/fn/impl）。去掉连词。用箭头表示因果（X -> Y）。一个词能说清就用一个词。
技术术语保持精确。代码块不变。错误信息原样引用。
模式：[事物] [动作] [原因]. [下一步].
不写："Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
写："Bug in auth middleware. Token expiry check use < not <=. Fix:"
持久性
一旦触发，每次回复都保持极简模式。不会多轮后恢复啰嗦。只有用户说"stop caveman"或"normal mode"才关闭。
自动清晰例外
以下情况临时退出极简模式：安全模式：安全警告、不可逆操作确认、多步骤序列中片段顺序可能导致误解、用户要求澄清或重复问题。清晰部分完成后恢复极简。
模块三：架构规范（Zoom Out + Improve Architecture）
来源：mattpocock/skills - zoom-out + improve-codebase-architecture 适用：代码库架构分析、重构优化、模块深度设计
3.1 全局视角（Zoom Out）
当需要理解不熟悉的代码区域时：
- 上升一层抽象
- 给出所有相关模块和调用者的地图
- 使用项目的领域术语表词汇
3.2 架构改进（Improve Codebase Architecture）
核心术语
| 术语 | 定义 |
|---|---|
| 模块 | 任何有接口和实现的东西（函数、类、包、切片） |
| 接口 | 调用者使用模块所需知道的一切：类型、不变量、错误模式、顺序、配置 |
| 深度 | 接口的杠杆率：小接口背后的大行为。深=高杠杆，浅=接口几乎和实现一样复杂 |
| 接缝 | 接口所在的位置；可以在不原地编辑的情况下改变行为的地方 |
| 适配器 | 在接缝处满足接口的具体实现 |
关键原则
- 删除测试：想象删除该模块。如果复杂性消失，它是透传。如果复杂性在N个调用者中重新出现，它值得保留。
- 接口即测试面。
- 一个适配器=假设性接缝。两个适配器=真实接缝。
执行流程
1. 探索 先阅读项目的领域术语表和ADR。然后有机地遍历代码库，记录遇到摩擦的地方：
- 理解一个概念需要在多少小模块之间跳转？
- 哪些模块是浅的？
- 哪些紧耦合模块紧密耦合，泄漏跨接缝？
- 哪些部分未经测试，或通过当前接口难以测试？
2. 提交候选 列出编号的深化机会列表。每个候选包含：
- 文件 — 涉及哪些文件/模块
- 问题 — 当前架构为何造成摩擦
- 方案 — 将改变什么的纯英文描述
- 收益 — 用局部性和杠杆率解释，以及测试如何改进
3. 讨论循环 用户选择候选后，进入讨论对话。走遍设计树——约束、依赖、深化模块的形状、接缝后的内容、哪些测试存活。
模块四：TDD 测试驱动开发
来源：mattpocock/skills - tdd 适用：需要测试驱动开发的场景
红绿重构循环
- 红：写一个失败测试，定义期望行为
- 绿：写最少代码让测试通过
- 重构：优化代码，保持测试通过
测试原则
- 一次一个垂直切片
- 测试应该快速、确定、隔离
- 测试是规范的可执行文档
- 先写测试再写代码
优先级规则
- 排错场景 → 优先使用模块一（Diagnose）完整流程
- 极简输出需求 → 启用模块二（Caveman）模式
- 架构/重构需求 → 使用模块三（Architecture）流程
- TDD需求 → 使用模块四（TDD）流程
- 多个场景叠加 → 按以上优先级顺序执行