1. /grill-me（无代码库）与 /grill-with-docs（有代码库）#

用途： 在动手之前与 AI 达成共识，防止 AI 用默认假设替你做了你不想要的决定。

底层驱动： 两个 Skill 都调用共享的 /grilling 原语。

核心规则（来自 /grilling SKILL.md）：

• 一次只问一个问题，等待你回答后再继续
• AI 会无情地采访你关于计划的每个细节
• 遍历决策树的每个分支，逐个解决依赖关系
• 每个问题 AI 都会提供推荐的答案
• 如果事实可以从环境（文件系统、工具）中获取，AI 会自己查，不问你
• 决策权留给你，AI 只负责提问

/grill-with-docs 的额外能力： 在采访过程中同时运行 /domain-modeling，帮你构建项目的统一语言（Ubiquitous Language），实时更新 CONTEXT.md 和 ADR。

实际体验： Matt 说他曾被 AI 连续问了 16 个问题，复杂特性甚至被拷问半小时、回答了三五十个问题。

2. /domain-modeling（领域建模）#

用途： 建立和维护项目的领域词汇表，让 AI 用 1 个词而不是 20 个词来表达。

核心行为：

ADR 只有同时满足三个条件才创建： ①难以逆转 ②缺少上下文会让人困惑 ③真正做了权衡取舍。

3. /to-spec（生成规范，v1.1 由 /to_prd 重命名）#

用途： 将当前对话中达成的共识综合成一份规范文档，发布到 Issue Tracker。

关键点： 不再访谈——只综合你已经讨论过的内容。生成的文档已超出传统 PRD 的范围。

Spec 模板包含：

• Problem Statement — 用户视角的问题陈述
• Solution — 用户视角的解决方案
• User Stories — 长长的编号列表（要求极其详尽）
• Implementation Decisions — 模块、接口、架构决策、Schema 变更、API 契约
• Testing Decisions — 测试策略、测试接缝（Seam）、参照先例
• Out of Scope — 明确排除的内容
• Further Notes — 补充说明

4. /to-tickets（拆解任务，v1.1 由 /to_plan + /to_issues 合并）#

用途： 将 Spec 拆解为一组 曳光弹式（Tracer Bullet）垂直切片 Ticket。

**核心规则：

graph LR
    subgraph 垂直切片
        A["Schema 层"] --> B["API 层"] --> C["UI 层"] --> D["测试"]
    end

• 垂直切片，不是水平切片： 每个 Ticket 贯穿所有相关层，形成可独立验证的最小功能
• 阻塞边（Blocking Edges）： 每个 Ticket 必须声明自己被哪些 Ticket 阻塞
• 前置条件满足后即可并行： 不相互阻塞的 Ticket 可以同时拉起多个 Agent 并行执行
• 发布到 Tracker 时按依赖顺序（先发不被阻塞的），如果平台支持原生依赖关系就用原生的

示例： 做用户注册功能时：

• Ticket 01：邮箱密码注册 + 返回成功状态（不被阻塞，可立即开始）
• Ticket 02：邮箱验证（阻塞于 01）
• Ticket 03：密码重置（阻塞于 01）

而不是：

• ❌ Ticket 01：建所有数据库表
• ❌ Ticket 02：写所有 API 路由
• ❌ Ticket 03：做所有 UI 页面

5. /implement（实现阶段）#

用途： 基于 Spec 或 Ticket 实现代码。

流程：

1. 使用 /tdd 在预先确认的接缝（Seam）上驱动开发
2. 定期运行类型检查和相关测试
3. 实现完成后运行 /code-review
4. 提交到当前分支

6. /tdd（测试驱动开发）#

用途： 执行 Red → Green 循环，v1.1 将 Refactor 移出此循环。

三步循环：

1. Red — 先写一个失败的测试
2. Green — 只写刚好让测试通过的代码（不过度设计）
3. 下一个切片 — 一次一个接缝、一个测试、一个最小实现

注意： v1.1 中 Refactor（重构）不再属于 TDD 循环，而是在 /code-review 阶段被识别为重构建议。目的是减少实现阶段同时承担的关注点，避免立即重构改坏刚跑通的逻辑。

什么是好的测试：

• 通过公共接口验证行为，不触及实现细节
• 读起来像规格说明书（如 “用户可以用有效购物车结账”）
• 预期值必须来自独立的事实来源，不能是代码自己算出来的

反模式：

• 与实现耦合的测试
• 同义反复的测试（断言和代码用同样的方式计算期望值）
• 水平切片测试（先写所有测试再写所有实现）

7. /code-review（代码审查）#

用途： 双轴并行审查，防止一个维度掩盖另一个。

flowchart LR
    A["git diff"] --> B["Spec 轴子代理"]
    A --> C["Standards 轴子代理"]
    B --> D["汇总报告"]
    C --> D

Standards 轴注入了 Martin Fowler 的代码异味清单（完整 12 种）：** 神秘命名、重复代码、特性依恋、数据泥团、基本类型偏执、重复 Switch、霰弹式修改、发散式变化、投机式通用性、消息链、中间人、拒绝的遗赠。

重要原则： 代码异味是启发式判断，不是硬性违规。项目的编码规范优先级更高。

8. /wayfinder（寻路者）#

用途： 面对巨大而模糊、单个 AI 会话装不下的项目时使用。

核心概念 — 战争迷雾：

• 不要试图一次性看清全貌
• 只规划视距范围内的事物——那些明确、可在一个 Agent Session 中解决的问题
• 在 Issue Tracker 上建立共享地图（一个标记为 wayfinder:map 的 Issue）

Ticket 类型（各有标签）：

Wayfinder 默认只规划，不实施。 最终产出的是通往目的地的路线，而不是最终交付物。

9. /improve-codebase-architecture（改进架构）

用途： 扫描代码库中的架构摩擦，提出深化（Deepening）机会——把浅层模块重构成深层模块。

核心理念（来自 /codebase-design）：

流程：

1. 根据 git 历史找到代码库的热点区域
2. 生成一个 HTML 可视化报告，包含每个候选的 Before/After 对比图
3. 用 /grilling 深入探讨你选择的候选方案
4. 边做边更新领域模型

10. /triage（分类）#

用途： 将 Issue 和 PR 按状态机流转。

1
needs-triage → needs-info / ready-for-agent / ready-for-human / wontfix
2
     ↑              │
3
     └──────────────┘ (记者回复后)

11. 辅助 Skills#