name: start description: “启动会话”
启动会话
初始化您的AI开发会话并开始处理任务。
操作类型
| 标记 | 含义 | 执行者 |
|---|---|---|
[AI] |
由AI执行的Bash脚本或工具调用 | 您（AI） |
[USER] |
用户执行的技能 | 用户 |
初始化 [AI]
步骤1：理解开发工作流
首先，阅读工作流指南以理解开发过程：
cat .trellis/workflow.md
遵循workflow.md中的指令 - 它包含：
- 核心原则（先读后写、遵循标准等）
- 文件系统结构
- 开发过程
- 最佳实践
步骤2：获取当前上下文
python3 ./.trellis/scripts/get_context.py
这显示：开发者身份、git状态、当前任务（如果有）、活动任务。
步骤3：阅读指南索引
cat .trellis/spec/frontend/index.md # 前端指南
cat .trellis/spec/backend/index.md # 后端指南
cat .trellis/spec/guides/index.md # 思考指南
步骤4：报告并询问
报告您学到的内容并询问：“您想处理什么？”
任务分类
当用户描述一个任务时，对其分类：
| 类型 | 标准 | 工作流 |
|---|---|---|
| 问题 | 用户询问代码、架构或工作原理 | 直接回答 |
| 琐碎修复 | 拼写错误修复、注释更新、单行更改、< 5分钟 | 直接编辑 |
| 开发任务 | 任何代码更改：修改逻辑、添加功能、修复错误、涉及多个文件 | 任务工作流 |
决策规则
如有疑问，使用任务工作流。
任务工作流确保规范被注入到正确的上下文中，从而产生更高质量的代码。 开销最小，但好处显著。
问题 / 琐碎修复
对于问题或琐碎修复，直接处理：
- 回答问题或进行修复
- 如果代码被更改，提醒用户运行
$finish-work
任务工作流（开发任务）
为什么使用此工作流？
- 在编码前进行专门的研究通行证
- 在jsonl上下文文件中配置规范
- 使用注入的上下文实现
- 通过单独的检查通行证验证
- 结果：自动遵循项目约定的代码
步骤1：理解任务 [AI]
在创建任何内容之前，理解用户想要什么：
- 目标是什么？
- 开发类型？（前端 / 后端 / 全栈）
- 任何特定要求或约束？
如果不清楚，询问澄清问题。
步骤2：研究代码库 [AI]
运行一个专注的研究通行证并产生：
.trellis/spec/中的相关规范文件- 要遵循的现有代码模式（2-3个示例）
- 可能需要修改的文件
- 建议的任务缩写
使用此输出格式：
## 相关规范
- <路径>: <为什么相关>
## 找到的代码模式
- <模式>: <示例文件路径>
## 要修改的文件
- <路径>: <什么更改>
## 建议的任务名称
- <短缩写名称>
步骤3：创建任务目录 [AI]
基于研究结果：
TASK_DIR=$(python3 ./.trellis/scripts/task.py create "<研究中的标题>" --slug <建议的缩写>)
步骤4：配置上下文 [AI]
初始化默认上下文：
python3 ./.trellis/scripts/task.py init-context "$TASK_DIR" <类型>
# 类型: backend | frontend | fullstack
添加在研究通行证中找到的规范：
# 对于每个相关规范和代码模式：
python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" implement "<路径>" "<原因>"
python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "<路径>" "<原因>"
步骤5：编写需求 [AI]
在任务目录中创建 prd.md，内容如下：
# <任务标题>
## 目标
<我们试图实现什么>
## 要求
- <要求 1>
- <要求 2>
## 接受标准
- [ ] <标准 1>
- [ ] <标准 2>
## 技术说明
<任何技术决策或约束>
步骤6：激活任务 [AI]
python3 ./.trellis/scripts/task.py start "$TASK_DIR"
这设置 .current-task，以便钩子可以注入上下文。
步骤7：实现 [AI]
实现 prd.md 中描述的任务。
- 遵循所有注入到实现上下文中的规范
- 将更改范围保持在要求内
- 在完成前运行代码检查和类型检查
步骤8：检查质量 [AI]
针对检查上下文运行质量通行证：
- 根据规范审查所有代码更改
- 直接修复问题
- 确保代码检查和类型检查通过
步骤9：完成 [AI]
- 验证代码检查和类型检查通过
- 报告实现了什么
- 提醒用户：
- 测试更改
- 准备就绪时提交
- 运行
$record-session记录此会话
继续现有任务
如果 get_context.py 显示当前任务：
- 阅读任务的
prd.md以理解目标 - 检查
task.json获取当前状态和阶段 - 询问用户：“继续处理 <任务名称>？”
如果是，从适当的步骤（通常是步骤7或8）恢复。
技能参考
用户技能 [USER]
| 技能 | 何时使用 |
|---|---|
$start |
开始会话（此技能） |
$finish-work |
在提交更改前 |
$record-session |
完成任务后 |
AI脚本 [AI]
| 脚本 | 目的 |
|---|---|
python3 ./.trellis/scripts/get_context.py |
获取会话上下文 |
python3 ./.trellis/scripts/task.py create |
创建任务目录 |
python3 ./.trellis/scripts/task.py init-context |
初始化jsonl文件 |
python3 ./.trellis/scripts/task.py add-context |
添加规范到jsonl |
python3 ./.trellis/scripts/task.py start |
设置当前任务 |
python3 ./.trellis/scripts/task.py finish |
清除当前任务 |
python3 ./.trellis/scripts/task.py archive |
归档已完成任务 |
工作流阶段 [AI]
| 阶段 | 目的 | 上下文源 |
|---|---|---|
| research | 分析代码库 | 直接仓库检查 |
| implement | 编写代码 | implement.jsonl |
| check | 审查和修复 | check.jsonl |
| debug | 修复特定问题 | debug.jsonl |
关键原则
规范被注入，而非记住。
任务工作流确保代理自动接收相关规范。 这比希望AI“记住”约定更可靠。