mattpocock-skills

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

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个排序假设，每个必须可证伪：

格式："如果是原因，那么<改变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. 多个场景叠加 → 按以上优先级顺序执行