这些指令什么时候用

这页查的是对 AI 说的指令。你不需要自己运行它们，也不用一次记住全部；想让 AI 明确走某一套流程时，在名称前加 $ 点名即可。

先分清三种东西

看到的写法	它是什么	在哪里使用
`$trellis-check`	项目里的 skill，点名让 AI 按固定流程做事	Codex 对话框
`$grill-with-docs`	全局 skill，把想法问清并同步整理术语和重大决定	Codex 对话框
`trellis update`	CLI 命令，更新项目里的 Trellis 文件	终端，通常让 AI 代跑

$trellis-* 只有在当前项目已经执行过 trellis init 后才存在。$grill-with-docs、$grilling 和 $domain-modeling 安装在 Codex 全局环境里，可以跨项目使用。

最容易混的两个

当前情况	应该使用	它负责留下什么
已经决定要做一个功能，需要建立任务、收敛范围和写 PRD	`$trellis-brainstorm`	Trellis 任务目录和 PRD，复杂时还会继续补设计与实施计划。
连“到底要做什么”都还模糊，术语不清或存在重要取舍	`$grill-with-docs`	把问题逐个问透；术语可进入 `CONTEXT.md`，少数重大决定可进入 ADR。
两种情况同时存在	两个一起用	先由 Trellis 建任务，在 planning 阶段用 grill 问清，再把结论写回 PRD。

平时最常用的 7 个

想做什么	点名的 skill	直接怎么说
刚打开项目，让 AI 先接手	`$trellis-start`	使用 `$trellis-start` 接手当前项目，先读取现状再决定下一步。
要为新功能建立任务和 PRD	`$trellis-brainstorm`	使用 `$trellis-brainstorm` 梳理这个需求，一次只问我一个关键问题。
想法、术语或重大取舍还没想清楚	`$grill-with-docs`	使用 `$grill-with-docs` 把想法问清，并同步整理术语和重大决定。
规划已确认，准备开始写代码	`$trellis-before-dev`	开始实现前使用 `$trellis-before-dev`，先读取本项目规范。
代码写完，准备验收	`$trellis-check`	使用 `$trellis-check` 做完整检查，并对照需求汇报问题。
一个 bug 修完后怕以后再犯	`$trellis-break-loop`	bug 已修好，使用 `$trellis-break-loop` 分析根因并把防复发规则写进项目规范。
这次工作结束了	`$trellis-finish-work`	使用 `$trellis-finish-work` 收尾，确认检查结果并记录进度。

一整段直接复制

使用 $trellis-start 接手当前项目。

如果需求还不清楚，使用 $trellis-brainstorm 梳理；
遇到术语含糊或重大取舍时，再使用 $grill-with-docs。

规划给我确认后，使用 $trellis-before-dev 再开始实现。
完成后使用 $trellis-check 检查，最后使用 $trellis-finish-work 收尾。

Trellis 全部 skills

日常流程

Skill	什么时候用	它会做什么
`$trellis-start`	新开会话、重新接手项目	读取工作流、Git 状态、当前任务和项目规范，再判断该直接改还是先规划。主要是读取。
`$trellis-brainstorm`	新功能、复杂任务、需求有多种做法	创建任务目录和 PRD，一次问一个关键问题，收敛范围；不会直接开始实现。
`$trellis-before-dev`	已经决定要实现，准备动代码	从 `.trellis/spec/` 读取当前模块真正适用的规范，减少 AI 按通用习惯乱改。主要是读取。
`$trellis-continue`	隔了一段时间，继续未完成任务	找到当前任务进行到哪一步，读取对应阶段说明，再从断点继续。
`$trellis-check`	写完代码、提交前、长任务中途	检查项目规范、类型、测试、跨层数据和一致性，汇报遗漏与风险。
`$trellis-finish-work`	一次开发告一段落	确认质量门槛、记录本次进度，并在任务已完成时归档；提交前仍由你确认。

建项目规范和防止重复踩坑

Skill	什么时候用	它会留下什么
`$trellis-spec-bootstrap`	项目第一次接入 Trellis，处理 `00-bootstrap-guidelines`	根据真实代码建立 `.trellis/spec/`，不是照抄空模板。
`$trellis-update-spec`	开发或排错中发现了以后还会用到的规则	把可执行的约定、接口契约或检查项写进 `.trellis/spec/`。
`$trellis-break-loop`	bug 已经修好，想避免同类问题再次出现	分析根因、失败尝试和预防机制，更新相关 spec；它不是代替第一次排错的指令。

偶尔才需要

Skill	什么时候用	需要知道的事
`$trellis-session-insight`	想找“上次怎么解决的”或以前讨论过什么	通过 `trellis mem` 读取历史 AI 对话，默认不修改项目。
`$trellis-channel`	明确要多 AI 协作、并行任务或交叉审查	会启用 Trellis 的多代理协作运行时；普通任务暂时不用。查看以后怎么用
`$trellis-meta`	要修改 Trellis 自己的配置、hooks、模板或工作流	这是维护 Trellis 本身的进阶指令，不是日常开发入口。

grill-with-docs 这套 skills

Skill	什么时候用	会不会写文件
`$grill-with-docs`	需求模糊、产品取舍复杂，又希望结论能留在项目里	会组合下面两个 skills；确认术语后可更新 `CONTEXT.md`，重大决定满足条件时可写 ADR。需要你主动点名。
`$grilling`	只想让 AI 把想法追问清楚	一次只问一个问题并给推荐答案；达成共同理解前不实现，通常不负责沉淀文档。
`$domain-modeling`	已经知道要专门整理术语或记录重大决定	会维护 `CONTEXT.md`；只有难撤销、缺少上下文会令人意外、且存在真实取舍时才写 ADR。

平时优先使用 $grill-with-docs。只有你明确想“只问清楚，不整理文档”，或者“只整理术语和决定”时，才分别点名底层的两个 skills。

两套一起用时这样说

使用 $trellis-start 接手当前项目，并按 Trellis 为这次需求创建任务。

规划阶段使用 $grill-with-docs 把需求问清楚：
一次只问我一个真正需要决定的问题；
能从项目里查到的事实请自己查；
术语结论写入 CONTEXT.md；
只有重大且难以撤销的取舍才写 ADR。

达成共同理解后，把需求、范围和验收条件写入 Trellis PRD，给我确认后再实现。