入门：5 分钟上手

目标：让你今天就能正确走完一次主流程，不踩最常见的坑。本层只讲主干 80%，专科工具（/triage、/wayfinder、/handoff…）留给熟练。

上一篇：总览 · 下一篇：熟练

正向：最小可用路径

绝大部分工作走这一条就够：

1. /grill-with-docs   把想法磨清楚，共识写进 CONTEXT.md
2. /implement         按方案实现（内部自动 /tdd，收尾自动 /code-review）

只有当工作大到一次 session 干不完时，中间插一刀：

1. /grill-with-docs
2. /to-spec    ──> 把讨论固化成规格
3. /to-tickets ──> 拆成带阻塞边的独立 ticket
4. 逐个 /implement（每做完一个 /clear，从干净 context 接下一个）

就这样。入门阶段你只需要这张图。

反向：5 种日常情境 → 指令

记不住没关系。一句话：在仓库里，从 /grill-with-docs 开始几乎总没错；出 bug 才换 /diagnosing-bugs，想”体检回归”就用 /code-review。

例子：打磨一条过时的代码规范

架构师日常：发现规范里有条约定过时了、或 AI 老是读偏，走一遍主流程。

第 1 步 — /grill-with-docs：磨清楚再动手

你说：“CLAUDE.md 里那条约定过时了，得改。” skill 不会立刻改文件，而是盘问你：

• 到底是哪一条？现象是什么 —— AI 读了照做错？人看着费解？和实际工具链矛盾？
• 改成什么？新约定的边界在哪？有没有反例？
• 会不会和别处的约定冲突？要不要顺手统一术语？（→ 调用 /domain-modeling 写进术语表）
• 谁消费这条规范？给人看还是给 AI 看？（这决定写法，见第 2 步）

你拍板，它记录。磨完你手里有一份清楚的改法，而不是”感觉不对就动手”。

第 2 步 — /implement：按方案落地

它改 CLAUDE.md / .ai/repo-wiki/ 里对应那一段。因为规范文档是给 AI 消费的，收尾会用 /writing-for-agents 的视角检查：重点是否前置、是否可指向、AI 是否抓得准。

• 若这次规范改动带代码（比如顺带调一条 oxlint 规则、改 oxfmt 配置），/implement 会触发 /tdd（先写期望的 lint 行为）+ /code-review（Standards + Spec 双轴）；
• 若纯文档改动，/tdd 跳过，/code-review 仍按 Spec 轴核对”改的内容是不是第 1 步定的”。

然后 pnpm format → lint → typecheck → build 验证不破，提交。

这就是一次完整的主流程 —— 哪怕”实现”只是改几行规范。

入门三原则（贴墙）

1. 在仓库里，永远从 /grill-with-docs 起 —— 不要直接 /implement。先磨清楚再写，比写完返工便宜得多。
2. 别在糊掉的 context 里硬撑 —— 跑着跑着感觉 AI 开始丢线索、绕圈子，就到边界 /compact 或 /clear，别硬扛。
3. 小改直接做 —— 改错别字、调一句文案，不用走流程。skills 是补短板的，没短板不补。

起步只需要 5 个指令

/grill-with-docs   想法 → 清楚方案
/implement         方案 → 代码（内含 /tdd + /code-review）
/tdd               想单独「测试驱动」某个行为时
/code-review       想单独审查一段 diff 时
/diagnosing-bugs   东西坏了

会这 5 个，你已覆盖日常 80%。剩下的交给熟练。

上一篇：总览 · 下一篇：熟练：全貌、价值表与判断 →