Trellis基础教程

Trellis 使用文档

让 AI 编码在团队规模上变得可靠 —— 跨 14+ AI 编码平台的团队级 AI 编码工作流框架

官方地址

GitHub - mindfold-ai/Trellis: The best agent harness.

Trellis - Trellis Doc

目录


1. 概述

Trellis 是一个团队级 AI 编码工作流框架,核心解决的问题是:让 AI 编码在不同会话、不同工具、不同开发者之间保持一致和可靠

核心能力 说明
自动注入 Spec .trellis/spec/ 写一次约定,Trellis 自动将相关上下文注入每次会话
任务驱动工作流 PRD、实现上下文、审查上下文和任务状态保存在 .trellis/tasks/
项目记忆 .trellis/workspace/ 中的日志保留上次会话内容,新会话不再从零开始
团队共享标准 Spec 文件随仓库版本控制,一人总结的规则全团队受益
多平台统一 同一套 .trellis/ 核心适用于 14+ AI 编码工具

2. 核心概念

概念 路径 作用
Spec(规格) .trellis/spec/ 项目编码约定、设计决策、模式规范,团队共享、PR 审查
Task(任务) .trellis/tasks/ 单个开发任务的 PRD、研究、上下文清单、元数据
Workspace(工作区) .trellis/workspace/<name>/ 开发者个人日志和跨会话笔记
Workflow(工作流) .trellis/workflow.md 定义开发流程的阶段、路由规则、提交计划
JSONL 上下文 implement.jsonl / check.jsonl / research.jsonl 为子代理指定该任务需要读取的 spec 和研究文件
子代理 平台 agents 目录 独立的 AI 子进程,接收 JSONL 上下文,执行实现、检查或研究
技能 平台 skills 目录 自动触发的 AI 行为模式(brainstorm、check、update-spec 等)

3. 安装与初始化

3.1 全局安装

1
2
# 需要 Node.js >= 18 和 Python >= 3.9
npm install -g @mindfoldhq/trellis@latest

支持 macOS、Linux 和 Windows。

3.2 项目初始化

1
2
3
4
5
6
7
8
9
cd your-project

# 交互式初始化(自动检测已安装的平台)
trellis init -u your-name

# 指定平台初始化
trellis init -u your-name --opencode
trellis init -u your-name --claude --cursor --opencode
trellis init -u your-name --codex --gemini

支持的平台标志:--claude--cursor--opencode--codex--kiro--gemini--qoder--codebuddy--copilot--droid--pi--antigravity--windsurf--kilo

your-name 成为你的开发者身份,并在 .trellis/workspace/your-name/ 下创建个人工作区。

3.3 初始化场景

场景 命令 结果
首次项目初始化 trellis init -u your-name --claude 创建 .trellis/ + 引导任务 00-bootstrap-guidelines
添加新平台 trellis init --cursor 在已有 .trellis/ 上写入新平台配置,不生成任务
新开发者加入 trellis init -u their-name 生成入职引导任务 00-join-<slug>
同一开发者新机器 同上 也生成入职任务(因为 .developer 不提交到 Git)
重复运行 init trellis init -u your-name 交互式询问添加开发者还是完全重初始化

.trellis/.developer 是一个 gitignored 的每台机器身份文件,绝不会提交到仓库。

init_developer.py 的逻辑是:先检查 .developer 是否存在,存在就直接退出,不干活。只有删了它,脚本才会创建新开发者的 workspace 目录。所以如果你想要在本机切换开发者需要先删除.develpoer再trellis init -u their-name

也可以直接直接改developer文件里的 name,但 workspace 目录不会自动创建——要么提前已有,要么首次工作时用 trellis init -u 初始化一次。

3.4 远程 Spec 模板

不从头写 spec,可以从远程拉取预构建模板:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 交互式选择模板
trellis init -u your-name

# 指定模板 ID
trellis init -u your-name --template electron-fullstack

# 从自定义仓库拉取
trellis init --registry gh:myorg/myrepo/my-team-spec
trellis init --registry gh:myorg/myrepo/marketplace --template my-template
trellis init --registry gh:myorg/myrepo/specs#develop

# GitLab 或 Bitbucket
trellis init --registry gitlab:myorg/myrepo/specs
trellis init --registry bitbucket:myorg/myrepo/specs

已有 spec 时的冲突策略:

标志 行为
--overwrite 删除已有 spec 目录,重新下载
--append 只复制不存在的文件
(无标志) 交互式提示

私有仓库需设置环境变量:

1
GIGET_AUTH=ghp_xxxxx trellis init --registry gh:myorg/private-repo/specs

4. 目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
your-project/
├── .trellis/ # Trellis 核心(平台无关)
│ ├── .developer # 开发者身份(gitignored)
│ ├── .version # Trellis 版本
│ ├── .template-hashes.json # 模板文件哈希(用于更新)
│ ├── workflow.md # 开发工作流指南
│ ├── config.yaml # 项目配置(包、更新策略、钩子)
│ │
│ ├── .runtime/ # 会话级运行时状态(gitignored)
│ │ └── sessions/ # 每个 AI 会话的活动任务
│ │ └── <session-key>.json
│ │
│ ├── spec/ # 项目 Spec 库
│ │ ├── frontend/ # 前端 Spec
│ │ ├── backend/ # 后端 Spec
│ │ └── guides/ # 思维指南
│ │
│ ├── workspace/ # 开发者工作区
│ │ ├── index.md
│ │ └── {developer-name}/
│ │ ├── index.md # index.md 是所有 journal 的汇总索引
│ │ └── journal-N.md # 每次会话的日志
│ │
│ ├── tasks/ # 任务目录
│ │ ├── {MM-DD-task-name}/ # 活跃任务
│ │ │ ├── task.json # 任务元数据
│ │ │ ├── prd.md # 需求文档
│ │ │ ├── info.md # 技术设计(可选)
│ │ │ ├── implement.jsonl # 实现子代理上下文
│ │ │ ├── check.jsonl # 检查子代理上下文
│ │ │ └── research.jsonl # 研究子代理上下文
│ │ └── archive/ # 归档任务
│ │ └── {YYYY-MM}/
│ │
│ └── scripts/ # 自动化脚本(Python)
│ ├── task.py # 任务管理
│ ├── get_context.py # 会话上下文
│ ├── add_session.py # 记录会话
│ ├── create_bootstrap.py # 首次 spec 引导
│ └── common/ # 共享库

├── .opencode/ # OpenCode 配置
│ ├── commands/trellis/ # 命令
│ │ ├── start.md
│ │ ├── finish-work.md
│ │ └── continue.md
│ ├── agents/ # 子代理定义
│ │ ├── trellis-implement.md
│ │ ├── trellis-check.md
│ │ └── trellis-research.md
│ ├── skills/ # 自动触发技能
│ │ ├── trellis-brainstorm/
│ │ ├── trellis-before-dev/
│ │ ├── trellis-check/
│ │ ├── trellis-update-spec/
│ │ └── trellis-break-loop/
│ └── plugins/ # JS 插件
│ ├── session-start.js
│ ├── inject-subagent-context.js
│ └── inject-workflow-state.js

└── .agents/skills/ # 跨平台共享技能层

5. 工作流详解

5.1 三阶段循环

Trellis 运行一个 3 阶段循环,由自动触发的技能和子代理驱动:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
┌──────────────────────────────────────────────────────────────────────┐
│ Phase 1: Plan(规划) │
│ │
│ 1.0 task.py create → 创建任务目录 │
│ 1.1 trellis-brainstorm → 逐个问题讨论需求,迭代 prd.md │
│ 1.2 trellis-research → 调查研究(按需),结果存入 research/ │
│ 1.3 精心策划 implement.jsonl / check.jsonl(spec + research 路径) │
│ 1.4 task.py start → 写入当前会话的活动任务 │
├──────────────────────────────────────────────────────────────────────┤
│ Phase 2: Execute(执行) │
│ │
│ 2.1 trellis-implement → 按 prd.md 写代码,不提交 git │
│ 2.2 trellis-check → 对照 spec 审查 diff + 运行 lint/类型检查/测试 │
│ → 自修复(bounded loop) │
├──────────────────────────────────────────────────────────────────────┤
│ Phase 3: Finish(收尾) │
│ │
│ 3.2 trellis-break-loop → Debug 复盘(按需) │
│ 3.3 trellis-update-spec → 将新经验写回 .trellis/spec/ │
│ 3.4 主会话驱动工作提交(分组 git commit) │
└──────────────────────────────────────────────────────────────────────┘

5.2 会话启动

当 AI 会话开始时,Trellis 通过 SessionStart 钩子/插件自动加载上下文:

上下文 来源
开发者身份 .trellis/.developer
Git 状态 当前分支、脏文件、近期提交
活动任务指针 .trellis/.runtime/sessions/<session-key>.json
活动任务列表 .trellis/tasks/*/task.json
工作流摘要 .trellis/workflow.md
Spec 索引 .trellis/spec/**/index.md
工作区记忆 .trellis/workspace/<developer>/index.md + 近期日志

对于有钩子/扩展能力的平台(Claude Code、Cursor、OpenCode 等),这一切是自动的。对于没有自动注入的平台(Kilo、Antigravity、Windsurf),需手动运行 /trellis:start

5.3 每轮提示的工作流状态注入

在有钩子的平台上,每次用户消息都会触发轻量级的工作流状态注入:

  1. 解析当前会话的活动任务
  2. 读取 task.json.status
  3. workflow.md 中匹配对应的状态块 [workflow-state:STATUS]
  4. 将状态指引包裹在 <workflow-state> 标签中注入当前对话轮

5.4 任务路由

主会话根据你的输入和当前工作流状态选择三条路径之一:

路径 适用场景 行为
直接回答 简单问答、查找、聊天 AI 回答后停止
Trellis 任务 实现、重构、构建等代码变更 创建或继续任务
内联逃逸 你明确要求跳过 Trellis 仅本次轮次内联处理

6. 命令与技能参考

6.1 命令

命令 触发方式 用途
/trellis:start 手动(无 SessionStart 钩子的平台) 开启会话,加载上下文,分类工作
/trellis:finish-work 手动(Phase 3.4 提交之后) 归档任务 + 记录会话日志
/trellis:continue 手动 推进当前任务到下一步

在有 SessionStart 钩子的平台上,不需要手动运行 /trellis:start

6.2 自动触发技能

技能 触发时机 用途
trellis-brainstorm 用户描述功能/Bug/模糊需求时 将需求转化为任务 + prd.md
trellis-before-dev 开始写代码前 读取相关 spec,确保 AI 了解约定
trellis-check 实现完成后 验证 + 自修复循环
trellis-update-spec 发现值得记录的经验时 将知识写入 .trellis/spec/
trellis-break-loop 解决棘手 Bug 后 根因分析 + 预防机制

6.3 子代理

子代理 限制 何时生成
trellis-research 只读 需要代码库搜索/模式发现/文档查找时
trellis-implement 写代码但不提交 需求和计划就绪后
trellis-check 写代码(修复) 验证阶段,内部运行自修复循环

7. 任务管理

7.1 任务生命周期

1
2
3
4
5
6
7
8
create → curate jsonl → start → implement/check → finish → archive

create: 创建任务目录 + task.json + 初始 jsonl
curate jsonl: AI 填充 implement/check/research 上下文
start: 设置当前 AI 会话的活动任务
implement/check: 开发和验证循环
finish: 清除当前 AI 会话的活动任务
archive: 移动已完成任务到 archive/

7.2 task.py 子命令

创建任务

1
2
3
4
5
6
7
TASK_DIR=$(./.trellis/scripts/task.py create "添加用户登录" \
--slug user-login \ # 目录名后缀(可选,自动生成)
--assignee alice \ # 指派人(可选)
--priority P1 \ # 优先级: P0/P1/P2/P3(可选,默认 P2)
--description "实现 JWT 登录") # 描述(可选)

# 创建目录: .trellis/tasks/02-27-user-login/

上下文配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 添加 spec 文件到实现上下文
./.trellis/scripts/task.py add-context "$TASK_DIR" implement \
".trellis/spec/backend/index.md" "后端开发指南"

# 添加检查上下文
./.trellis/scripts/task.py add-context "$TASK_DIR" check \
".trellis/spec/cli/unit-test/conventions.md" "单元测试约定"

# 添加整个目录(自动读取所有 .md 文件)
./.trellis/scripts/task.py add-context "$TASK_DIR" implement \
"src/services/" "现有服务模式"

# 验证 jsonl 引用的文件都存在
./.trellis/scripts/task.py validate "$TASK_DIR"

# 查看所有 JSONL 条目
./.trellis/scripts/task.py list-context "$TASK_DIR"

# 查看有哪些 spec 可用
./.trellis/scripts/get_context.py --mode packages

任务控制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 设为当前会话的活动任务
./.trellis/scripts/task.py start "$TASK_DIR"

# 清除当前会话的活动任务
./.trellis/scripts/task.py finish

# 设置 Git 分支名
./.trellis/scripts/task.py set-branch "$TASK_DIR" "feature/user-login"

# 设置 PR 目标分支
./.trellis/scripts/task.py set-base-branch "$TASK_DIR" "main"

# 设置范围(用于提交消息: feat(scope): ...)
./.trellis/scripts/task.py set-scope "$TASK_DIR" "auth"

任务列表与归档

1
2
3
4
5
6
7
8
9
10
11
12
# 列出活跃任务
./.trellis/scripts/task.py list
./.trellis/scripts/task.py list --mine # 只看自己的
./.trellis/scripts/task.py list --status review # 按状态过滤

# 归档已完成任务
./.trellis/scripts/task.py archive user-login
# 移动到 archive/2026-02/

# 列出已归档任务
./.trellis/scripts/task.py list-archive
./.trellis/scripts/task.py list-archive 2026-02 # 按月份过滤

7.3 task.json 结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
{
"id": "02-27-user-login",
"name": "user-login",
"title": "添加用户登录",
"description": "实现 JWT 登录流程",
"status": "planning",
"dev_type": null,
"scope": null,
"package": null,
"priority": "P1",
"creator": "alice",
"assignee": "alice",
"createdAt": "2026-02-27",
"completedAt": null,
"branch": null,
"base_branch": "main",
"worktree_path": null,
"commit": null,
"pr_url": null,
"subtasks": [],
"children": [],
"parent": null,
"relatedFiles": [],
"notes": "",
"meta": {}
}

状态转换:

1
2
3
task.py create   →  status: "planning"
task.py start → planning → "in_progress"(其他状态不变)
task.py archive → status: "completed" + 移动到 archive/

7.4 JSONL 上下文配置

task.py create 在有子代理能力的平台上会自动在 implement.jsonlcheck.jsonl 中写入一条示例行:

1
{"_example": "Fill with {\"file\": \"<path>\", \"reason\": \"<why>\"}. ..."}

AI 在 Phase 1.3 阶段会将其替换为真实的 spec 和研究文件引用:

1
2
3
{"file": ".trellis/spec/guides/index.md", "reason": "共享跨包思维指南"}
{"file": ".trellis/spec/cli/backend/index.md", "reason": "后端开发指南"}
{"file": ".trellis/tasks/.../research/auth-library-comparison.md", "reason": "库选择理由"}

应该放入 jsonl 的

  • Spec 文件(.trellis/spec/<pkg>/<layer>/index.md + 具体指南文件)
  • 研究文件({TASK_DIR}/research/*.md

不应放入 jsonl 的

  • 代码文件(子代理在实现阶段自己读取)
  • 即将修改的文件(同理)

7.5 父子任务

1
2
3
4
5
6
7
8
9
10
11
12
13
# 方式 A:创建时直接指定父任务
./.trellis/scripts/task.py create "JWT 中间件" \
--slug jwt-middleware \
--parent 02-27-user-login

# 方式 B:链接两个已有任务
./.trellis/scripts/task.py add-subtask \
02-27-user-login \ # 父任务目录
02-28-jwt-middleware # 子任务目录

# 解除链接(不删除任何任务)
./.trellis/scripts/task.py remove-subtask \
02-27-user-login 02-28-jwt-middleware

注意:task.json 中的 subtasks 字段是任务内部的待办清单,与父子任务无关。父子关系通过 parentchildren 字段管理。

7.6 任务生命周期钩子

.trellis/config.yaml 中配置:

1
2
3
4
5
6
7
8
9
hooks:
after_create:
- 'python3 .trellis/scripts/hooks/linear_sync.py create'
after_start:
- 'python3 .trellis/scripts/hooks/linear_sync.py start'
after_finish:
- "echo 'Task finished'"
after_archive:
- 'python3 .trellis/scripts/hooks/linear_sync.py archive'
事件 触发时机 用途
after_create task.py create 完成后 在项目追踪器中创建关联 issue
after_start task.py start 设置活动任务后 更新 issue 状态为 “进行中”
after_finish task.py finish 清除活动任务后 通知团队、触发审查
after_archive task.py archive 归档任务后 标记 issue 为 “完成”

每个钩子接收环境变量 TASK_JSON_PATH(指向 task.json 的绝对路径)。

Trellis 内置了 Linear 同步钩子示例(.trellis/scripts/hooks/linear_sync.py),支持创建、更新状态和同步 PRD 内容。


8. 编写 Spec

8.1 Spec 目录结构

trellis init 生成的默认结构:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
.trellis/spec/
├── frontend/
│ ├── index.md # 索引:列出所有 spec 及其状态
│ ├── component-guidelines.md # 组件规范
│ ├── hook-guidelines.md # Hook 规范
│ ├── state-management.md # 状态管理
│ ├── type-safety.md # 类型安全
│ ├── quality-guidelines.md # 质量指南
│ └── directory-structure.md # 目录结构

├── backend/
│ ├── index.md
│ ├── database-guidelines.md
│ ├── error-handling.md
│ ├── logging-guidelines.md
│ ├── quality-guidelines.md
│ └── directory-structure.md

└── guides/
├── index.md
├── cross-layer-thinking-guide.md
└── code-reuse-thinking-guide.md

frontend/backend/ 不是固定的。Trellis 通过扫描 .trellis/spec/ 下一层包含 index.md 的目录来发现 spec 层。你可以按包、按运行时、按职责命名。

8.2 从空模板到完整 Spec

trellis init 生成的模板标记为 “(To be filled by the team)”,是空的。填充步骤:

步骤 1:从实际代码中提取模式

1
2
ls src/components/     # 组件结构
ls src/services/ # 服务结构

步骤 2:写下你的约定

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 组件指南

## 文件结构

- 每个文件一个组件
- 文件名使用 PascalCase: `UserProfile.tsx`
- 样式就近放置: `UserProfile.module.css`
- 测试就近放置: `UserProfile.test.tsx`

## 模式

#### 必须

- 函数组件 + hooks(禁止类组件)
- TypeScript 显式 Props 接口
- 页面组件用 `export default`,共享组件用命名导出

#### 禁止

- Props 中不允许 `any` 类型
- 不使用内联样式(使用 CSS Modules)
- 不直接操作 DOM

步骤 3:添加代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#### 正确示例

```tsx
interface UserProfileProps {
userId: string;
onUpdate: (user: User) => void;
}

export function UserProfile({ userId, onUpdate }: UserProfileProps) {
// ...
}
```

#### 错误示例

```tsx
// 不要:没有 Props 接口,使用 any
export default function UserProfile(props: any) {
// ...
}
```

步骤 4:更新 index.md 状态

1
2
3
4
| 规范           | 文件                    | 状态       |
| -------------- | ----------------------- | ---------- |
| 组件指南 | component-guidelines.md | **已填写** |
| Hook 指南 | hook-guidelines.md | 待填写 |

也可使用内置的 trellis-spec-bootstrap 技能,让 AI 从实际代码库中草拟初版 spec。

8.3 Spec 编写原则

Spec 分为两类:

类型 位置 目的 内容风格
代码规格 <layer>/*.md(如 backend/ “如何安全实现” 签名、契约、验证矩阵、正确/基础/错误示例、必要测试
思维指南 guides/*.md “写代码前要想什么” 检查清单、问题、指向 spec 的指针

好的 Spec 条目——具体、可执行、有代码示例、有原因说明:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#### 约定:使用 ORM 批量方法,禁止循环单行 DB 调用

**是什么**:对于 N 行数据的集合,调用 ORM 的批量方法(`createMany``updateMany``deleteMany`)一次。绝不将单行 `create`/`update`/`delete` 包裹在 `for`/`Promise.all` 循环中。

**为什么**:每次 DB 调用是一次往返。生产环境中,200 项的循环会让 p99 延迟从 50ms 悄无声地增长到 8s——我们已在代码审查中两次发现这个问题(PR #312, #417)。批量方法将 N 次往返压缩为一条语句。

**示例**

```ts
// ✅ 正确 — 一次往返
await prisma.user.createMany({ data: users });

// ❌ 错误 — N 次往返
for (const user of users) {
await prisma.user.create({ data: user });
}
```

**相关**`quality-guidelines.md#performance``error-handling.md#transactions`

差的 Spec 条目——没有签名、没有示例、没有原因:

1
2
3
4
5
#### 数据库

- 使用好的查询模式
- 小心处理 SQL
- 遵循最佳实践

8.4 Spec 更新模板

trellis-update-spec 提供多种模板,根据你学到的内容选择:

你学到了…… 模板 关键字段
为什么选择方案 X 而非 Y 设计决策 上下文、考虑的选项、决策、示例、扩展性
项目用方式 X 做某事 约定 是什么、为什么、示例、相关
某个反复出现的问题的可复用解决方案 模式 问题、解决方案、示例(好+坏)、原因
导致问题的做法 禁止模式 问题代码片段、为什么不好、替代代码片段
容易犯的错误 常见错误 症状、原因、修复、预防
非显而易见的行为 陷阱 > Warning: 引用块,说明何时/如何

涉及基础设施/跨层工作时,需要完整的 7 节格式:

  1. 范围/触发 — 为什么需要代码规格深度
  2. 签名 — 命令/API/DB 签名
  3. 契约 — 请求字段、响应字段、环境变量(名称、类型、约束)
  4. 验证与错误矩阵<条件> → <错误> 表格
  5. 正确/基础/错误案例 — 示例输入及预期输出
  6. 必要测试 — 单元/集成/E2E 及断言点
  7. 错误 vs 正确 — 至少一个显式对比

9. 平台支持

9.1 能力矩阵

能力 Claude Code Cursor OpenCode Codex Kiro Gemini Qoder CodeBuddy Copilot Droid Pi Agent
SessionStart 自动注入
子代理上下文注入
子代理 (trellis-*)
自动触发技能
显式 /trellis:* 命令

✅ = Trellis 配置且平台执行 · ⚡ = 部分支持 · ❌ = 平台不提供此事件 · — = 平台无命令原语

9.2 各平台配置详情

OpenCode

1
trellis init -u your-name --opencode

OpenCode 1.2.x 是完整的一类平台(钩子 + 子代理):

  • .opencode/commands/trellis/:start / finish-work / continue
  • .opencode/agents/trellis-implement.mdtrellis-check.mdtrellis-research.md
  • .opencode/skills/:5 个 trellis 技能
  • .opencode/plugins/:JS 插件(session-start.jsinject-subagent-context.jsinject-workflow-state.js

Claude Code

最完整的自动化支持。钩子:

钩子 触发时机 效果
session-start.py SessionStart 注入身份、git 状态、活动任务
inject-workflow-state.py UserPromptSubmit 将 AI 引导向当前任务状态
inject-subagent-context.py PreToolUse (Task) 加载 implement.jsonl/check.jsonl/research.jsonl

Codex

需在 ~/.codex/config.toml 中启用钩子:

1
2
[features]
hooks = true # Codex 0.129+。旧版本用 codex_hooks = true

Codex 0.129+ 还需要在 Codex 内运行 /hooks 一次性审批钩子。

Kiro

Trellis 内容通过 .kiro/ 技能和代理文件交付。Kiro 的 Agent Hooks 是用户配置的(在文件保存、构建成功等事件触发),Trellis 不默认安装任何 Kiro Agent Hook。

Gemini CLI

  • .gemini/commands/trellis/{name}.toml:TOML 命令文件
  • .gemini/skills/trellis-{name}/SKILL.md:5 个技能
  • .gemini/agents/{name}.md:子代理定义(拉取式 prelude)
  • .gemini/hooks/session-start.py:SessionStart 钩子

无子代理平台(Kilo、Antigravity、Windsurf)

这三个平台只有工作流 + 技能,没有钩子和子代理。入口:

  • Kilo: /start.md
  • Antigravity: 打开 .agent/workflows/start.md
  • Windsurf: /trellis-start

10. 多开发者协作

每人隔离(无冲突)

路径 说明
个人工作区 .trellis/workspace/{name}/ 每个开发者自己的日志和索引
开发者身份 .trellis/.developer gitignored,每台机器独立
会话运行时 .trellis/.runtime/ gitignored,每个 AI 会话/窗口有自己的活动任务文件

共享状态(通过 PR 协调)

路径 说明
Spec .trellis/spec/ 团队约定,像代码一样 PR 审查
任务 .trellis/tasks/ 任务 JSON;使用 --assignee 避免冲突

新开发者加入已有项目时:

1
2
trellis init -u their-name
# 选择 "Set up developer identity on this device"

这会创建 .trellis/.developer.trellis/workspace/their-name/,并生成入职引导任务。


11. 版本管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 查看当前版本
cat .trellis/.version

# 更新到最新版本
trellis update

# 预览更新
trellis update --dry-run

# 应用破坏性变更迁移(大版本必须)
trellis update --migrate

# 强制覆盖本地修改的文件
trellis update -f

# 跳过本地修改的文件
trellis update -s

模板哈希机制(.trellis/.template-hashes.json):

  1. 计算本地文件哈希
  2. 与记录的模板哈希比较
  3. 匹配 → 文件未被用户修改 → 安全更新
  4. 不匹配 → 提示用户(覆盖/跳过),或使用 -f/-s 策略

破坏性变更会附带迁移清单:不带 --migratetrellis update 会退出并给出说明,而非静默重命名文件。


12. 真实场景

12.1 从零开始新项目

起始提示

1
2
3
我正在从零开始构建一个 B2B 仪表板。帮我设置 Trellis 用于第一周的工作。

先问缺失的产品和技术栈决策,然后创建一个小的首个任务 PRD 和前端结构、API 形态、错误处理和测试策略的最小 spec。

工作流

  1. 运行 trellis init → 生成约 17 个默认 spec 模板 + 引导任务 00-bootstrap-guidelines
  2. 在引导任务中,与 AI 讨论产品需求和技术栈
  3. 创建最小的端到端任务(task.py create),AI 进入 Phase 1 规划
    • trellis-brainstorm 逐个问题澄清需求,迭代 prd.md
    • 复杂任务还需写 design.md(技术设计)和 implement.md(执行计划)
    • 策划 implement.jsonl / check.jsonl(子代理上下文清单)
    • 你确认规划后,task.py start 激活任务(planningin_progress
  4. AI 进入 Phase 2 执行
    • trellis-implementprd.md 写代码
    • trellis-check 审查 diff + 跑 lint/测试,自修复
    • 可反复 /trellis:continue 驱动循环(不说也行,AI 会根据 task.json.status 自动判断下一步)
  5. AI 进入 Phase 3 收尾
    • trellis-update-spec 将踩坑经验写回 .trellis/spec/
    • 主会话驱动 git commit
  6. 执行 task.py finishtask.py archive 归档任务
  7. 输入 /trellis:finish-work 将会话摘要写入 journal

注意:新项目代码还少时无需手动填充 spec 模板,也无需使用 trellis-spec-bootstrap。等积累几轮开发、代码有了一定规模后,再用 trellis-spec-bootstrap 一次性从代码库分析提取 spec 更高效。

12.2 接手现有项目

起始提示

1
2
3
这是一个已有仓库。先不要重构代码。

检查代码库并提出下一个功能任务的最小 Trellis 引导方案。识别 API 路由、权限检查、日志、测试和前端表单的实际模式。只根据当前代码示例支持的编写 spec。

关键原则

  • 不要将理想标准写成已实现的代码
  • 不要填充每个模板——错误的规则比空白占位符更有害
  • 让 AI 为每条约定引用文件路径

12.3 交付产品功能

起始提示

1
2
3
创建团队邀请功能的 Trellis 任务。

功能应包括:工作区管理员通过邮箱邀请用户、重新发送待处理邀请、撤销邀请、接受邀请。包含产品需求、范围外项目、数据模型变更、API 形态、前端状态、测试和上线风险。

任务拆分(在同一 Trellis 任务下):

子任务 范围
产品与契约 邀请生命周期、角色规则、过期行为、范围外选择
数据模型 invitations 表、token 哈希、过期、唯一性、审计字段
API 和服务行为 创建/重新发送/撤销/接受邀请、管理员检查、幂等性
邮件副作用 邀请邮件模板、重新发送行为、测试邮件/模拟提供商
UI 状态 邀请表单、待处理列表、撤销/重新发送操作、接受屏幕
跨层检查 从创建邀请到接受会员的端到端路径

12.4 重构遗留模块

起始提示

1
2
3
为 src/billing/invoice-service.ts 创建一个行为保持不变的重构任务。

先映射当前职责、调用方、副作用和现有测试。然后提出最安全的顺序。在有特征测试或明确覆盖之前,不要改变行为。

在 PRD 中明确写出行为不变量

1
2
3
4
5
6
## 必须不变的行为

- 发票总额必须与现有计算匹配活跃折扣。
- 失败的支付尝试必须仍然写入审计日志。
- 邮件渲染输出必须与现有模板逐字节兼容。
- 公共 API 响应形状不得改变。

12.5 修复反复出现的 Bug

起始提示

1
2
3
修复 SessionStart 钩子在 `str | None` 上的崩溃。用户终端的 Python 是 3.11,但钩子子进程似乎使用了更旧的版本。

在最小 PATH shell 上复现,识别最小安全修复,添加检测此类问题的方法,然后运行 break-loop 分析。如果根因暴露了缺失的约定,提出 spec 更新。

完成标准

  • 补丁修复了报告的行为
  • 回归测试在没有补丁时失败
  • 根因已记录
  • 存在聊天记录之外的预防机制

12.6 减少重复审查反馈

起始提示

1
2
3
审查最近几个 PR 的评论,帮我将重复的工程反馈转化为 Trellis spec。

只提出具体的、可执行的、与实际审查评论关联的规则。为每条规则展示目标 spec 文件和好/坏示例。

示例转换:

重复的审查评论 更好的 spec 规则
“这里需要加载状态” “每个异步提交按钮都有 idle、loading、success 和 error 状态”
“这里不要用 any “公共组件 Props 不允许使用 any;使用显式接口或泛型”
“API 错误格式不一致” “所有路由处理器通过 toApiError() 返回 ApiError

12.7 团队推广

阶段 目标 退出标准
1 试点一个仓库 用 spec、检查和日志完成一个真实任务
2 捕获重复反馈 3-5 个审查模式成为 spec
3 标准化任务工作流 开发者知道何时使用 /trellis:start/trellis:continue/trellis:finish-work
4 添加平台适配 多个 AI 工具消费同一 .trellis/ 上下文
5 治理更新 Spec 和工作流变更像代码一样审查

13. 配置参考

config.yaml

.trellis/config.yaml 是项目级配置文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 包配置(monorepo 中按包划分 spec)
packages:
- cli
- docs-site

# 更新策略
update:
skip: [] # 跳过更新的文件模式

# 任务生命周期钩子
hooks:
after_create:
- 'python3 .trellis/scripts/hooks/linear_sync.py create'
after_start:
- 'python3 .trellis/scripts/hooks/linear_sync.py start'
after_finish:
- "echo 'Task finished'"
after_archive:
- 'python3 .trellis/scripts/hooks/linear_sync.py archive'

14. 常见问题

Trellis 和 CLAUDE.mdAGENTS.md.cursorrules 有什么区别?

这些文件是有用的入口点,但往往会变成庞大的单一文件。Trellis 在它们周围添加了分层的 spec、任务 PRD、工作流关卡、工作区记忆和平台感知的生成文件。

Trellis 只适用于 Claude Code 吗?

不是。Trellis 是一个跨多个 AI 编码工具的项目层。同一套 .trellis/ 核心在 14+ 平台上通用。

Trellis 是给个人开发者还是团队的?

两者都适用。个人开发者用它来记忆和可重复的工作流。团队获得更大收益:共享标准、任务边界、可审查的上下文和平台可移植性。

必须手动写每个 spec 文件吗?

不必。很多团队让 AI 从现有代码草拟 spec,然后手工精修重要部分。Trellis 效果最好时,是你保持高信号规则明确且版本化。

团队使用会有冲突吗?

不会。个人工作区日志(workspace/<name>/)是每个开发者独立的。共享的 spec 和任务通过 PR 审查,和项目其他制品一样。

/trellis:finish-work 做什么?

  1. 检查工作区是否干净(无脏文件)
  2. 归档活动任务到 archive/YYYY-MM/
  3. 追加会话摘要到 workspace/<developer>/journal-N.md
  4. 更新工作区索引

不是 提交代码的命令——代码提交在 Phase 3.4 由主会话驱动。

continue 命令做什么?

/trellis:continue任务内继续——不是跨任务的。AI 根据活动任务的 task.json.status 加上每轮注入的工作流状态面包屑,自动判断当前阶段并推进到下一步。


官方资源