菜单、模型和 Agent 随客户端版本与企业配置变化。Supervisor 需在 CLI 中使用，见 CLI 场景示例。

当前示例按以下 9 个场景展开，后面的任务模板和产品选择表属于补充内容：

1. 用 /init 接入一个新项目
2. Plan → Manual / Auto / Trust 执行一个中型需求
3. 用 Auto 自动完成低风险测试修复
4. 在隔离 Worktree 中使用 Trust
5. 用 Spec 推进大型变更
6. 用 Goal 持续修复直到验证通过
7. 后台启动开发服务器并观察日志
8. 用 /btw 处理旁支问题
9. 提交前做一次 Review

场景一：用 /init 接入一个新项目

首次在仓库中使用 Studio 或项目规则过期时，先运行 /init，核对目录、启动命令和测试方式。

1. 在工作区侧栏点击 添加工作区，选择项目根目录。
2. 新建一个 Code 会话，先检查当前目录、分支和 Git 状态。
3. 在 Composer 输入 /，从 Engine 命令列表选择 init 并发送；如果菜单没有该命令，直接发送这段任务描述。
4. 只更新 AGENTS.md，再用一个只读问题核对项目结构。

如果需要补充项目规则，再发送：

请阅读当前项目，说明主要模块、启动命令、测试命令和开发注意事项。
只修改 AGENTS.md，不修改业务代码；不确定的内容标记为待确认。

• 项目目录会保存在工作区历史中，可从同一目录继续会话。
• 生成 AGENTS.md 后，核对项目结构和命令。
• 会话、文件上下文、Git 状态和 Terminal 都绑定到当前工作区。

如果项目根目录、包管理器或测试命令识别错误，先修正规则文件，不要继续执行代码改动。

Studio 的 / 菜单会显示当前可用命令。如果没有 /init，直接发送上面的任务描述即可。

场景二：Plan → Manual / Auto / Trust 执行一个中型需求

需求跨越多个文件、但还不需要建立长期规格时，先确认影响范围、风险和验证方式。

1. 在 Composer 的运行模式菜单选择 Plan。
2. 发送只读需求，要求列出文件清单、接口兼容风险、测试方式和回滚点。
3. 在计划审批卡中检查步骤和风险，选择 Manual 或 Auto 进入实施；需要调整方案时选择 Continue planning。
4. 若实施阶段需要 Trust，再从运行模式菜单选择 Trust 并确认。在约定范围内完成修改，运行测试并在 Review 中检查改动。

请为“新增用户导出功能”制定实施计划。
先只读分析，不要修改文件。计划列出会改哪些文件、接口兼容风险、测试方式和回滚方案。
确认计划后再执行；不要修改数据库迁移和部署配置。

# 新增用户导出功能

- [ ] 增加导出接口与权限校验
- [ ] 增加用户列表导出入口
- [ ] 验证兼容性并确认回滚点

• Plan 卡显示可审查的步骤、进度和原始计划。
• 按审批卡中的选择，Composer 进入 Manual 或 Auto；Trust 可在实施前另行选择并确认。
• 改动、测试和 Review 都留在同一个 Studio 会话中。

如果计划发现需要改数据库结构、权限模型或外部接口，先扩大评审范围，不要直接批准实施。

场景三：用 Auto 自动完成低风险测试修复

测试命令明确、修改范围可控时，可减少读取、搜索和普通测试的逐项确认。

1. 先在 Manual 或 Plan 下确认项目目录、测试命令和允许修改的范围。
2. 点击 Composer 的运行模式胶囊，选择 Auto。
3. 明确允许修改的目录和禁止操作，先运行相关测试，再修复失败项。
4. 测试通过后切回 Manual，在 Review 中检查最终 Diff。

运行当前表单模块的测试并修复失败用例。
只修改 src/forms 和对应测试，不改依赖、部署配置、密钥和数据库迁移。
每轮修复后运行 npm test -- form；如果需要扩大范围，先暂停并说明原因。

读取 CI 配置 · 86 lines

找到 3 个失败用例

16 passed · 0 failed

检测到敏感配置写入 · tool-error

• 读取 CI 配置、搜索失败日志和运行普通测试会标记为“Auto · 自动通过”，并连续推进。
• 破坏性或敏感操作会显示“安全分类器拦截”，不会继续执行；Agent 的主动提问不会由 Auto 自动代答。
• 需要处理被拦截的操作时，切回 Manual 或根据实际权限策略重新判断；完成后在 Review 中核对全部改动。

出现数据破坏可能、需要修改依赖或部署文件，或测试结果不稳定时，关闭 Auto 并人工判断。

Auto 受 Engine 的权限规则、安全分类和会话状态约束；如果 Engine 提供 /auto，也可以从 Composer 的命令菜单执行。

场景四：在隔离 Worktree 中使用 Trust

临时隔离目录需要连续运行大量可回滚操作，且已确认目录不含生产凭据、客户数据或其他不可恢复内容时，才使用 Trust。

1. 在 Composer 底部打开环境菜单，确认当前是本地根目录还是 Worktree。
2. 在支持的 Engine 上选择 创建 Worktree，等待创建完成并切换到新目录。
3. 在目标目录新建或选择会话，重新说明任务目标和限制，并检查路径、分支、凭据和 Git 状态。
4. 在运行模式菜单选择 Trust，阅读确认对话框并确认。
5. 任务完成后切回 Manual，检查 Review 和测试结果。

在当前临时 Worktree 中完成迁移脚本重构。
只修改 src/migrations，不提交、不推送、不访问生产凭据；遇到删除数据、改部署或访问项目外路径时立即停止。

• Worktree 与本地根目录在 Studio 中作为独立环境显示。
• Trust 确认后减少常规权限询问，切换到 Worktree 后，应在该目录新建会话或选择已有会话继续。
• 任务结束后切回 Manual，在 Review 中检查改动。

目录不可回滚、发现 .env 或客户数据、需要生产访问，立即关闭 Trust 并回到 Manual。

如果环境菜单没有“创建 Worktree”，请先确认当前版本和项目是否支持。切换目录不会自动复制当前会话上下文；进入新目录后，重新说明任务目标和限制。

场景五：用 Spec 推进大型变更

变更跨越多个能力、需要记录背景、需求场景、设计取舍和实施任务时，使用 Spec。

1. 在 Composer 的更多菜单选择 规格进展；也可以单独执行 /spec。选中后，Composer 会显示可关闭的“规格进展”标签。
2. 只读检查现有实现和测试，确认变更原因、范围、代码依据和边界。
3. 在项目总览查看“正在进行的变更”：阶段只会是 提案中 / 实施中 / 可归档；需求墙按 ADDED、MODIFIED、REMOVED、RENAMED 显示 delta 类型和场景数量，任务进度单独取自 tasks.md。
4. 在项目工作区检查 specs/changes/<slug>/ 下的 proposal.md、可选的 design.md、tasks.md 和 deltas/<capability>/spec.md。
5. 阅读方案和验收条件。需要调整时直接说明；确认无误后，在会话中回复“可以实施，按这个方案开始吧”。
6. 收到确认后，阶段进入“实施中”，按 tasks.md 修改业务代码并逐项勾选；全部完成后进入“可归档”。
7. 点击 Composer 中“规格进展”标签的关闭按钮，或执行 /unspec 结束工作流。已有规格文件会保留，权限模式不会被自动切换。

从更多菜单选择“规格进展”，或等待 /spec 命令执行成功后，再单独发送：

请为“登录失败后的设备绑定恢复”创建规格驱动变更。
先只读检查现有登录、设备绑定和错误提示实现，说明变更原因、范围、代码依据和边界；
然后整理 specs/changes/device-binding-recovery/，至少包含 proposal.md、tasks.md，
以及 deltas/authentication/spec.md。需求覆盖登录失败、恢复绑定、重复提交和旧设备状态。
先给出方案和验收条件，问我是否可行；等我回复“可以实施”后，再修改业务代码。

• Composer 明确显示“规格进展”工作流标签，权限模式仍独立存在。
• 项目总览显示当前阶段、变更原因和范围、需求墙、任务完成数和下一步。
• 项目工作区留下可评审的提案、需求 delta 和任务清单；评审通过后按任务清单实施。

无法从代码和测试确认关键事实时，停在分析或提案阶段，不要用猜测填充规格。

规格进展选择按当前会话保存；点击工作流标签的关闭按钮或执行 /unspec 后，项目中的 specs/changes 文档会保留。

场景六：用 Goal 持续修复直到验证通过

需要多轮运行测试、定位问题和修复，并固定目标、命令和边界时，使用 Goal。

1. 先进入已有的 Code 会话，在 Composer 输入 /goal 和持续目标；也可点击“更多 → 目标”，在预填命令后补充目标再发送。
2. 写出完成标准、验证命令、禁止事项和停止条件。
3. 在 Goal 条中查看进度，需要人工判断时选择暂停；条件满足后清除 Goal。
4. 在同一会话中继续修改和验证，最后打开 Review。

/goal 持续修复当前分支的 TypeScript 和单元测试问题，直到 npm test 通过。
不要提交代码；不改数据库迁移；如果连续两轮没有进展就暂停并报告。

可用命令：/goal status、/goal pause、/goal resume、/goal clear。

• Goal 条显示目标、状态和当前轮次。
• 可以从 Studio 直接暂停、恢复或清除目标。
• 多轮执行的 Todo、工具活动和最终改动都留在当前会话中。

测试命令不稳定、连续轮次没有进展、需要扩大修改范围或出现危险操作时暂停。

Goal 条显示当前轮数和最大轮数，但不能手动设置最大轮数。单独发送 /goal 会查询状态；创建目标时要在命令后写出目标内容。

场景七：后台启动开发服务器并观察日志

需要 dev server、watcher 或长时间测试，同时继续处理主会话中的分析和修改时，将任务放到后台运行。

1. 在右侧打开 Terminal，创建或切换一个 PTY，运行开发服务器或测试。
2. 如果 Agent 启动了后台 Shell 或 Monitor，切换到 Tasks 面板。
3. 展开任务卡查看命令、输出、类型、执行次数和运行结果。
4. 发现错误后回到主会话定位，不要反复启动相同服务。
5. Terminal 中启动的服务可在对应终端按 Ctrl+C 停止；Agent 启动的后台任务从 Tasks 卡片停止，再确认端口已经释放。

npm run dev
npm test -- checkout

• 多个 PTY 可以并存，收起 Terminal 或切换页签不会中断进程。
• Tasks 显示后台 Shell / Monitor 的实时输出和最终状态。
• 运行中的任务可以从任务卡停止，已退出任务保留结果供复查。

日志持续增长、进程失控、端口冲突或服务访问真实数据时，立即停止并人工检查。

CLI 的 /bashes 在 Studio 中对应 Tasks 面板，可查看输出和停止任务。Tasks 不提供 Supervisor 功能，也不会自动按日志标记重试。

场景八：用 /btw 处理旁支问题

主任务进行中，临时需要解释一个错误码、函数或设计背景，不希望重置主线或污染主会话上下文。

1. 在当前会话的 Composer 输入 /btw 和问题。
2. 在 btw 窗口中阅读回答；需要继续追问就在窗口内发送。
3. 关闭 btw 后回到原会话，主任务的计划、改动和上下文保持不变。

/btw 这个项目里的 RetryableError 和 FatalError 有什么区别？只解释，不修改文件。

• btw 窗口显示独立的问答记录。
• 主会话不会新增这条问题，也不会为旁路问题调用工具。
• 关闭窗口后可以继续原来的 Composer 任务。

如果旁支问题需要改代码、运行破坏性命令或改变主任务范围，回到主会话重新提出，并先更新计划。

/btw 是 Studio 本地命令，问题长度和历史条数有上限；它适合解释和澄清，不适合执行任务。

场景九：提交前做一次 Review

代码已修改，准备提交、合并或创建 PR，需要先检查文件范围、Diff、测试和敏感信息。

1. 打开右侧 Review 工作台，先看 Uncommitted，再看 Last turn。
2. 展开文件，检查增删统计、逐段 Diff 和是否混入其他会话或手工改动。
3. 在 Composer 中补充测试或审查要求；如果 Engine 提供 review 命令，也可以从 / 菜单执行 /review。
4. 按优先级处理问题，重新运行测试、构建或相关检查。
5. 确认无误后提交所选路径；需要丢弃改动时先确认范围，再使用 Discard all。

请只修改 checkout 模块，完成后列出改动文件和验证命令；我会在 Review 中检查后再提交。

• Review 同时提供 Uncommitted 与 Last turn 两个范围。
• 可以查看文件 Diff、增删行数，并选择要提交的路径。
• 测试和人工检查通过后，再决定是否 commit、push 或创建 PR。

审查发现改动范围失控、测试未通过或包含敏感信息时，不要提交，先回到 Plan 或 Manual 处理。

Review 面板支持查看和提交改动，Push 和 GitHub PR 需通过其他工具完成。Discard all 可能不可恢复，执行前必须确认未包含手工改动。

Studio 任务提示词模板

在 Composer 开始较长任务前，先在工作区或环境菜单选择目标目录，再写清目标、允许修改的范围和验证方式。遇到超出范围或无法验证的情况，暂停处理。复制这段内容到 Composer，再替换为当前任务的信息：

目标：修复 checkout 模块的表单校验失败
工作区或 Worktree：当前项目的 checkout-fix Worktree
允许修改：src/checkout/ 和对应测试文件
禁止修改：依赖、部署配置、密钥、数据库迁移
验证命令：npm test -- checkout
完成标准：相关测试通过，Review 中只有 checkout 文件发生改动
停止条件：需要扩大目录、修改依赖，或测试连续两轮没有进展
是否允许提交：否

Studio 与 CLI 的选择