平时怎么和 AI 一起做

你负责表达目标、回答取舍和确认关键节点；AI 负责查事实、维护文件、写代码、测试和汇报。流程的目的不是增加仪式，而是防止 AI 边猜边改。

一件事平时怎么走完

1. 接手上下文

   AI 使用 $trellis-start，读取 Git 状态、当前任务、项目规范和工作流。

2. 创建 Trellis 任务

   你明确同意“为这件事创建任务并进入 planning”。AI 先写 PRD；复杂任务还要写 design.md 和 implement.md。

3. 需求模糊时使用 $grill-with-docs

   AI 一次问一个决策。确认后的术语进入 CONTEXT，少数重大决定进入 ADR。

4. 你确认规划后再实现

   AI 根据 PRD、设计和项目 spec 开发。没有确认前不进入实现阶段。

5. 检查、测试、沉淀

   对照验收条件检查，运行真实测试；必要时更新项目 spec，避免同类问题再次出现。

6. 确认后提交或推送

   AI 汇报改动和验证结果。你说“提交”只创建本地 commit；你说“推上去”才会 push 到 GitHub。

事情大小不一样，流程也不用一样

类型	规划文件	适合的事情
很小且明确	可以不建任务，直接检查、修改、验证	错字、小样式、明确的小 bug
轻量任务	prd.md 可以足够	单一、边界清楚的小功能
复杂任务	prd.md + design.md + implement.md	多页面、数据结构、跨模块功能

授权要分开

同意创建任务，不等于同意开始实现；同意提交，也不等于同意推送。这样能保留你在关键节点的控制权。

继续上次没做完的事

恢复当前上下文

使用 $trellis-start 接手当前项目。
先读取项目规则、Git 状态、当前任务和相关代码，保护已有改动。
先告诉我目前处于什么状态，以及下一步建议，不要立刻改代码。

事情很小而且已经想清楚

轻量 Trellis 任务

按 Trellis 为这次需求创建一个轻量任务并进入 planning。

需求：[写你的需求]

先把需求、范围和验收条件写进 PRD，给我确认后再实现。完成后运行相关测试并汇报结果。

同一个问题总是修不好

跳出重复试错

这个问题已经反复修过仍未解决。请使用 $trellis-break-loop，停止继续打补丁。

整理已经尝试过的方案和证据，重新分类根因，提出能区分不同假设的验证办法。先给我根因分析和下一步验证顺序，不要直接大改。

做完后检查并发布

检查、提交与推送

按 Trellis 完成当前任务：
1. 对照 PRD 和验收条件检查实现；
2. 运行相关测试和质量审查；
3. 必要时更新 .trellis/spec；
4. 汇报改动、验证结果和剩余风险；
5. 等我确认后再提交；
6. 只有我明确说“推上去”后才推送 GitHub。