项目仓库mattpocock/skillsStar 数51,400 ⭐排名GitHub 全球第 466 位开源协议MIT License主要语言Shell目录引言为什么需要真实工程技能项目概述与核心哲学四大核心问题及解决方案项目架构与目录结构核心技能详解安装与快速开始技能设计模式实战案例使用 TDD 技能设计理念深度剖析总结与延伸阅读1. 引言为什么需要真实工程技能1.1 AI 编码时代的挑战随着 Claude Code、Copilot、Cursor 等 AI 编码工具的普及软件开发的门槛大幅降低。然而这种便利也带来了新的问题 问题现象 ├── AI 生成的代码根本不是我想要的 ├── 代码能用但架构一团糟 ├── 调试了三天三夜问题还是没找到 └── 每次问 AI 都说需要更多上下文 深层原因 ├── 人类与 AI 之间存在沟通鸿沟 ├── 缺乏系统化的开发流程和反馈机制 ├── 过度依赖 AI忽视了软件工程基本功 └── 没有建立团队/项目的共享语言1.2 Matt Pocock 的回答Matt Pocock 是谁Total TypeScript创始人前 Vercel 工程师TypeScript 教育者和布道者拥有60,000订阅者的 newsletter他的答案是“真实工程技能”Skills for Real Engineers—— 基于数十年工程经验设计的 AI 代理技能集合这些技能不是替代工程基本功而是将它们系统化、可重复化帮助工程师在 AI 时代依然保持高质量产出。2. 项目概述与核心哲学2.1 项目定位┌─────────────────────────────────────────────────────────────┐ │ mattpocock/skills │ ├─────────────────────────────────────────────────────────────┤ │ 使命让 AI 代理做真实工程而非氛围编码 │ │ │ │ 特点 │ │ ├── 小型化每个技能专注单一职责易于理解和修改 │ │ ├── 可组合技能可以单独使用也可以组合形成工作流 │ │ ├── 模型无关适用于任何 AI 模型Claude/GPT/其他 │ │ └── 可定制鼓励用户修改以适应自己的需求 │ └─────────────────────────────────────────────────────────────┘2.2 核心哲学来自项目 README 的原话“Developing real applications is hard. Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve.”翻译开发真实应用程序很难。GSD、BMAD、Spec-Kit 等方法试图通过掌控流程来提供帮助但这样做会剥夺你的控制权使流程中的错误难以解决。Matt 的解决思路传统方法Matt 的方法流程优先技能优先自动化一切保留人的控制权固定流程可组合、灵活通用模板领域特定2.3 项目数据指标数值GitHub Stars51,400GitHub Forks4,300排名全球第 466 位创建时间2026 年 2 月提交次数63 次贡献者2 人技能总数16 个Newsletter 订阅~60,000 人3. 四大核心问题及解决方案3.1 问题总览┌────────────────────────────────────────────────────────────────────┐ │ AI 编码代理的四大失败模式 │ ├──────────────┬─────────────────────────────────────────────────────┤ │ 问题 #1 │ 代理没有按照我的意愿执行 │ │ 问题 #2 │ 代理过于冗长 │ │ 问题 #3 │ 代码无法工作 │ │ 问题 #4 │ 构建了泥球架构 │ └──────────────┴─────────────────────────────────────────────────────┘3.2 问题 #1代理没有按照我的意愿执行引用经典“No-one knows exactly what they want.”— David Thomas Andrew Hunt,《The Pragmatic Programmer》问题分析用户脑海中的想法 ──────→ [沟通鸿沟] ──────→ AI 理解的实现 vs 结果AI 构建的东西完全不是用户想要的解决方案Grilling Session深度访谈技能用途/grill-me非代码用途的通用访谈/grill-with-docs代码用途的高级访谈带文档更新工作原理用户我想添加一个用户认证功能 AI 追问 1. 用户指的是登录用户还是管理员用户 → 用户登录用户 2. 使用什么认证方式OAuth、邮箱密码、还是第三方登录 → 用户邮箱密码 3. 密码需要加密存储吗使用什么加密算法 → 用户bcrypt 4. 需要支持忘记密码功能吗通过邮件重置 → 用户是的 ... 直到决策树的每个分支都被解决3.3 问题 #2代理过于冗长问题分析 AI 生成代码 Here is the function that handles the user authentication process by first checking if the provided credentials match our stored hash... ✅ 理想情况 authenticateUser(credentials)根本原因AI 不理解项目中的专业术语缺乏领域模型和共享语言每次都需要重新解释相同的概念解决方案CONTEXT.md 共享语言示例对比❌ 之前模糊描述✅ 之后共享语言“There’s a problem when a lesson inside a section of a course is made ‘real’”“There’s a problem with the materialization cascade”共享语言的额外好处✅ 变量、函数、文件名命名一致✅ 代码库更易于 AI 导航✅ AI “思考” 消耗的 token 更少3.4 问题 #3代码无法工作问题分析没有反馈循环的 AI 编码 盲目飞行解决方案测试驱动开发 结构化调试技能用途/tdd红-绿-重构循环测试先行/diagnose硬 Bug 的规范化诊断循环/tdd 核心流程┌─────────────────────────────────────────────────────────────┐ │ TDD 红-绿-重构循环 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ RED 阶段 GREEN 阶段 REFACTOR │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 写失败 │ → │ 最简代码 │ → │ 重构代码 │ │ │ │ 的测试 │ │ 使测试 │ │ 提高质量 │ │ │ │ │ │ 通过 │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ 关键词垂直切片一次只做一个行为 │ └─────────────────────────────────────────────────────────────┘/diagnose 核心流程复现 → 最小化 → 假设 → 工具化 → 修复 → 回归测试3.5 问题 #4构建了泥球架构引用经典“Invest in the design of the system every day.”— Kent Beck,《Extreme Programming Explained》问题分析AI 的超能力 加速编码 AI 的副作用 加速软件熵增 结果代码库以前所未有的速度变得复杂难懂解决方案关注代码设计技能用途/to-prd创建 PRD 前先询问模块设计/zoom-out放大视角理解代码在系统中的位置/improve-codebase-architecture拯救泥球代码库4. 项目架构与目录结构4.1 整体目录结构mattpocock/skills/ │ ├── .claude-plugin/ # Claude 插件配置 │ ├── .out-of-scope/ # 范围外内容 │ ├── docs/ # 文档 │ └── adr/ # 架构决策记录 (Architecture Decision Records) │ ├── scripts/ # 实用脚本 │ ├── skills/ # 核心技能目录 │ │ │ ├── engineering/ # ️ 工程类技能9个 │ │ ├── diagnose/ # 调试诊断 │ │ ├── grill-with-docs/ # 深度访谈带文档 │ │ ├── triage/ # 问题分类 │ │ ├── improve-codebase-architecture/ # 架构改进 │ │ ├── setup-matt-pocock-skills/ # 初始化配置 │ │ ├── tdd/ # 测试驱动开发 │ │ ├── to-issues/ # 拆解为 Issues │ │ ├── to-prd/ # 创建 PRD │ │ └── zoom-out/ # 宏观视角 │ │ │ ├── productivity/ # ⚡ 生产力类技能3个 │ │ ├── caveman/ # 极简沟通模式 │ │ ├── grill-me/ # 通用访谈 │ │ └── write-a-skill/ # 创建新技能 │ │ │ └── misc/ # 杂项工具4个 │ ├── git-guardrails-claude-code/ │ ├── migrate-to-shoehorn/ │ ├── scaffold-exercises/ │ └── setup-pre-commit/ │ ├── CLAUDE.md # Claude 代理配置 ├── CONTEXT.md # 项目共享语言文档 ├── LICENSE # MIT 许可证 └── README.md # 项目说明4.2 技能分类详解┌─────────────────────────────────────────────────────────────┐ │ 技能分类图 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ engineering/ (9个) productivity/ (3个) │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ 日常代码工作 │ │ 通用工作流工具 │ │ │ │ │ │ │ │ │ │ • TDD │ │ • caveman │ │ │ │ • diagnose │ │ • grill-me │ │ │ │ • zoom-out │ │ • write-a-skill │ │ │ │ • ... │ │ │ │ │ └─────────────────┘ └─────────────────┘ │ │ │ │ misc/ (4个) │ │ ┌─────────────────┐ │ │ │ 备用工具 │ │ │ │ │ │ │ │ • git-guardrails│ │ │ │ • pre-commit │ │ │ │ • ... │ │ │ └─────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘4.3 每个技能的文件结构skill-name/ ├── SKILL.md # 主指令文件必需 ├── REFERENCE.md # 详细参考文档可选 ├── EXAMPLES.md # 使用示例可选 └── scripts/ # 实用脚本可选 └── helper.shSKILL.md 标准格式---name:skill-namedescription:技能描述. Use when[触发条件].---# Skill Name## Quick start[最小可用示例]## Workflows[带检查清单的分步流程]## Advanced features[链接到其他文件See REFERENCE.md]5. 核心技能详解5.1 Engineering 技能详解/tdd— 测试驱动开发文件位置skills/engineering/tdd/SKILL.md核心原则“测试应通过公共接口验证行为而非实现细节。代码可以完全改变但测试不应该。”好测试 vs 坏测试好测试坏测试集成风格通过公共 API 测试耦合到实现模拟内部组件描述系统做什么描述系统如何做能承受重构重构时测试就失败垂直切片 vs 水平切片❌ 水平切片错误 RED: test1, test2, test3, test4, test5 GREEN: impl1, impl2, impl3, impl4, impl5 ✅ 垂直切片正确 RED→GREEN: test1→impl1 RED→GREEN: test2→impl2 RED→GREEN: test3→impl3完整 TDD 流程┌─────────────────────────────────────────────────────────────┐ │ TDD 工作流 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 阶段 1: 规划 │ │ ├── [ ] 与用户确认接口变更 │ │ ├── [ ] 识别深度模块机会 │ │ └── [ ] 列出要测试的行为按优先级 │ │ │ │ 阶段 2: 追踪弹 │ │ ├── RED: 写一个测试 → 测试失败 │ │ └── GREEN: 写最简代码 → 测试通过 │ │ │ │ 阶段 3: 增量循环 │ │ 对每个剩余行为: │ │ ├── RED: 写下一个测试 → 失败 │ │ └── GREEN: 最简代码通过 │ │ │ │ 阶段 4: 重构 │ │ ├── [ ] 提取重复代码 │ │ ├── [ ] 加深模块 │ │ └── [ ] 每次重构后运行测试 ⚠️ 先到 GREEN │ │ │ └─────────────────────────────────────────────────────────────┘/diagnose— 结构化调试文件位置skills/engineering/diagnose/SKILL.md核心洞察“如果有一个快速、确定性、可代理运行的 pass/fail 信号来检测 Bug你会找到原因——二分搜索、假设测试和工具化都只是消耗那个信号。”诊断循环┌─────────────────────────────────────────────────────────────┐ │ 6 阶段诊断循环 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ Phase 1: 构建反馈循环 │ │ ├── 优先级 1: 失败的测试 │ │ ├── 优先级 2: Curl/HTTP 脚本 │ │ ├── 优先级 3: CLI 调用 │ │ └── ... 直到找到可验证的信号 │ │ │ │ Phase 2: 复现 (Reproduce) │ │ └── 运行循环观察 Bug 出现 │ │ │ │ Phase 3: 假设 (Hypothesise) │ │ ├── 生成 3-5 个排名假设 │ │ └── 每个假设必须是可证伪的 │ │ │ │ Phase 4: 工具化 (Instrument) │ │ ├── 每个探测映射到特定预测 │ │ ├── 调试器 定向日志 记录一切 │ │ └── 使用 [DEBUG-xxx] 前缀标记日志 │ │ │ │ Phase 5: 修复 回归测试 │ │ ├── 修复前写回归测试 │ │ └── 验证正确边界 │ │ │ │ Phase 6: 清理 复盘 │ │ ├── 移除所有 [DEBUG-xxx] │ │ └── 记录 什么能防止这个 Bug │ │ │ └─────────────────────────────────────────────────────────────┘反馈循环质量金字塔优先级 1: 失败的测试 ↓ 优先级 2: Curl / HTTP 脚本 ↓ 优先级 3: CLI 调用带快照对比 ↓ 优先级 4: 无头浏览器脚本Playwright ↓ ... 优先级 9: HITL bash 脚本最后手段/grill-with-docs— 深度访谈与文档同步文件位置skills/engineering/grill-with-docs/SKILL.md核心功能不断追问计划的每个方面与 CONTEXT.md 中的术语对照实时更新 CONTEXT.md 和 ADR文档结构规范# 标准仓库结构 / ├── CONTEXT.md # 领域术语和共享语言 ├── docs/ │ └── adr/ │ ├── 0001-event-sourced-orders.md │ └── 0002-postgres-for-write-model.md └── src/ └── ... # 多上下文仓库结构monorepo / ├── CONTEXT-MAP.md # 指向各上下文位置 ├── docs/ │ └── adr/ # 系统级决策 └── src/ ├── ordering/ │ ├── CONTEXT.md │ └── docs/adr/ └── billing/ ├── CONTEXT.md └── docs/adr/ADR 创建条件仅当全部满足条件说明1难以逆转后期改变成本高2缺乏上下文会让人困惑为什么这么做3存在真正的权衡选择了其中一个/zoom-out— 宏观视角文件位置skills/engineering/zoom-out/SKILL.md核心指令I dont know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the projects domain glossary vocabulary.用途场景接手不熟悉的代码区域理解某个功能在整体架构中的位置快速建立全局认知/improve-codebase-architecture— 架构改进文件位置skills/engineering/improve-codebase-architecture/SKILL.md核心概念术语定义Module任何有接口和实现的东西函数、类、包、切片Interface调用者必须知道的一切类型、不变量、错误模式、顺序、配置Depth杠杆效应大量功能隐藏在简单接口后Seam接口所在位置可以在不修改原代码的情况下改变行为Adapter在 seam 处满足接口的具体实现Deletion Test想象删除这个模块。如果复杂性消失了它是通道模块。如果复杂性分散到 N 个调用者中它是在创造价值的模块。发现深化机会寻找以下摩擦点 ├── 理解一个概念需要在多个小模块间跳跃 ├── 模块是浅层的接口几乎和实现一样复杂 ├── 纯函数被提取出来只是为了可测试性 ├── 紧耦合模块跨 seam 泄漏 └── 代码库难以测试5.2 Productivity 技能详解/grill-me— 通用访谈文件位置skills/productivity/grill-me/SKILL.md核心指令Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead.使用场景用户说 “grill me”想压力测试一个计划想被质询设计方案/caveman— 极简沟通核心概念通过删除填充词同时保持完整技术准确性减少约75%的 token 使用示例❌ 冗长版本✅ Caveman 版本“I think we should probably consider using…”“Use X”“It might be a good idea to refactor…”“Refactor X to use Y”“This could potentially improve performance…”“X improves perf”/write-a-skill— 创建新技能文件位置skills/productivity/write-a-skill/SKILL.md创建流程1. 收集需求 ├── 技能覆盖什么任务/领域 ├── 需要处理哪些具体用例 ├── 需要可执行脚本还是只需要指令 └── 有哪些参考资料 2. 起草技能 ├── SKILL.md简洁指令 ├── 参考文件内容超过 500 行时添加 └── 实用脚本确定性操作时添加 3. 与用户审核 ├── 覆盖所有用例 ├── 有缺失或不清晰 └── 详细程度合适SKILL.md 模板---name:skill-namedescription:Brief description. Use when[触发条件].---# Skill Name## Quick start[最小可用示例]## Workflows[带检查清单的分步流程]## Advanced features[链接到其他文件]5.3 Misc 技能详解技能用途git-guardrails-claude-code阻止危险的 git 命令push, reset --hard, cleanmigrate-to-shoehorn将as类型断言迁移到 total-typescript/shoehornscaffold-exercises创建带章节、问题、解决方案的练习目录结构setup-pre-commit设置 Husky pre-commit hookslint-staged, Prettier, 类型检查6. 安装与快速开始6.1 30 秒快速开始Step 1运行安装脚本npx skillslatestaddmattpocock/skillsStep 2选择技能和编码代理确保选择/setup-matt-pocock-skillsStep 3运行设置命令在代理中运行/setup-matt-pocock-skills设置命令会询问使用的问题跟踪器GitHub / Linear / 本地文件triage 时使用的标签保存文档的位置Step 4完成6.2 每个仓库的配置流程对于新仓库需要运行/setup-matt-pocock-skills该技能会创建以下配置docs/agents/ ├── issue-tracker.md # 问题跟踪器配置 ├── triage-labels.md # 标签词汇 └── domain.md # 领域文档布局标签系统5 个标准角色标签用途needs-triage需要维护者评估needs-info等待报告者提供信息ready-for-agent完全指定AI 可接手无人类上下文ready-for-human需要人类实现wontfix不会处理7. 技能设计模式7.1 技能命名规范skill-name/ ├── SKILL.md # 主文件 ├── REFERENCE.md # 详细参考 ├── EXAMPLES.md # 示例 ├── tests/ # 测试如有 └── scripts/ # 脚本如有7.2 SKILL.md 格式标准---name:skill-namedescription:描述. Use when[触发条件].---# Skill Name## Quick Start[一句话用法]## Workflows[详细流程 检查清单]## Advanced[链接到 REFERENCE.md]7.3 渐进式披露原则SKILL.md (简短) ↓ 链接 ↓ REFERENCE.md (详细) ↓ 链接 ↓ EXAMPLES.md (示例)规则SKILL.md 100 行超过 500 行内容 → 拆分到参考文件只深入一层引用7.4 触发条件写法好的示例description:Extract text from PDFs,fill forms,merge documents. Use when working with PDF files or when user mentions PDFs,forms,or document extraction.坏的示例description:Helps with documents.8. 实战案例使用 TDD 技能8.1 场景描述用户想要为一个电商系统添加购物车功能。8.2 步骤 1规划阶段AI 提问“购物车需要支持哪些操作”用户回答“添加商品、移除商品、更新数量、清空购物车、计算总价”AI 继续提问“添加商品时如果商品已经在购物车中怎么办”用户回答“增加数量而不是创建新条目”“用户指的是 Customer 还是 User它们是不同的概念。”… 继续直到决策树清晰8.3 步骤 2识别模块AI 提出的模块设计shopping-cart/ ├── domain/ │ ├── Cart.ts # 核心领域模型 │ ├── CartItem.ts # 购物车条目 │ └── events.ts # 购物车事件 ├── services/ │ └── CartService.ts # 购物车服务 └── ports/ └── CartRepository.ts # 仓库接口用于持久化8.4 步骤 3TDD 循环RED 阶段 - 写失败的测试// cart.test.tsdescribe(ShoppingCart,(){it(should add an item to the cart,(){constcartnewShoppingCart();cart.addItem({productId:PROD-001,quantity:2,price:29.99});expect(cart.items).toHaveLength(1);expect(cart.items[0].productId).toBe(PROD-001);});it(should increase quantity when adding existing item,(){constcartnewShoppingCart();cart.addItem({productId:PROD-001,quantity:2,price:29.99});cart.addItem({productId:PROD-001,quantity:3,price:29.99});expect(cart.items).toHaveLength(1);expect(cart.items[0].quantity).toBe(5);});// ... 更多测试});GREEN 阶段 - 最简实现// cart.tsexportclassShoppingCart{items:CartItem[][];addItem(item:CartItemInput):void{constexistingthis.items.find(ii.productIditem.productId);if(existing){existing.quantityitem.quantity;}else{this.items.push({...item});}}}REFACTOR 阶段提取CartItem类型添加价格验证保持接口干净8.5 步骤 4运行诊断如果测试失败使用/diagnose技能/diagnose AI: 请描述你观察到的失败。 用户: 添加商品时数量统计错误 AI: 让我运行反馈循环... Phase 1: 构建反馈循环 → 已有失败的测试跳过 Phase 2: 复现 → 运行测试观察失败 Phase 3: 假设 生成 3 个假设 1. 如果是数组引用问题 → 使用深拷贝 2. 如果是数量计算逻辑 → 检查 操作 3. 如果是类型问题 → 检查类型定义 ...9. 设计理念深度剖析9.1 核心设计原则原则 1小型化 (Small)❌ 一个技能做所有事 ✅ 一个技能只做一件事但做到极致原因易于理解和修改可以自由组合更容易测试和调试原则 2可组合 (Composable)skills/ ├── grill-me tdd 规划良好的 TDD ├── zoom-out grill-me 有全局视野的访谈 └── diagnose tdd 测试驱动的调试原则 3模型无关 (Model-Agnostic)不依赖特定 AI 模型的能力通用指令 → 适用于 Claude/GPT/其他不使用特定模型的专有功能鼓励用户修改以适应自己的模型原则 4保留人类控制权❌ 完全自动化用户失去控制 ✅ 技能辅助人类人类保持最终决策权9.2 与传统开发方法的对比维度GSD/BMAD/Spec-Kitmattpocock/skills流程固定流程优先技能组合优先控制流程自动化人保持控制灵活性低高适用场景通用项目管理专业工程实践学习曲线陡峭平缓可定制性低高9.3 共享语言的力量为什么共享语言如此重要没有共享语言 用户: When the materialization cascade fires but the lesson hasnt been made real yet... AI: I dont understand. Could you explain what made real means? 有共享语言 (CONTEXT.md): CONTEXT.md: ## materialization cascade The process of giving a CourseEntity (lesson, section, etc.) a spot in the file system, making it accessible to students. 用户: Theres a problem with the materialization cascade AI: Got it. What aspect of the cascade isnt working correctly?9.4 深度模块 vs 浅层模块深度模块理想// 深度模块示例interfaceLogger{debug(msg:string):void;info(msg:string):void;warn(msg:string):void;error(msg:string):void;}// 用户只需要知道这 4 个方法// 内部实现可以很复杂日志级别、格式化、持久化、轮转...浅层模块要避免// 浅层模块示例 - 接口和实现一样复杂classComplexLogger{privatelevel:LogLevel;privateformat:Formatter;privatetransport:Transport[];privatebuffer:Buffer;privateflushInterval:number;// ... 50 more fields// 用户必须了解所有内部细节才能使用}10. 总结与延伸阅读10.1 项目亮点总结┌─────────────────────────────────────────────────────────────┐ │ mattpocock/skills 核心亮点 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 定位AI 时代的真实工程技能库 │ │ │ │ 数据 │ │ ├── 51,400 Stars │ │ ├── GitHub 全球排名第 466 │ │ └── 16 个精心设计的技能 │ │ │ │ 四大核心问题解决方案 │ │ ├── 问题 1 → /grill-me, /grill-with-docs │ │ ├── 问题 2 → CONTEXT.md 共享语言 │ │ ├── 问题 3 → /tdd, /diagnose │ │ └── 问题 4 → /to-prd, /zoom-out, /improve-codebase-... │ │ │ │ 核心价值 │ │ ├── 小型化、可组合、模型无关 │ │ ├── 保留人类控制权 │ │ ├── 基于数十年工程经验 │ │ └── 真正帮助做真实工程而非氛围编码 │ │ │ └─────────────────────────────────────────────────────────────┘10.2 适用人群人群如何使用个人开发者使用基础技能提升代码质量团队建立共享语言和工程规范AI 爱好者学习如何与 AI 有效协作TypeScript 开发者配合 Total TypeScript 学习10.3 快速开始清单[ ] 运行安装命令npx skillslatest add mattpocock/skills [ ] 选择 /setup-matt-pocock-skills 进行初始化 [ ] 在新项目上运行 /setup-matt-pocock-skills [ ] 下次想构建功能时尝试 /grill-me [ ] 下次写代码时尝试 /tdd [ ] 下次遇到 bug 时尝试 /diagnose [ ] 创建 CONTEXT.md 建立项目共享语言10.4 相关资源资源链接GitHub 仓库https://github.com/mattpocock/skillsMatt Pocock TwittermattpocockNewsletterhttps://www.aihero.dev/s/skills-newsletterTotal TypeScripthttps://www.totaltypescript.com/10.5 延伸阅读推荐书籍书名作者与项目相关章节The Pragmatic ProgrammerDavid Thomas Andrew HuntGrilling philosophyDomain-Driven DesignEric Evans共享语言、ADRTest-Driven DevelopmentKent Beck/tdd 技能A Philosophy of Software DesignJohn Ousterhout深度模块概念Extreme Programming ExplainedKent Beck代码设计理念10.6 最后的思考“Software engineering fundamentals matter more than ever.”— Matt Pocock在 AI 时代工程基本功不是过时了而是更重要了。技能只是工具真正重要的是理解为什么这些技能有效以及如何在你的工作流中灵活运用它们。Matt 的技能库是一个起点而不是终点。Hack around with them. Make them your own. Enjoy.版权声明本文为技术分析博客详细解读了 mattpocock/skills 项目的设计理念和使用方法。项目版权归 Matt Pocock 所有遵循 MIT 许可证。参考引用项目 README: https://github.com/mattpocock/skillsMatt Pocock Newsletter: https://www.aihero.dev/s/skills-newsletter