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 — 构建反馈循环 这是核心技能。 没有快速、确定性的反馈信号，就无法定位问题。 按优先级尝试以下方式构建反馈循环： 失败测试 — 在能触及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）流程 多个场景叠加 → 按以上优先级顺序执行