# Mattpocock Skills

> Matt Pocock 编程Skill合集（核心：排错、极简输出、架构规范）。触发条件：BUG调试排错、代码诊断、性能回归排查、极简输出需求、架构重构优化、代码库解耦、模块深度设计、TDD测试驱动开发。

- Skill: `drgon1/mattpocock-skills` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add drgon1/mattpocock-skills`
- Raw SKILL.md: https://api.skillmd.com/api/skills/drgon1/mattpocock-skills/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: drgon1 (https://skillmd.com/u/drgon1)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/drgon1/mattpocock-skills

---


# Matt Pocock Skills 合集

> **核心原则**：本Skill整合 mattpocock/skills 仓库的核心工程实践，包含排错诊断、极简输出、架构规范三大模块。
>
> **使用对象**：需要系统化排错、精简输出、架构优化的AI模型。
>
> **强制要求**：匹配触发场景时，严格按对应模块流程执行，禁止跳过步骤或自主发挥。**如需编写测试脚本或使用截图功能，一律保存到 test/ 目录。**

---

## 触发条件

以下任一关键词或场景出现时，**自动启用本Skill**：

| 触发场景 | 典型需求 |
|---------|---------|
| BUG调试排错 | "诊断这个bug"、"调试这个错误"、"排查性能问题"、"代码报错" |
| 极简输出 | "说人话"、"精简回答"、"少说废话"、"简短点"、"caveman模式" |
| 架构规范 | "重构代码"、"优化架构"、"解耦模块"、"改善设计"、"代码太乱" |
| TDD开发 | "测试驱动"、"先写测试"、"红绿重构" |
| 代码审查 | "审查代码"、"代码质量"、"review代码" |

**非触发场景**（不启用本Skill）：
- 日常闲聊、生活问答
- 非技术类文案写作
- 纯数据库操作

---

## 模块一：排错诊断（Diagnose）

> 来源：mattpocock/skills - diagnose
> 适用：硬核BUG、性能回归、难以复现的问题

### 阶段1 — 构建反馈循环

**这是核心技能。** 没有快速、确定性的反馈信号，就无法定位问题。

按优先级尝试以下方式构建反馈循环：
1. **失败测试** — 在能触及bug的接缝处写测试
2. **Curl/HTTP脚本** — 针对运行中的开发服务器
3. **CLI调用** — 用固定输入，diff标准输出与已知正确快照
4. **无头浏览器脚本**（Playwright/Puppeteer）— 驱动UI，断言DOM/控制台/网络
5. **回放捕获的跟踪** — 保存真实请求/载荷/事件日志，隔离重放
6. **一次性测试工具** — 启动最小子系统，单函数调用即可触发bug路径
7. **属性/模糊测试** — 如果bug是"有时输出错误"，跑1000次随机输入
8. **二分法工具** — 如果bug出现在两个已知状态之间，自动化"在状态X启动→检查→重复"
9. **差异循环** — 同一输入跑旧版vs新版，diff输出
10. **人工辅助脚本** — 最后手段，用脚本驱动人工操作

**迭代反馈循环本身**：能否更快？信号更清晰？更确定？

### 阶段2 — 复现

运行循环，确认bug出现。确认：
- [ ] 循环产生的是**用户描述的**故障模式
- [ ] 故障可多次复现（或非确定性bug有足够高的复现率）
- [ ] 已捕获确切症状（错误消息、错误输出、慢速）

### 阶段3 — 提出假设

生成 **3-5个排序假设**，每个必须可证伪：
> 格式："如果<X>是原因，那么<改变Y>会使bug消失/<改变Z>会使它更严重"

**向用户展示排序列表**后再测试。用户可能有领域知识能立即重排。

### 阶段4 — 检测

每个检测必须对应阶段3的特定预测。**一次只改变一个变量。**

工具优先级：
1. 调试器/REPL检查
2. 针对性日志
3. 绝不"全量日志然后grep"

**给每个调试日志加唯一前缀**，如 `[DEBUG-a4f2]`，清理时grep删除。

### 阶段5 — 修复 + 回归测试

在**修复前**写回归测试——但只在有**正确接缝**时做。

如果存在正确接缝：
1. 将最小化复现转为该接缝处的失败测试
2. 观察它失败
3. 应用修复
4. 观察它通过
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）

当需要理解不熟悉的代码区域时：
1. 上升一层抽象
2. 给出所有相关模块和调用者的地图
3. 使用项目的领域术语表词汇

### 3.2 架构改进（Improve Codebase Architecture）

#### 核心术语

| 术语 | 定义 |
|------|------|
| **模块** | 任何有接口和实现的东西（函数、类、包、切片） |
| **接口** | 调用者使用模块所需知道的一切：类型、不变量、错误模式、顺序、配置 |
| **深度** | 接口的杠杆率：小接口背后的大行为。**深**=高杠杆，**浅**=接口几乎和实现一样复杂 |
| **接缝** | 接口所在的位置；可以在不原地编辑的情况下改变行为的地方 |
| **适配器** | 在接缝处满足接口的具体实现 |

#### 关键原则

- **删除测试**：想象删除该模块。如果复杂性消失，它是透传。如果复杂性在N个调用者中重新出现，它值得保留。
- **接口即测试面**。
- **一个适配器=假设性接缝。两个适配器=真实接缝。**

#### 执行流程

**1. 探索**
先阅读项目的领域术语表和ADR。然后有机地遍历代码库，记录遇到摩擦的地方：
- 理解一个概念需要在多少小模块之间跳转？
- 哪些模块是**浅**的？
- 哪些紧耦合模块紧密耦合，泄漏跨接缝？
- 哪些部分未经测试，或通过当前接口难以测试？

**2. 提交候选**
列出编号的深化机会列表。每个候选包含：
- **文件** — 涉及哪些文件/模块
- **问题** — 当前架构为何造成摩擦
- **方案** — 将改变什么的纯英文描述
- **收益** — 用局部性和杠杆率解释，以及测试如何改进

**3. 讨论循环**
用户选择候选后，进入讨论对话。走遍设计树——约束、依赖、深化模块的形状、接缝后的内容、哪些测试存活。

---

## 模块四：TDD 测试驱动开发

> 来源：mattpocock/skills - tdd
> 适用：需要测试驱动开发的场景

### 红绿重构循环

1. **红**：写一个失败测试，定义期望行为
2. **绿**：写最少代码让测试通过
3. **重构**：优化代码，保持测试通过

### 测试原则

- 一次一个垂直切片
- 测试应该快速、确定、隔离
- 测试是规范的可执行文档
- 先写测试再写代码

---

## 优先级规则

1. **排错场景** → 优先使用模块一（Diagnose）完整流程
2. **极简输出需求** → 启用模块二（Caveman）模式
3. **架构/重构需求** → 使用模块三（Architecture）流程
4. **TDD需求** → 使用模块四（TDD）流程
5. **多个场景叠加** → 按以上优先级顺序执行