[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71Q66AGFM7REBCQK69M7SS3":3,"skill-same:01M71Q66AGFM7REBCQK69M7SS3":58},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":21,"linkOnly":22,"markdownContent":23,"markdownBody":24,"frontMatter":25,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":30,"repositoryHtmlUrl":31,"repositoryHomepageUrl":32,"ownerHtmlUrl":33,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":34,"install":35,"resources":47},"01M71Q66AGFM7REBCQK69M7SS3","ask-matt",null,"询问当前情境适合哪个技能或流程；它是本仓库所有 skills 的路由器。","vinvcn\u002Fmattpocock-skills-zh-CN","vinvcn","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F120928190?v=4","01M71Q60C4V98DEXHGN2VXFSZB","01M71Q60D6PRAJHKQRY33ZNE59",5797,"MIT","https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fask-matt\u002FSKILL.md",[],[18,19,20],"ask matt","ask","true","2026-11-10 13:02:02",false,"---\nname: ask-matt\ndescription: 询问当前情境适合哪个技能或流程；它是本仓库所有 skills 的路由器。\ndisable-model-invocation: true\n---\n\n# 问 Matt\n\n你不需要记住每个 skill，所以直接问。\n\n在断言某个 skill 做什么、或建议跳过某个步骤之前，先读那个 skill 的 SKILL.md：这里的摘要只用于定向。\n\n**Flow** 是穿过 skills 的一条路径。大多数路径沿着一条 **main flow** 前进，两个 **on-ramps** 会并入它。其他内容要么是 standalone，要么是在下层运行的 vocabulary layer。\n\n## 主流程：idea -> ship\n\n这是大多数工作的路线：你有一个想法，并希望把它构建出来。\n\n1. **`\u002Fgrill-with-docs`** - 通过访谈打磨想法。在 **working directory** 中工作时从这里开始：它是 stateful 的，会把学到的内容保存在 `GLOSSARY.md` 和 ADRs 中。（没有 working directory？用 `\u002Fgrill-me`，见「独立 skills」。两者都运行同一个 `\u002Fgrilling` primitive；`grill-with-docs` 是会留下文档痕迹的版本，只要有 repo 可记录，它就是两者中更好的那个。）\n2. **分支 - 能否在对话中解决所有问题？** 如果某个问题需要可运行的答案（state、business logic，或必须亲眼看到的 UI），就通过 prototype 绕行，并用 **`\u002Fhandoff`** 在两个方向桥接（prototype 住在自己的目录里，这正是 `\u002Fhandoff` 的用途，见「Phase 边界」）：\n   - **`\u002Fhandoff`** 导出，然后基于该文件打开 fresh session；\n   - **`\u002Fprototype`** 用 throwaway code 回答问题；\n   - **`\u002Fhandoff`** 把学到的内容带回来，并在原始 idea thread 中引用它。\n3. **分支 - 这是 multi-session build 吗？**\n   - **是** -> **`\u002Fto-spec`**（把 thread 变成 spec），再用 **`\u002Fto-tickets`** 拆成 tracer-bullet tickets，每个 ticket 声明 **blocking edges**。然后从以下两种方式中选一种来推进这些 tickets：\n     - 逐 ticket 运行 **`\u002Fimplement`**，并在 tickets 之间用 **`\u002Fclear`** 清空 context。Local tracker 在 `.scratch\u002F\u003Cfeature>\u002Fissues\u002F` 下每 ticket 一个文件，手动按 blockers-first 处理；真实 tracker 用 native blocking links，因此 blockers 已完成的 ticket 都可领取。每个 ticket 都是自包含的，因此最后一个 ticket 的 context 可以丢弃。\n     - 用 **`\u002Fimplement-spec`** 一次运行实现整份 spec。它把 tickets 读作 **task graph**，在 ready **frontier** 上并行运行 implementer subagents，并把全部成果落到一条 **integration branch** 上。当你更想编排这次 build、而不是亲自逐个驱动 ticket 时，就选它。\n   - **否** -> 在当前 context window 里直接运行 **`\u002Fimplement`**。\n\n   无论哪种方式，代码都通过驱动 **`\u002Ftdd`** 来构建（一次一个 red-green slice），并用 **`\u002Fcode-review`** 收尾，也就是对 diff 做 Standards + Spec 双轴 review。`\u002Fimplement` 会在每个 ticket 上运行这两者；`\u002Fimplement-spec` 的每个 implementer 各自驱动 `\u002Ftdd`，它再对 integration branch 运行一次 `\u002Fcode-review`。只想在没有完整 spec 的情况下 test-first 构建一个具体 behavior 时，单独用 **`\u002Ftdd`**；想按固定点 review branch 或 PR 时，单独用 **`\u002Fcode-review`**。\n\n   当工作以 pull request 的形式提上去时，**`\u002Fpr`** 负责塑形 PR 正文：展示这次变更的最小 visual、证明它可用的 before\u002Fafter 证据，再加上一次单向门还是双向门的判断。它是 model-invoked 的，所以 agent 每次写 PR 都会伸手用它。\n\n4. **`\u002Fretro`** 闭合循环。一次 build 之后，尤其是一次走了弯路的 build，它会回看整个 session，建议改动 agent 的 **environment**，而不是代码：navigation pointers、automated checks、`\u002Fcode-review` 强制执行的 coding standards、steering files、tooling。机械性错误变成 deterministic checks；judgement calls 变成 coding standards。下一次 build 由此从更好的 environment 出发。\n\n### Context 卫生\n\n步骤 1 到 `\u002Fto-tickets` 要留在 **同一个未中断的 context window** 中；不要 compact 或 clear，这样 grilling、spec 和 tickets 才能建立在同一组思考之上。之后每个 `\u002Fimplement` 都从 fresh session 开始，只基于对应 ticket 工作。在 clear 之前，在被回看的那个 session 里运行 `\u002Fretro`；clear 之后，改为让它读取该 session 的 log。\n\n限制来自 **[smart zone](https:\u002F\u002Fwww.aihero.dev\u002Fai-coding-dictionary\u002Fsmart-zone)**：在该窗口（最新模型大约 150k tokens）内，模型还能保持敏锐推理。如果 session 在 `\u002Fto-tickets` 前接近这个区间，不要硬撑降级状态；在最近的 phase boundary 用 `\u002Fcompact`，然后继续（见「Phase 边界」）。\n\n## 入口匝道\n\n起点会生成工作，然后并入 main flow。\n\n- **Bugs 和 requests 堆积** -> **`\u002Ftriage`**。它通过 triage roles 推进 issues，并产出 agent-ready issues，之后由 **`\u002Fimplement`** 领取。\n\n  Triage 只用于 **不是你创建的** issues：bug reports、incoming feature requests，以及任何原始进入的内容。`\u002Fto-tickets` 产出的 tickets 已经是 agent-ready，不要再 triage。\n\n- **Something's broken** -> **`\u002Fdiagnosing-bugs`**。用于难处理的问题：第一眼看不出的 bug、间歇性 flake、夹在两个 known-good states 之间的 regression。它在拥有 **tight feedback loop** 前拒绝空想，也就是一个已经能在 _这个_ bug 上变红的命令；然后用 regression test 修复。修复到位后，在同一个 session 里运行 **`\u002Fretro`**，追问什么本可以预防这个 bug；如果真正的发现是没有好 seam 能把 bug 锁住，那就是 **`\u002Fimprove-codebase-architecture`** 的工作。\n\n- **巨大而模糊的 effort：greenfield project 或巨大 feature build，一个 session 装不下** -> **`\u002Fwayfinder`**，这是这里认知负担最重的 flow。当从当前位置到 destination 的路还看不见时，它在 issue tracker 上绘制 **decision tickets** 的 **shared map**，逐个解决，产出 **decisions, not deliverables**，直到 fog 被推开、路径清晰。`\u002Fgrill-with-docs` 用于一个 session 能装下的想法，wayfinder 用于装不下的想法；它更慢、更密集，所以只应留给确实如此的 effort，绝不要用于范围明确的 feature。\n\n  Map 清晰后，**它会 hand off，而不是 build**：先进入 **`\u002Fto-spec`**，把 map 中相互链接的 decisions 收束成可构建计划，然后照常使用 `\u002Fto-tickets` 和 `\u002Fimplement`。让 map 直接循环进入 `\u002Fimplement` 会跳过这次收束并丢掉相互链接的细节；只有当 effort 后来发现确实很小时，才直接进入 `\u002Fimplement`。\n\n## Codebase 健康\n\n这不是 feature work，而是维护。\n\n- **`\u002Fimprove-codebase-architecture`** - 有空时运行，保持 codebase 适合 agents 操作。它会暴露 **deepening opportunities**；选择其中一个会生成一个 idea，可以带入 main flow 的 `\u002Fgrill-with-docs`。它负责找候选项；**`\u002Fcodebase-design`**（见下文）是你设计已选候选项时使用的工作台。\n\n## 底层词汇\n\n两个 model-invoked references 在其他 skills 下层运行，分别是自己词汇的 single source of truth。问题在于**词语**而不是流程时直接用它们；也可以让上面的 skills 自动拉起它们。\n\n- **`\u002Fdomain-modeling`** - 打磨项目的 _domain_ language：挑战模糊术语、解决 overloaded word（例如一个 \"account\" 承担三件事）、把难以逆转的决策记录为 ADR。它是 `\u002Fgrill-with-docs` 用来保持 `GLOSSARY.md` glossary 干净的主动纪律。\n- **`\u002Fcodebase-design`** - deep-module vocabulary（module、interface、depth、seam、adapter、leverage、locality），用于设计 module 的 _shape_：把大量 behavior 放在 clean seam 上的小 interface 后面。`\u002Ftdd` 和 `\u002Fimprove-codebase-architecture` 都使用这套语言。\n\n## Phase 边界\n\n**phase** 是 session 内的一段工作：grilling、implementation、QA。在它们之间的 **boundary** 处你有五个选项，而在这整张 map 中，选哪个是最模糊的决定：\n\n- **Continue** - 原地不动。不花成本，也不丢失任何东西。\n- **`\u002Fclear`** - 清空 context window，当这里的内容对接下来什么都不重要时。\n- **`\u002Fhandoff`** - 写一个便携 markdown 文件。范围很窄：只用于 **new harness**、**new directory**、**colleague**，或在 **阶段中途** 分叉一个 side task。它买到的是 portability。\n- **Subagent** - 把 tightly-scoped task 送到它自己的 context window，并拿回一份报告。\n- **`\u002Fcompact`** - 压缩这个 context，并用 summary 播种 fresh session。它是 **default**，位于树的底部，而不是最先伸手可及的地方。\n\n关于有序的树，阅读 [PHASE-BOUNDARIES.md](PHASE-BOUNDARIES.md)：五个问题、每个分支背后的推理，以及为什么 primary-source 成本让 **Continue** 成为第一个要排除的选项。**在** boundary 处做决定；阶段中途，要么继续，要么把剩余的工作拆成 subagents。\n\n## 独立 skills\n\n完全在 main flow 之外。\n\n- **`\u002Fgrill-me`** - 与 `\u002Fgrill-with-docs` 一样的持续访谈，但 **stateless**：不在本地保存任何内容，也不构建 `GLOSSARY.md`。当你 **不在 working directory** 中工作时使用它：打磨一个计划、一个设计、一段文字，任何没有 repo 承载的东西。如果你在 working directory 中，改用 `\u002Fgrill-with-docs`：它运行同样的访谈并留下文档痕迹，因此严格来说是更好的选择。\n- **`\u002Fgrilling`** - 访谈 primitive 本身：rounds、frontier，facts 是 agent 的工作，decisions 是你的。`\u002Fgrill-me` 和 `\u002Fgrill-with-docs` 是两个命名的入口，`\u002Ftriage`、`\u002Fwayfinder` 和 `\u002Fimprove-codebase-architecture` 都在内部运行它。只有在你想要不带任何 wrapper 的访谈时才直接使用它。\n- **`\u002Fprototype`** - 一个小型 throwaway program，用来回答一个设计问题：这个 state model 感觉对吗，或者这个 UI 应该是什么样。Throwaway 是对代码编写方式的约束，而不是销毁它的承诺：答案会折进真实代码，prototype 本身则作为 **primary source** 保留在 main 之外的 `prototype\u002F\u003Cname>` branch 上，并由 implementation issue 指向。它是 main flow 第 2 步的绕行，但任何难以纸面解决的 design question 都可以直接用它。\n- **`\u002Fresearch`** - 把阅读工作委托给 **background agent**：它对照 **primary sources** 调研问题，然后在 repo 中留下带引用的 Markdown 文件。你可以在它阅读时继续工作。产物应带入 `\u002Fgrill-with-docs` 的 main flow；research 提供思考材料，但不取代思考。\n- **`\u002Fto-questionnaire`** - 当阻塞你的东西不在你的头脑或 codebase 里，而在 **别人的** 头脑里时，这个 skill 会写一份问卷让他们填写。它是 `\u002Fgrill-me` 的反向：它不访问你关于 subject，而是访问你关于 **send**（发给谁、你需要拿回什么），并把问题对准 gap。拿回来的东西是 `\u002Fgrill-with-docs` 或 `\u002Fto-spec` 的素材。\n- **`\u002Fwizard`** - 用于只有 **human** 能完成的步骤：provisioning infrastructure、设置 credentials 或 CI secrets、在陌生的第三方 dashboard 中点击操作、运行一次性 migration 或 cutover。它生成一个交互式 bash script，打开每个 URL、捕获每个值，并写入 `.env` 和 GitHub secrets，这样该过程就不再需要你每次向 agent 重新解释。它是 model-invoked 的，所以 agent 一遇到只有你能通过的墙就会伸手够它。如果 agent 自己能做，它就应该自己做；这个 skill 用于 human 真正在 loop 中的场景。\n- **`\u002Fwait-what`** - 对没有落地的消息的纠正。在对话中途、任何其他 skill 内部使用它，agent 会用你缺失的 context、以平实的语言、用 `GLOSSARY.md` vocabulary 重新表述它刚说的话。它事后生效；`\u002Fgrill-with-docs` 是前置的解法，因为早早就共同约定的共享语言才是阻止 jargon 出现的根本。\n- **`\u002Fteach`** - 使用当前目录作为 stateful workspace，跨多个 sessions 学习一个概念。\n- **`\u002Fwriting-for-agents`** - 编写 agents 消费的文档的 reference：skills、AGENTS.md、被指向的 docs。\n\n## 前置条件\n\n**`\u002Fsetup-matt-pocock-skills`** - 第一次运行 engineering flow 前先执行，用来配置其他 skills 所依赖的 issue tracker、triage labels 和 docs layout。自定义 issue trackers 也可以。\n","# 问 Matt\n\n你不需要记住每个 skill，所以直接问。\n\n在断言某个 skill 做什么、或建议跳过某个步骤之前，先读那个 skill 的 SKILL.md：这里的摘要只用于定向。\n\n**Flow** 是穿过 skills 的一条路径。大多数路径沿着一条 **main flow** 前进，两个 **on-ramps** 会并入它。其他内容要么是 standalone，要么是在下层运行的 vocabulary layer。\n\n## 主流程：idea -> ship\n\n这是大多数工作的路线：你有一个想法，并希望把它构建出来。\n\n1. **`\u002Fgrill-with-docs`** - 通过访谈打磨想法。在 **working directory** 中工作时从这里开始：它是 stateful 的，会把学到的内容保存在 `GLOSSARY.md` 和 ADRs 中。（没有 working directory？用 `\u002Fgrill-me`，见「独立 skills」。两者都运行同一个 `\u002Fgrilling` primitive；`grill-with-docs` 是会留下文档痕迹的版本，只要有 repo 可记录，它就是两者中更好的那个。）\n2. **分支 - 能否在对话中解决所有问题？** 如果某个问题需要可运行的答案（state、business logic，或必须亲眼看到的 UI），就通过 prototype 绕行，并用 **`\u002Fhandoff`** 在两个方向桥接（prototype 住在自己的目录里，这正是 `\u002Fhandoff` 的用途，见「Phase 边界」）：\n   - **`\u002Fhandoff`** 导出，然后基于该文件打开 fresh session；\n   - **`\u002Fprototype`** 用 throwaway code 回答问题；\n   - **`\u002Fhandoff`** 把学到的内容带回来，并在原始 idea thread 中引用它。\n3. **分支 - 这是 multi-session build 吗？**\n   - **是** -> **`\u002Fto-spec`**（把 thread 变成 spec），再用 **`\u002Fto-tickets`** 拆成 tracer-bullet tickets，每个 ticket 声明 **blocking edges**。然后从以下两种方式中选一种来推进这些 tickets：\n     - 逐 ticket 运行 **`\u002Fimplement`**，并在 tickets 之间用 **`\u002Fclear`** 清空 context。Local tracker 在 `.scratch\u002F\u003Cfeature>\u002Fissues\u002F` 下每 ticket 一个文件，手动按 blockers-first 处理；真实 tracker 用 native blocking links，因此 blockers 已完成的 ticket 都可领取。每个 ticket 都是自包含的，因此最后一个 ticket 的 context 可以丢弃。\n     - 用 **`\u002Fimplement-spec`** 一次运行实现整份 spec。它把 tickets 读作 **task graph**，在 ready **frontier** 上并行运行 implementer subagents，并把全部成果落到一条 **integration branch** 上。当你更想编排这次 build、而不是亲自逐个驱动 ticket 时，就选它。\n   - **否** -> 在当前 context window 里直接运行 **`\u002Fimplement`**。\n\n   无论哪种方式，代码都通过驱动 **`\u002Ftdd`** 来构建（一次一个 red-green slice），并用 **`\u002Fcode-review`** 收尾，也就是对 diff 做 Standards + Spec 双轴 review。`\u002Fimplement` 会在每个 ticket 上运行这两者；`\u002Fimplement-spec` 的每个 implementer 各自驱动 `\u002Ftdd`，它再对 integration branch 运行一次 `\u002Fcode-review`。只想在没有完整 spec 的情况下 test-first 构建一个具体 behavior 时，单独用 **`\u002Ftdd`**；想按固定点 review branch 或 PR 时，单独用 **`\u002Fcode-review`**。\n\n   当工作以 pull request 的形式提上去时，**`\u002Fpr`** 负责塑形 PR 正文：展示这次变更的最小 visual、证明它可用的 before\u002Fafter 证据，再加上一次单向门还是双向门的判断。它是 model-invoked 的，所以 agent 每次写 PR 都会伸手用它。\n\n4. **`\u002Fretro`** 闭合循环。一次 build 之后，尤其是一次走了弯路的 build，它会回看整个 session，建议改动 agent 的 **environment**，而不是代码：navigation pointers、automated checks、`\u002Fcode-review` 强制执行的 coding standards、steering files、tooling。机械性错误变成 deterministic checks；judgement calls 变成 coding standards。下一次 build 由此从更好的 environment 出发。\n\n### Context 卫生\n\n步骤 1 到 `\u002Fto-tickets` 要留在 **同一个未中断的 context window** 中；不要 compact 或 clear，这样 grilling、spec 和 tickets 才能建立在同一组思考之上。之后每个 `\u002Fimplement` 都从 fresh session 开始，只基于对应 ticket 工作。在 clear 之前，在被回看的那个 session 里运行 `\u002Fretro`；clear 之后，改为让它读取该 session 的 log。\n\n限制来自 **[smart zone](https:\u002F\u002Fwww.aihero.dev\u002Fai-coding-dictionary\u002Fsmart-zone)**：在该窗口（最新模型大约 150k tokens）内，模型还能保持敏锐推理。如果 session 在 `\u002Fto-tickets` 前接近这个区间，不要硬撑降级状态；在最近的 phase boundary 用 `\u002Fcompact`，然后继续（见「Phase 边界」）。\n\n## 入口匝道\n\n起点会生成工作，然后并入 main flow。\n\n- **Bugs 和 requests 堆积** -> **`\u002Ftriage`**。它通过 triage roles 推进 issues，并产出 agent-ready issues，之后由 **`\u002Fimplement`** 领取。\n\n  Triage 只用于 **不是你创建的** issues：bug reports、incoming feature requests，以及任何原始进入的内容。`\u002Fto-tickets` 产出的 tickets 已经是 agent-ready，不要再 triage。\n\n- **Something's broken** -> **`\u002Fdiagnosing-bugs`**。用于难处理的问题：第一眼看不出的 bug、间歇性 flake、夹在两个 known-good states 之间的 regression。它在拥有 **tight feedback loop** 前拒绝空想，也就是一个已经能在 _这个_ bug 上变红的命令；然后用 regression test 修复。修复到位后，在同一个 session 里运行 **`\u002Fretro`**，追问什么本可以预防这个 bug；如果真正的发现是没有好 seam 能把 bug 锁住，那就是 **`\u002Fimprove-codebase-architecture`** 的工作。\n\n- **巨大而模糊的 effort：greenfield project 或巨大 feature build，一个 session 装不下** -> **`\u002Fwayfinder`**，这是这里认知负担最重的 flow。当从当前位置到 destination 的路还看不见时，它在 issue tracker 上绘制 **decision tickets** 的 **shared map**，逐个解决，产出 **decisions, not deliverables**，直到 fog 被推开、路径清晰。`\u002Fgrill-with-docs` 用于一个 session 能装下的想法，wayfinder 用于装不下的想法；它更慢、更密集，所以只应留给确实如此的 effort，绝不要用于范围明确的 feature。\n\n  Map 清晰后，**它会 hand off，而不是 build**：先进入 **`\u002Fto-spec`**，把 map 中相互链接的 decisions 收束成可构建计划，然后照常使用 `\u002Fto-tickets` 和 `\u002Fimplement`。让 map 直接循环进入 `\u002Fimplement` 会跳过这次收束并丢掉相互链接的细节；只有当 effort 后来发现确实很小时，才直接进入 `\u002Fimplement`。\n\n## Codebase 健康\n\n这不是 feature work，而是维护。\n\n- **`\u002Fimprove-codebase-architecture`** - 有空时运行，保持 codebase 适合 agents 操作。它会暴露 **deepening opportunities**；选择其中一个会生成一个 idea，可以带入 main flow 的 `\u002Fgrill-with-docs`。它负责找候选项；**`\u002Fcodebase-design`**（见下文）是你设计已选候选项时使用的工作台。\n\n## 底层词汇\n\n两个 model-invoked references 在其他 skills 下层运行，分别是自己词汇的 single source of truth。问题在于**词语**而不是流程时直接用它们；也可以让上面的 skills 自动拉起它们。\n\n- **`\u002Fdomain-modeling`** - 打磨项目的 _domain_ language：挑战模糊术语、解决 overloaded word（例如一个 \"account\" 承担三件事）、把难以逆转的决策记录为 ADR。它是 `\u002Fgrill-with-docs` 用来保持 `GLOSSARY.md` glossary 干净的主动纪律。\n- **`\u002Fcodebase-design`** - deep-module vocabulary（module、interface、depth、seam、adapter、leverage、locality），用于设计 module 的 _shape_：把大量 behavior 放在 clean seam 上的小 interface 后面。`\u002Ftdd` 和 `\u002Fimprove-codebase-architecture` 都使用这套语言。\n\n## Phase 边界\n\n**phase** 是 session 内的一段工作：grilling、implementation、QA。在它们之间的 **boundary** 处你有五个选项，而在这整张 map 中，选哪个是最模糊的决定：\n\n- **Continue** - 原地不动。不花成本，也不丢失任何东西。\n- **`\u002Fclear`** - 清空 context window，当这里的内容对接下来什么都不重要时。\n- **`\u002Fhandoff`** - 写一个便携 markdown 文件。范围很窄：只用于 **new harness**、**new directory**、**colleague**，或在 **阶段中途** 分叉一个 side task。它买到的是 portability。\n- **Subagent** - 把 tightly-scoped task 送到它自己的 context window，并拿回一份报告。\n- **`\u002Fcompact`** - 压缩这个 context，并用 summary 播种 fresh session。它是 **default**，位于树的底部，而不是最先伸手可及的地方。\n\n关于有序的树，阅读 [PHASE-BOUNDARIES.md](PHASE-BOUNDARIES.md)：五个问题、每个分支背后的推理，以及为什么 primary-source 成本让 **Continue** 成为第一个要排除的选项。**在** boundary 处做决定；阶段中途，要么继续，要么把剩余的工作拆成 subagents。\n\n## 独立 skills\n\n完全在 main flow 之外。\n\n- **`\u002Fgrill-me`** - 与 `\u002Fgrill-with-docs` 一样的持续访谈，但 **stateless**：不在本地保存任何内容，也不构建 `GLOSSARY.md`。当你 **不在 working directory** 中工作时使用它：打磨一个计划、一个设计、一段文字，任何没有 repo 承载的东西。如果你在 working directory 中，改用 `\u002Fgrill-with-docs`：它运行同样的访谈并留下文档痕迹，因此严格来说是更好的选择。\n- **`\u002Fgrilling`** - 访谈 primitive 本身：rounds、frontier，facts 是 agent 的工作，decisions 是你的。`\u002Fgrill-me` 和 `\u002Fgrill-with-docs` 是两个命名的入口，`\u002Ftriage`、`\u002Fwayfinder` 和 `\u002Fimprove-codebase-architecture` 都在内部运行它。只有在你想要不带任何 wrapper 的访谈时才直接使用它。\n- **`\u002Fprototype`** - 一个小型 throwaway program，用来回答一个设计问题：这个 state model 感觉对吗，或者这个 UI 应该是什么样。Throwaway 是对代码编写方式的约束，而不是销毁它的承诺：答案会折进真实代码，prototype 本身则作为 **primary source** 保留在 main 之外的 `prototype\u002F\u003Cname>` branch 上，并由 implementation issue 指向。它是 main flow 第 2 步的绕行，但任何难以纸面解决的 design question 都可以直接用它。\n- **`\u002Fresearch`** - 把阅读工作委托给 **background agent**：它对照 **primary sources** 调研问题，然后在 repo 中留下带引用的 Markdown 文件。你可以在它阅读时继续工作。产物应带入 `\u002Fgrill-with-docs` 的 main flow；research 提供思考材料，但不取代思考。\n- **`\u002Fto-questionnaire`** - 当阻塞你的东西不在你的头脑或 codebase 里，而在 **别人的** 头脑里时，这个 skill 会写一份问卷让他们填写。它是 `\u002Fgrill-me` 的反向：它不访问你关于 subject，而是访问你关于 **send**（发给谁、你需要拿回什么），并把问题对准 gap。拿回来的东西是 `\u002Fgrill-with-docs` 或 `\u002Fto-spec` 的素材。\n- **`\u002Fwizard`** - 用于只有 **human** 能完成的步骤：provisioning infrastructure、设置 credentials 或 CI secrets、在陌生的第三方 dashboard 中点击操作、运行一次性 migration 或 cutover。它生成一个交互式 bash script，打开每个 URL、捕获每个值，并写入 `.env` 和 GitHub secrets，这样该过程就不再需要你每次向 agent 重新解释。它是 model-invoked 的，所以 agent 一遇到只有你能通过的墙就会伸手够它。如果 agent 自己能做，它就应该自己做；这个 skill 用于 human 真正在 loop 中的场景。\n- **`\u002Fwait-what`** - 对没有落地的消息的纠正。在对话中途、任何其他 skill 内部使用它，agent 会用你缺失的 context、以平实的语言、用 `GLOSSARY.md` vocabulary 重新表述它刚说的话。它事后生效；`\u002Fgrill-with-docs` 是前置的解法，因为早早就共同约定的共享语言才是阻止 jargon 出现的根本。\n- **`\u002Fteach`** - 使用当前目录作为 stateful workspace，跨多个 sessions 学习一个概念。\n- **`\u002Fwriting-for-agents`** - 编写 agents 消费的文档的 reference：skills、AGENTS.md、被指向的 docs。\n\n## 前置条件\n\n**`\u002Fsetup-matt-pocock-skills`** - 第一次运行 engineering flow 前先执行，用来配置其他 skills 所依赖的 issue tracker、triage labels 和 docs layout。自定义 issue trackers 也可以。\n",{"name":5,"description":7,"disable-model-invocation":26},true,"main","c5c5e87cc1df26aeb7dba345ad9f846434d2b3d4","skills\u002Fengineering\u002Fask-matt",450,"https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN","https:\u002F\u002Fskills.sh\u002Fvinvcn\u002Fmattpocock-skills-zh-CN","https:\u002F\u002Fgithub.com\u002Fvinvcn","2026-11-10 17:40:42",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":26},[37,40,43],{"tool":38,"command":39},"npx","npx skills add vinvcn\u002Fmattpocock-skills-zh-CN --skill ask-matt",{"tool":41,"command":42},"bunx","bunx skills add vinvcn\u002Fmattpocock-skills-zh-CN --skill ask-matt",{"tool":44,"command":45},"pnpm","pnpm dlx skills add vinvcn\u002Fmattpocock-skills-zh-CN --skill ask-matt","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fask-matt\u002FSKILL.md",[48,54],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"agents\u002Fopenai.yaml","REFERENCE","参考文档",139,"https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fask-matt\u002Fagents\u002Fopenai.yaml",{"path":55,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":56,"sourceHtmlUrl":57},"PHASE-BOUNDARIES.md",4354,"https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fask-matt\u002FPHASE-BOUNDARIES.md",[59,83,92,102,112,121],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":78,"publishedAt":21},"01M71Q8F3M8YFP6WYVYQP61KBT","writing-for-agents","为 agent 编写文档。适用于创建或编辑 skills，或修改 AGENTS.md 或 CLAUDE.md 时。","https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fwriting-for-agents\u002FSKILL.md",[65,70,73],{"categoryNo":66,"categoryName":67,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":71,"categoryName":72,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[79,80,81,82],"for","writing for agents","writing","文档",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":21},"01M71Q8DHRPYE6R648CQ7NAHYN","wait-what","停一下：刚才那条消息没有说清楚，重新表述一遍。","https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fwait-what\u002FSKILL.md",[],[90,91,20],"wait","wait what",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":21},"01M71Q8C8CBSRJRP8Y0JRZ7RJ7","to-questionnaire","把你无法完整回答的 decision 转成一份交给他人填写的 questionnaire。","https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fto-questionnaire\u002FSKILL.md",[],[99,100,101,20],"questionnaire","to questionnaire","decision",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":111,"publishedAt":21},"01M71Q8ASS9A6P84PSC02YFKHB","teach","在这个工作区中教用户一个新技能或概念。","https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fteach\u002FSKILL.md",[108],{"categoryNo":109,"categoryName":110,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000039","教师与教育",[104,20],{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":21},"01M71Q89C2C2QRR3J3H64ZKH0P","handoff","把当前对话压缩成交接文档，让另一个代理接手。","https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fhandoff\u002FSKILL.md",[],[114,20,119,120,82],"对话","压缩",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":21},"01M71Q883CXWF0BGDQC3Y8TJZ2","grilling","围绕计划、decision 或 idea 持续追问用户。适用于用户想对自己的思路做压力测试，或使用任何 “grill” 触发措辞时。","https:\u002F\u002Fgithub.com\u002Fvinvcn\u002Fmattpocock-skills-zh-CN\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrilling\u002FSKILL.md",[],[123,128,129,101,130],"idea","grill","testing"]