# Ask Matt

询问哪个技能或流程适合你的情况。本仓库内技能的路由器。

- Repository: https://github.com/devcxl/mattpocock-skills-zh (522 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add devcxl/mattpocock-skills-zh --skill ask-matt -g -a claude-code -y`
Codex: `npx skills add devcxl/mattpocock-skills-zh --skill ask-matt -g -a codex -y`
Cursor: `npx skills add devcxl/mattpocock-skills-zh --skill ask-matt -g -a cursor -y`
Gemini CLI: `npx skills add devcxl/mattpocock-skills-zh --skill ask-matt -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add devcxl/mattpocock-skills-zh`

## Description

询问哪个技能或流程适合你的情况。本仓库内技能的路由器。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Ask Matt

你不必记住每一个技能，所以来问。

在说明某个技能的作用或建议跳过某一步之前，先阅读该技能的 `SKILL.md`：这里的摘要仅用于定位。

**流程（flow）**是穿过技能的一条路径。大多数路径沿一条**主干流程**行进，两条**入口匝道**汇入其中。其余的都是独立技能，或者是在底层运行的词汇层。

## 主干流程：想法 → 交付

大多数工作走的路线。你有一个想法，想把它建出来。

1. **`/grill-with-docs`**：通过盘问打磨想法。只要你在**工作目录**里就从这里开始：它是有状态的，会把学到的东西保存在 `GLOSSARY.md` 和 ADR 中。（没有工作目录？用 `/grill-me`，见"独立技能"。两者跑的是同一个 `/grilling` 原语；`grill-with-docs` 是会留下书面痕迹的那个，所以只要有仓库可以留痕迹，它就是更好的选择。）
2. **分支：所有问题都能在对话中解决吗？** 如果某个问题需要一个可运行的答案（状态、业务逻辑、必须亲眼看到的 UI），就绕道原型，由 **`/handoff`** 双向桥接（原型住在自己的目录里，这正是 `/handoff` 的用武之地，见"阶段边界"）：
   - **`/handoff`** 跳出去，然后针对那个文件开一个新会话，
   - **`/prototype`** 用一次性代码回答问题，
   - **`/handoff`** 把你学到的东西带回来，并在原始想法线程中引用它。
3. **分支：这是多会话构建吗？**
   - **是** → **`/to-spec`**（把对话变成 spec），然后 **`/to-tickets`** 把它拆成示踪子弹式 ticket，每个都声明自己的**阻塞边**。接着用两种方式之一推进 ticket：
     - **`/implement`** 逐个 ticket 实现，**每个之间用 `/clear` 清空上下文**。在本地跟踪器上，每个 ticket 是 `.scratch/<feature>/issues/` 下的一个文件，按阻塞优先的顺序人工推进；在真实跟踪器上，阻塞边变成原生阻塞链接，所以任何阻塞项已完成的 ticket 都可以被领取。每个 ticket 自包含，所以上一个的上下文可以丢弃。
     - **`/implement-spec`** 一次性实现整份 spec。它把 ticket 读成一张**任务图**，在可领取的**前沿**上并行运行实施者子代理，把一切落到一条**集成分支**上。当你更想编排整个构建、而不是亲自逐张驱动 ticket 时用它。
   - **否** → 就在同一个上下文窗口里 **`/implement`**。

   无论哪种方式，代码都靠驱动 **`/tdd`**（一次一个红-绿切片）来构建，并以 **`/code-review`** 收尾，对 diff 做双轴审查（标准 + 规格）。`/implement` 对每张 ticket 各跑一遍这两步；`/implement-spec` 的每个实施者各自驱动 `/tdd`，然后在集成分支上跑一次 `/code-review`。只想在没有完整 spec 的情况下测试优先地构建一个具体行为时，单独用 **`/tdd`**；任何时候想对照固定点审查分支或 PR，单独用 **`/code-review`**。

   当工作要以 PR 提交时，**`/pr`** 负责塑造 PR body：能说清变更的最小可视化、证明其可行的 before/after 证据、以及单向门/双向门的判断。它是模型调用的，所以 agent 每次写 PR 都会主动拿起来用。

4. **`/retro`** 闭合这个循环。一次构建之后（尤其是跑偏的那种），它会回顾整个会话，为 agent 的**环境**（而非代码）提出改动建议：导航指针、自动化检查、`/code-review` 执行的编码规范、引导文件、工具。机械性错误变成确定性检查；判断题变成编码规范。下一次构建就从更好的环境开始。

### 上下文卫生

把步骤 1, 3 保持在**一个不间断的上下文窗口**里（在 `/to-tickets` 之前不要压缩或清空），这样盘问、spec 和 ticket 都建立在同一个思考之上。之后每次 `/implement` 从 ticket 出发、重新开始。在它所回顾的那次会话里、清空之前运行 `/retro`；清空之后，就把它指向那次会话的日志。

The rest: https://github.com/devcxl/mattpocock-skills-zh/blob/HEAD/skills/engineering/ask-matt/SKILL.md