定位
mattpocock-dev-workflows 是一个元技能，将 Matt Pocock 技能仓库中的五项工程规范打包在一起，用于应对编码智能体常见的五种失败模式。这些子技能被设计为小型、可组合、可适配，据称适用于任何模型和任何代码库。
五个子模式与对应失败模式
- to-spec — 智能体没有做你想要的（错位）：把当前对话与对代码库的理解综合成结构化规格，发布到项目 issue tracker。
- codebase-design — 智能体造出“泥球”（代码熵）：设计深模块（小接口、多行为），放在干净的 seam 上，通过接口可测试。
- domain-modeling — 智能体过于冗长（无共享语言）：建立共享领域术语表 CONTEXT.md 与 ADR。
- diagnosing-bugs — 代码不工作（缺反馈回路）：六阶段规范化调试循环。
- code-review — 无法判断变更好坏（缺审查纪律）：Standards + Spec 双轴审查。
每个子模式可独立使用，元技能根据任务目标路由到合适子模式。
主要能力
to-spec
不进行访谈，直接综合已讨论内容。步骤：探索仓库了解现状；勾勒测试 seam（尽可能高，优先已有 seam）；与用户确认 seam；按模板写规格；带标签发布到 issue tracker。
规格模板包含：问题陈述、解决方案、用户故事、实现决策（模块、接口、技术澄清、架构决策、schema 变更、API 契约；不含具体文件路径或代码片段，原型验证过的状态机、reducer、schema 或类型形状除外）、测试决策、范围外、补充说明。
codebase-design
提供设计深模块的共享词汇与规范，包括 module、interface、implementation、depth、seam、adapter、leverage、locality 等术语的定义与避免使用的词。
核心原则：深度是接口属性而非实现属性；删除测试（模块消失后复杂度是否在多个调用方重现）；接口即测试面；只有一个适配器时 seam 是假设性的，两个适配器才是真实 seam；不要因测试而暴露内部 seam。
可测试性设计：接受依赖而非创建依赖；返回结果而非产生副作用；小表面积减少测试需求。
加深流程：对依赖分类（进程内、可本地替代、远程但自有、真正外部），按 Ports & Adapters 等方式处理；替换而非叠加。
Design It Twice：框定问题空间后并行派生 3 个以上子智能体，分别以最小化接口、最大化灵活性、优化最常见调用方（可选 Ports & Adapters）为约束设计，再按深度、locality、seam 位置比较并给出有主见的推荐或混合方案。
domain-modeling
主动构建并打磨项目领域模型：用术语表挑战术语；为模糊或过载词提出精确规范术语；用边界场景压力测试；与代码交叉核对；立即内联更新 CONTEXT.md；仅在难以逆转、脱离上下文会令人意外、且是真实权衡结果三者同时满足时才提议 ADR。
文件结构支持单上下文（根目录 CONTEXT.md + docs/adr/）与多上下文（CONTEXT-MAP.md + 各子目录 CONTEXT.md 与 docs/adr/）。
CONTEXT.md 仅收录项目特有概念，定义一到两句，选定最佳术语并在 Avoid 下列出同义词。ADR 可以是一段话。
code-review
对 HEAD 与用户指定固定点之间的 diff 做双轴审查，两轴作为并行子智能体运行以避免上下文互相污染。
步骤：固定基点并采集 git diff 与 git log；确定规格来源（提交信息中的 issue 引用、用户传入路径、docs/ specs/ .scratch/ 下匹配分支名的规格文件，否则询问用户）；确定标准来源（CODING_STANDARDS.md、CONTRIBUTING.md 等）加 Fowler《重构》第 3 章坏味道基线（神秘命名、重复代码、依恋情结、数据泥团、基本类型偏执、重复 switch、霰弹式修改、发散式变化、夸夸其谈通用性、消息链、中间人、被拒绝的遗赠）；并行运行标准子智能体与规格子智能体，各自少于 400 词，区分硬性违规与主观判断；最后在 ## Standards 与 ## Spec 标题下原样呈现，不跨轴合并或重排。
diagnosing-bugs
六阶段循环，仅在明确说明理由时跳过阶段：
- 构建反馈回路（这是核心）：失败测试、curl/HTTP 脚本、CLI 调用、无头浏览器脚本、重放 trace、一次性 harness、属性/模糊测试、二分 harness、差分回路、人工 bash 脚本（最后手段）。回路需红能力、确定性、快速、可无人值守运行。
- 复现并最小化到每个剩余元素都是必要的。
- 在测试前生成 3-5 个可排序、可证伪的假设，每个声明预测，先给用户看。
- 插桩：一次改一个变量，优先调试器/REPL 或有唯一前缀的定向日志；性能回归先建立基线再二分。
- 先写回归测试再修复；若无正确 seam 需标记架构问题；观察失败、修复、观察通过，再跑原始回路。
- 清理：原始复现不再出现、回归测试通过、移除所有 [DEBUG-...] 插桩、删除一次性原型、在提交/PR 信息中写明正确假设。
展示命令与产物前须脱敏，密钥用 <REDACTED> 替代，回路通过环境变量构建。
适用场景
- 新功能：to-spec + domain-modeling + codebase-design 组合。
- 缺陷或回归：仅用 diagnosing-bugs，不混用其他模式。
- 代码审查：变更后用 code-review。
- 架构整理：用 codebase-design 找可加深的候选。
- 改善智能体沟通：用 domain-modeling 建立共享语言。
限制与不适用场景
- 代码库没有 CONTEXT.md 且只需快速修复时不适用。
- 从零搭建项目应使用 app-scaffolding。
- 探索代码库未知未知项应使用 finding-unknowns。
- 优化模型路由成本应使用 model-routing-cost-optimizer。
资料未提供安装方式、平台要求、收费或价格信息。