Ask Matt 是一个 skill 路由器，解决的问题是：你记不住每个 skill，所以问它该用哪个 skill 或流程。它把仓库中的 skill 组织成若干条路径，并说明每条路径的用途与衔接方式。
用途
它用于在开始工作前判断当前处境应进入哪条流程。核心概念是“流程（flow）”——一条穿过各 skill 的路径。多数路径沿着一条主流走，另有两个入口（on-ramp）并入它；其余是独立 skill，或是在底下跑的词汇层。
主流：点子 → 上线
多数工作走的路线：你有一个点子，想把它造出来。
/grill-with-docs —— 用访谈磨利点子。每当你在一个工作目录里干活，就从这里开始：它有状态，把学到的东西留在 CONTEXT.md 和 ADR 里。没有工作目录时可直接用 /grilling 原语；grill-with-docs 跑的也是这个原语，区别是它会留下书面痕迹。
分支——每个问题都能在对话里敲定吗？如果某个问题需要一个可运行的答案（状态、业务逻辑、一个你得亲眼看的 UI），就绕道做个原型，两个方向都用 /handoff 桥接：/handoff 出去，然后对着那个文件开一个新会话；/prototype 用一次性代码回答问题；/handoff 把学到的东西带回来，并在原来的点子线索里引用它。
分支——这是一个跨会话的构建吗？是 → /to-spec（把线索变成规格），再 /to-tickets 拆成 tracer-bullet 工单，每个声明它的阻塞边。本地 tracker 下是 .scratch/<feature>/issues/ 下每工单一文件，按阻塞优先手工推进；真 tracker 下阻塞边变成原生阻塞链接，任何阻塞已完成的工单都能被认领——每个工单启动一个 /implement，每个之间 /clear 上下文。否 → 就在这里、同一个上下文窗口里 /implement。
无论哪条，/implement 内部驱动 /tdd 来构建每个 issue——一次一个红-绿切片——收尾时在提交前跑一遍 /code-review（对 diff 的两轴评审：规范 + 规格）。想不带完整规格、只以测试先行造一个具体行为时，单独用 /tdd；想针对某个固定点评审一个分支或 PR 时，单独用 /code-review。
上下文卫生
把步骤 1–3 保持在一个不间断的上下文窗口里——直到 /to-tickets 之后才 compact 或 clear——好让质询、规格和工单都建立在同一套思考上。每个 /implement 则从头开始，基于工单干活。这条的上限是 smart zone：模型仍然锐利推理的那个窗口（最先进模型上约 150k token）。如果某次会话在 /to-tickets 之前就逼近它，别在退化中硬撑——在最近的阶段边界 /compact 然后继续。
入口（On-ramps）
一个会产生工作、随后并入主流的起始处境。
bug 和请求在堆积 → /triage。它把 issue 推过分诊角色，产出 agent-ready 的 issue，/implement 后续来接。分诊只用于你不是自己创建的 issue——bug 报告、外部功能请求、任何原样到达的东西。/to-tickets 产出的工单已经是 agent-ready 的，所以不要分诊它们。
有东西坏了 → /diagnosing-bugs。对付难调的那些：一眼看不透的 bug、偶发的 flake、在两个已知良好状态之间悄悄爬进来的回归。它拒绝在拥有一个紧的反馈回路——一条已经能在这个 bug 上变红的命令——之前进行理论化，然后带着回归测试修复。当真正的发现是“没有好的接缝能锁住这个 bug”时，它的复盘会交给 /improve-codebase-architecture。
一个庞大、模糊的工作——一个全新项目或一个巨型功能构建，大到一次会话装不下 → /wayfinder，这里认知要求最高的流程。当从这里到目的地的路还看不见时，它在 issue tracker 上画一张由决策工单组成的共享地图，并一个一个解决它们——产出决策，而非交付物——直到迷雾被推回、路清晰。当地图清晰时，它交班，它不构建：在 /to-spec 并入主流，把地图上相互链接的决策折叠成一份可构建的计划，然后照常 /to-tickets 和 /implement。把地图直接 loop 进 /implement 会跳过那次折叠、丢掉相互链接的细节——只有当这个工作最终证明确实很小时，才直接去 /implement。
代码库健康
不是功能开发——是维护。/improve-codebase-architecture —— 有空就跑一下，保持代码库对 agent 操作友好。它浮现深化的机会；挑一个会产生一个点子，你可以带进主流的 /grill-with-docs。它是找到候选人的勘察；/codebase-design 是你设计选中的那一个的工作台。
底下的词汇
两个 model-invoked 的参考，跑在其他 skill 底下——各自是其词汇的唯一权威。当问题是词、不是流程时，直接用它们；或让上面的 skill 把它们拉进来。
/domain-modeling —— 磨利项目的领域语言：挑战一个模糊的词、解决一个过载的词（“account”兼三份工）、把一个难以撤销的决策记成 ADR。它是 /grill-with-docs 驱动以保持 CONTEXT.md 一份干净词汇表的那门主动纪律。
/codebase-design —— 设计一个模块形状的深模块词汇（module、interface、depth、seam、adapter、leverage、locality）：大量行为藏在一个干净接缝处的小接口背后。/tdd 和 /improve-codebase-architecture 都说它。
阶段边界
一个阶段（phase）是一次会话里的一块工作——质询、实现、QA。在两个阶段之间的边界上你有五个选项：Continue（继续）——待在原地，不花什么，也不丢什么；/clear —— 清空窗口，当下面的东西对接下来无关时；/handoff —— 写一个可移植的 markdown 文件，窄：只为新 harness、新目录、同事，或阶段中 fork 一个支线任务，它买的是可移植性；Subagent（子代理）—— 把一个范围紧密的任务送到它自己的窗口，拿回一份报告；/compact —— 压缩这份上下文并用它播种一次新会话，默认项，在树底而不是第一选择。读 PHASE-BOUNDARIES.md 看有序的决策树——五个问题、每个分支背后的理由、以及为什么一手资料的成本让 Continue 成为要先排除的那一个。决策要在边界上做；阶段中间，继续或把剩下的拆成子代理。
独立 skill
完全不在主流上。
/grilling —— 访谈原语本身：一轮轮、前沿、事实是 agent 的活、决策是你的。/grill-with-docs 是它的具名入口，而 /triage、/wayfinder 和 /improve-codebase-architecture 内部都跑它。只想要这个访谈、不要任何外壳时，直接用它。
/resolving-merge-conflicts —— 逐 hunk 处理一个进行中的 merge 或 rebase 冲突，按追溯到每一侧一手资料的意图解决，而不是挑行，然后完成操作。它从不跑 --abort。独立、不在任何流程上：当你已经处于冲突中间时用它。
/prototype —— 一个小的一次性程序，回答一个设计问题：这个状态模型感觉对吗，或者这个 UI 该长什么样。一次性是对代码怎么写的约束，不是销毁它的承诺：答案折进真实代码，原型本身作为一手资料留在 main 之外的一个 prototype/<name> 分支上，从实现 issue 指向它。它是主流步骤 2 里的绕道，但任何设计问题在纸上难敲定时都可以用它。
/research —— 把阅读苦力活派给一个后台 agent：它针对一手资料调研一个问题，然后在仓库里留下一份带引用的 markdown 文件。它读的时候你继续干活。它产出的文件是带进主流 /grill-with-docs 的东西——研究喂养思考，不替代思考。
/to-questionnaire —— 当挡住你的东西既不在你脑子里也不在代码库里、而在别人那里时，这个给他们写一份问卷来填。它是 /grilling 的反面：不就主题访谈你，而是就寄送访谈你——寄给谁、你要回什么——并把问题对准那个缺口。回来的东西是 /grill-with-docs 或 /to-spec 的素材。
/teach —— 跨多个会话学一个概念，用当前目录作为有状态的工作区。
前提条件
/setup-ouyangjiahong-skills —— 在你的第一次工程流程前跑一次，配置其他 skill 假定的 issue tracker、分诊标签和文档布局。自定义的 issue tracker 也支持。Loop 工具按 harness 另配：Claude Code 跑 /setup-claude-code，pi 跑 /setup-pi。