核心思想
作者的设计原则、与同类项目的差异化定位、关键工作流的简要介绍。文中提到的技能名称会自动链接到对应技能页。
mattpocock/skills 与 GSD、BMAD、Spec-Kit 等"全包式"框架不同，这套技能坚持三个原则：
当你给 AI 提出开发需求时，技能集在后台按以下流程自动调度：
需求对齐（Grilling）
原型验证（Prototype）
规格化与拆解（Spec & Tickets）
实现（Implement）
架构维护（Architecture Health）
技能关系
Skill → Skill 的使用关系，可跨层指向。同色块表示同一类技能形态。
技能组成
每个技能都为某种调用者设计——有的必须由你点名触发，有的则由模型自动按上下文加载。下面的两张卡片一眼看清整个技能集的触发分工。
这些技能期待被用户手动直接点名使用。
由模型在判断上下文相关时自动使用，通常不需要点名调用。
技能清单
针对技能集的"路由器"技能：用户不记得有哪些技能或不确定用哪个流程时，调用此技能获取推荐。它描述了从"想法→交付"的主流程（grill-with-docs → to-spec/to-tickets → implement），以及 on-ramps（triage、diagnosing-bugs、wayfinder）、代码库维护（improve-codebase-architecture）、底层词汇技能（domain-modeling、codebase-design）和独立技能（grill-me、prototype、research、teach）。按此推荐即可找到正确的工作流入口。
双轴线代码审查技能：对一个 diff（从固定点到 HEAD）同时发起 Standards（编码规范 + Fowler 代码坏味基线）和 Spec（是否忠实实现了原始需求）两条轴线的审查，两条线用并行子 Agent 独立执行以避免相互污染。最终聚合报告，不合并两个维度的结论，确保"编码规范达标但做错了功能"与"功能做对了但违反规范"两种失败模式都能被独立发现。
深度模块设计的共享词汇技能：提供一套精确的设计术语（Module、Interface、Depth、Seam、Adapter、Leverage、Locality），指导 Agent 和开发者设计"深度模块"——小接口背后承载大量行为的模块。包含设计原则（删除测试、接口即测试面等）和可测试性指南。本技能是"引用型"参考，供其他技能（如 improve-codebase-architecture、tdd）和被工程师手动调用时使用。
针对"硬 bug"和性能回归的严谨诊断循环技能：核心思想是先构建一个紧致的反馈循环（tight feedback loop），没有循环就不进入假设阶段。分为 6 个阶段：构建反馈循环 → 复现并最小化 → 生成 3-5 条可证伪假设 → 按预测插桩 → 修复并添加回归测试 → 清理与事后分析。如果代码库架构无法锁定 bug，会推荐转给 improve-codebase-architecture 技能。
主动构建和精炼领域模型的技能：在对话过程中实时挑战术语、澄清模糊语言、压力测试场景、交叉验证代码与建模的一致性、即时更新 CONTEXT.md 词表，并审慎地创建 ADR（仅当决策难以逆转、后来者看到会意外、且经过了真正权衡时）。不只是一本词典，而是持续"打磨"领域模型的活性流程。
无文档产出的"拷问"技能：直接代理一个 /grilling 会话，对用户的计划或设计进行逐一的、坚持不懈的追问，直到每个决策树分支都被解析。与 /grill-with-docs 的区别是不产生持久化文档——不更新 CONTEXT.md、不创建 ADR，适合没有代码库或不需要文档沉淀的场景（如头脑风暴、个人计划推敲）。用户手动调用。
有文档产出的"拷问"技能：对用户关于计划或设计进行坚持不懈的追问（通过 /grilling 技能），同时利用 /domain-modeling 技能在对话过程中持续构建项目领域模型——更新 CONTEXT.md 词表和创建 ADR。与 /grill-me 的主要区别是它会产生持久化的文档资产。用户手动调用，适合有代码库的场景。
通用"拷问"流程——技能集中最底层的可复用采访循环：对用户关于计划、决策或想法进行逐一追问，每次一个问题，走完每个决策树分支。可查证的事实自己查找不做决策，决策由用户做、等回答再继续，不作动直到用户确认共享理解达成。被 /grill-me 和 /grill-with-docs 两个用户调用的入口技能代理使用，也由 /improve-codebase-architecture、/triage、/wayfinder 等其他技能在需要结构化讨论时自动加载。
跨会话交接技能：将当前对话的关键上下文压缩为一篇 Markdown 交接文档，保存到用户 OS 临时目录，供另一个 Agent 在新会话中接续工作。包含"建议技能"章节推荐后续 Agent 应加载哪些技能。不重复已在其他作品中（specs、plans、ADRs、issues、commits、diffs）的内容，引用其路径或 URL。脱敏 API key、密码等敏感信息。
基于 spec 或 ticket 执行开发工作的技能：读入用户提供的 spec 或 ticket 集合，在预定 seam 处尽量使用 /tdd 进行开发，定期运行类型检查和单测，最后通过 /code-review 审查变更后提交到当前分支。是整个"想法→交付"主流程中实际的"写代码"环节，上游衔接 /to-spec 和 /to-tickets。
代码架构改进技能：扫描代码库寻找"深度化机会"（将浅度模块转为深度模块），生成一份可视化的 HTML 报告（含 Tailwind 样式和 Mermaid 图表），然后用户选择一个候选后进入 /grilling 环节来具体设计。利用 /codebase-design 词汇进行分析、/domain-modeling 维护领域模型、/grilling 走通决策树。定期运行可以防止代码库变成"泥球"（ball of mud）。
快速构建一次性原型来回答设计问题的技能：识别问题的两个分支——"这个逻辑/状态模型对吗？"用终端交互应用验证，"这个 UI 应该长什么样？"用多版本 UI 切换探索。原型代码从第一天起就被标记为"可丢弃"，不写测试、不做错误处理、不持久化。原型结论沉淀到真正的代码中，原型本身提交到一个独立分支作为"原始资料"保存。
后台研究技能：将研究任务委托给一个后台 Agent 去执行，让主 Agent 可以继续当前工作。后台 Agent 只查询高可信度的一手资料（官方文档、源码、规范、第一方 API），不依赖二手分析文章。研究成果以 Markdown 文件形式保存到仓库中，每条声明都附带来源引用。
Git 合并/变基冲突系统性解决技能：按步骤进行——查看当前冲突状态 → 找到每处冲突的一手来源（commit message、PR、issue），深刻理解双方的原始意图 → 逐个大区解决，尽可能同时保留双方意图，冲突时按合并目标取舍 → 运行项目的自动化检查 → 完成合并/变基。核心原则：绝不 --abort，绝不发明新行为。
一次性的项目初始化技能：配置 Issue Tracker（GitHub / GitLab / 本地 Markdown / 其他）、Triage 标签（5 个标准角色的标签字符串）、领域文档布局（单上下文或多上下文）。通过问答驱动，每一步给出推荐值让用户一键确认，不假设、不盲目写。运行完后其他工程类技能（triage、to-spec、to-tickets、implement 等）就可以正常使用。
测试驱动开发技能：定义红-绿-重构循环的规范和边界。规定什么是好测试（通过公共接口验证行为而非实现细节）、测试放在哪里（在预先约定的 seam 处，每轮循环确认一次）、三个反模式（实现耦合、同义反复、水平切片）、以及循环规则（先红后绿、一次一个垂直切片、重构不属于循环内）。不只是一个"先写测试"的提醒，而是完整的 TDD 质量保障参考。
多会话教学技能：将当前目录作为教学空间，基于用户的学习任务（MISSION.md）提供持久化的结构化教学。产出包括 MISSION（学习动机）、reference 参考文档、lessons 课程（自包含 HTML 文件）、learning records（类似 ADR 的知识）、RESOURCES（学习资源）等。教学理念强调"合意困难"——使用检索练习、间隔学习、交错练习来构建存储强度（长期记忆）而非流利度（即时回忆）。
将当前对话内容合成为一份 spec（PRD）并发布到 Issue Tracker 的技能：不进行新的采访，仅基于已有对话内容和代码库理解进行提炼。输出包括 Problem Statement、User Stories（详尽的编号列表）、Implementation Decisions、Testing Decisions、Out of Scope 等标准章节。会先确定测试的 seam 并征得用户同意，然后用模板生成 spec 并打上 ready-for-agent 标签。
将 plan/spec/对话拆解为一组"示踪弹"（tracer bullet）垂直切片 tickets 的技能：每个 ticket 覆盖从 schema 到 UI 到测试的完整路径、独立可演示/可验证、大小适合单次 Agent 上下文窗口、声明阻塞边。支持本地文件或真实 tracker 两种发布方式。宽重构使用"展开→迁移→收缩"模式而非强行垂直切片。发布前会向用户展示拆分方案并确认。
Issue 分类与处理技能：将 issue 和外部 PR 通过一个状态机（needs-triage → needs-info → ready-for-agent/ready-for-human/wontfix）推进，包含分类、验证、grilling（如果需要）和编写 agent-ready brief。遵循严格的角色体系（2 个类别角色 + 5 个状态角色），对每个 issue/PR 做冗余检查、优先级推荐、claim 验证、grilling 精炼，最终输出 agent 可直接使用的 brief 或明确标记为何需要人工处理。
超大工作量导航技能：当从当前状态到目标状态的路径被"迷雾"笼罩、无法一次性看清时，在 Issue Tracker 上绘制一份"共享地图"（shared map）——一组决策 ticket，逐个解决直至路径清晰。每个 ticket 解决一个问题（原型、研究、grilling 或任务），产生的是决策而非交付物。地图不存储内容只做索引，决策存在于各自的 ticket 中。地图的"未定区域"（fog of war）记录尚无法精确描述的问题。
技能编写参考——写和编辑 Agent Skill 的方法论和原则参考技能。定义了技能的可预测性（predictability）为根本追求，详细说明了调用类型选择（user-invoked vs model-invoked）、description 写作、信息层次（in-skill step / in-skill reference / external reference）、拆分策略、剪枝方法、leading words 的使用、以及故障模式（premature completion、duplication、sediment、sprawl、no-op、negation）。技能本身大量使用本技能描述的写作原则来构建。
