熟练：全貌、价值表与判断
目标：你已走过主流程，现在要看清整张地图、知道每个指令何时用何时别用。本层信息密度高、表格化，适合按需查阅。
正向：完整流程拓扑
主线 + 三条 on-ramp + 健康循环
【主线 idea → ship】
想法 ──>/grill-with-docs──> (单session) /implement
或
(多session) /to-spec ──>/to-tickets──> 逐个 /implement（每个之间 /clear）
【三条 on-ramp，各从不同起点汇入主线】
别人的原始 bug/需求 ──────>/triage ─────────────┐
东西坏了 ─────────────────>/diagnosing-bugs ────┼──> 汇入主线（产出 issue / 方案）
大雾项目（路完全看不见）──>/wayfinder ──>/to-spec┘
【健康循环，独立运转，产出喂回主线】
空闲 ──>/improve-codebase-architecture ──> 想法 ──> 回 /grill-with-docs要点：
- 主线只有一条。三条 on-ramp 不是并行的路，而是从不同情境汇入主线的入口。
/wayfinder产出的是决策，不是交付物；雾散了必须经/to-spec折叠成计划，不能直接/implement。/improve-codebase-architecture是循环的起点：它找”深化机会”，挑一个就生成一个想法，带这个想法回到主线开头。
Context 卫生纪律（熟练者的第一习惯）
| 阶段 | context 策略 |
|---|---|
/grill-with-docs → /to-spec → /to-tickets | 一个连续不中断的窗口，不中途 /clear、不中途 /compact |
每个 /implement | 从干净 context 开始，只读 ticket；ticket 自包含，上一个用完即弃 |
| 接近 smart zone（~150k） | 到 phase boundary 再 /compact，绝不在 phase 中途压 |
为什么？因为 /to-tickets 产出的 ticket 必须建立在完整推理之上；而每个 /implement 只需要 ticket 这一个自包含输入 —— 上一段 context 用完即可抛弃，这正是把大任务拆成 tracer-bullet 的意义。完整的边界决策树见深入。
反向：完整价值表
用这把尺子理解每一行：“不走它，直接对话/直接写代码会怎样？” 暴露的缺陷就是它的价值。触发点 = 何时非它不可；反模式 = 怎么用错。
① 把”模糊想法”变清楚（想清楚 + 留痕）
| 指令 | 价值（补什么短板） | 触发点 | 反模式 |
|---|---|---|---|
/grill-with-docs | 强制盘问逼你拍板，共识沉淀进 CONTEXT.md/ADR | 在 repo 里做任何非琐碎改动 | 当聊天，没做决策就放行 |
/grill-me | 同上，但无状态、无 repo（磨写作/计划） | 不在 working directory 里 | 在 repo 里用它（丢了留痕） |
/grilling | 盘问原语本身，不带任何包装 | 只想要纯粹访谈 | 想留痕却用它（它不写 CONTEXT.md） |
/domain-modeling | 磨领域语言、把硬决策记成 ADR | 术语含糊 / 一词多义 | 记了 ADR 却不引用、不更新 |
/wait-what | 用 CONTEXT.md 词汇把一条没接住的消息重讲 | AI 蹦术语、你懵了 | 事前不建共享语言（该用 grill） |
② 把”清楚的东西”固化成任务
| 指令 | 价值 | 触发点 | 反模式 |
|---|---|---|---|
/to-spec | 把易逝对话固化成可构建规格 | 多 session 大任务 | 单 session 小改也走（过度流程化） |
/to-tickets | 切成 tracer-bullet、自带阻塞边的 ticket | spec 太大、要多人/多 session | 把产出的 ticket 再送 /triage |
/triage | 把别人报来的原始 bug/需求加工成 issue | 处理你没创建的原始报告 | 用于 /to-tickets 产出（已 ready） |
③ 把任务干出来 + 守质量
| 指令 | 价值 | 触发点 | 反模式 |
|---|---|---|---|
/implement | 按 spec/ticket 实现，内含 tdd+code-review | 方案清楚、要落地 | 没磨清楚就直接 implement |
/tdd | 一次一个红绿切片，用行为测试锚定 | 单独想测试驱动某行为 | 绿了之后一次重构一大坨 |
/code-review | Standards + Spec 双轴客观审查 diff | 提交前 / PR / 审分支 | 只看 Standards 不看 Spec（跑题没人发现） |
/prototype | 用一次性代码回答纸面难定的设计问题 | 聊天里对状态/UI 说不清 | 当正式代码写、加测试/抽象 |
④ 出事 / 迷路
| 指令 | 价值 | 触发点 | 反模式 |
|---|---|---|---|
/diagnosing-bugs | 先建紧反馈回路（复现命令）再修，带回归测试 | 难 bug / 间歇 flake / 回归 | 没复现就猜根因乱改 |
/wayfinder | 大雾项目里产出决策 ticket 推雾 | 绿地 / 超大功能、路看不见 | 范围清楚的功能用它（又慢又重） |
/resolving-merge-conflicts | 逐 hunk 按意图解冲突，永不 --abort | 正在 merge/rebase 冲突 | 机械挑行丢语义 |
⑤ 长期健康 + 外部信息
| 指令 | 价值 | 触发点 | 反模式 |
|---|---|---|---|
/improve-codebase-architecture | 主动找”深化”机会，产出想法喂回 grill | 空闲、想清技术债 | 找一堆却不挑优先级 |
/codebase-design | 深模块设计词汇（module/depth/seam） | 设计/改善模块形状 | 当文档读而不在动手时用 |
/research | 后台 agent 读原始资料、留带引用 md，边干边等 | 不想浪费主 context 阅读 | 结果不复核就当事实（它是 secondary） |
/to-questionnaire | 答案在别人脑里时，写问卷去问 | 关键信息在第三方 | 自己能查到的也去烦人 |
/writing-for-agents | 写给 AI 消费的文档（skills / CLAUDE.md / repo-wiki）的参考 | 打磨规范 / 写 skill / 改 AGENTS.md | 按”写给人看”的方式写（AI 抓不到重点） |
⑥ 协作卡点 + 基础设施
| 指令 | 价值 | 触发点 | 反模式 |
|---|---|---|---|
/handoff | 写可移植 md，跨 harness/目录/同事交接 | 要换 session/换人/换目录 | 同 session 内用（没必要） |
/wizard | 把只有人能做的步骤做成交互式 bash | 配密钥/过陌生后台/迁移 | agent 能自己做的也用 |
/teach | 跨多 session 学概念，目录当工作区 | 系统学某概念 | 一次性问答也用 |
/setup-matt-pocock-skills | 前置配置 tracker/labels/doc 布局 | 第一次用前 | 跳过它导致其他 skill 假设落空 |
例子：六个架构师高频场景
① 写周报：把一周散乱工作磨成有价值的叙述
一周的 commit / diff / 回修记录是原始材料，直接堆就是流水账。
/research—— 后台 agent 汇总本周所有 commit、diff、回修，按”设计 vs 代码”拆分工作量，留一份结构化 md。补”不想在主 context 手翻一周 git log”。/grill-with-docs—— 在 repo 内、按CONTEXT.md约定把材料磨成双用途叙述，并维护这份约定（术语 / 标签 / 项目简写改进时更新它）。纯一次性、无 repo 的写作才退到/grill-me。- 别用
/to-spec//to-tickets—— 那是为多 session 工程构建设计的，周报是写作不是构建。 - 边界：格式约定住在
CONTEXT.md里，skills 负责遵守和维护它，不发明格式。 - 批量多期：见案例 · 周报打磨。
② 回归影响分析：这次改动有没有破坏以前的行为
架构师守门动作：固定一个基线，审 since 该基线的全部 diff。
/code-review—— 固定基线（commit / tag / merge-base / 分支），跑两个并行 subagent：Standards（规范）+ Spec（意图）。Spec 轴正是抓”是否偏离 / 破坏了原有行为”的那一个 —— 回归分析主要靠它。- 若 Spec 审查发现可疑回归 → 转
/diagnosing-bugs：先逼出一条复现命令，确认是否真回归，再修 + 补回归测试。 - 判断点：还没发现 bug、只想”体检” →
/code-review；已观察到某行为坏了 →/diagnosing-bugs。
③ 规范打磨改进：开发规范 / 代码规范的持续维护
规范会自然腐化：新约定没写进、旧约定过时、AI 读了抓不到重点。
/improve-codebase-architecture—— 空闲巡检，找”深化机会”和”约定缺失 / 不一致”，产出想法（不直接改）。- 挑出的想法 →
/grill-with-docs磨成具体改法（改什么、为什么、影响哪些）。 - 落地改
CLAUDE.md/.ai/repo-wiki/时 →/writing-for-agents：这些文档是给 AI 消费的，要按”重点前置、可指向、AI 抓得准”来写，不能按”写给人看”的来写。 /domain-modeling—— 顺手统一规范里的术语。- 闭环：这是健康循环 —— 巡检 → 想法 → 主线 → 沉淀进规范 → 下一轮巡检。
④ 多 session 大功能
比如”把整站搜索换成自建方案”。/grill-with-docs 磨范围 → /to-spec 固化 → /to-tickets 拆（索引器 / 前端组件 / 构建钩子各自带阻塞边）→ 逐个 /implement，中间 /clear。
⑤ 概念 / 术语对齐
全站”组件 / 部件 / 模块”混用 → /domain-modeling 把每个词的边界定死，写进 CONTEXT.md 术语表。
⑥ 模块形状 / 状态模型拿不准
新模块接口该多深？某个状态机对不对？聊天里说不清 → /prototype 跑一次性验证（逻辑用单 HTML，UI 用多变体），并用 /codebase-design 的词汇（deep module / seam / depth）讨论它的形状。看准了把决策折进真实代码，原型留在 prototype/<name> 分支当 primary source。
实战：把现成提示词改造成 skills flow
两个真实案例已独立成篇，便于反复研读。共同心法：事实收集丢
/research后台、磨叙述走 grill、验收用原带清单。
- 案例 · 版本测试手册（
test-00.md）—— 单体大提示词如何拆 phase；第三层即/code-review双轴。 - 案例 · 周报打磨（
plan-01.md）—— 批量任务的 context 黑洞；约定解耦 +/grill-with-docs维护CONTEXT.md。
常见困境：/grill-with-docs 问了几十个问题怎么办
详见常见困境。一句话：你只为决策买单，事实让 agent 掏；磨够就固化，任务大就先拆。
反模式清单（致命的几条）
- ❌ 没磨清楚就
/implement—— 跑题没人发现，返工最贵。 - ❌ 把
/to-tickets产出再送/triage—— 已 agent-ready，重复加工。 - ❌ 用
/wayfinder对付范围清楚的功能 —— 又慢又重，留给真正的大雾。 - ❌ 把
/prototype当正式代码 —— 加测试、加抽象、加错误处理，全错；它就是一次性的。 - ❌ 在 phase 中途
/compact—— 丢线索；只在 phase boundary 压。 - ❌ 只跑
/code-review的 Standards 轴 —— Spec 轴才是抓”跑题”的，丢了等于没审。 - ❌
/research的结果不复核就当事实 —— 它产的是 secondary source，关键决策要回查 primary。