监督器模式
监督器模式用于组织执行，不是生成抽象评论。当 imux 能看到工作区目标、最近活动、文件上下文、终端状态和下一步决策所需证据时，它效果最好。
Goal:
Ship the failing login-form fix in this repo without changing unrelated UI.
Context:
- Branch: fix/login-form
- Relevant files: app/login/page.tsx, app/api/session/route.ts
- Current failure: npm test -- login-form
Ask:
Turn the visible workspace context into the next 2-4 concrete actions.
Include verification and handoff output.给监督器一个边界明确的目标
边界明确的目标能让监督器把上下文压缩成可用下一步，而不是生成通用计划。
- 每个工作区只使用一个可衡量目标。
- 补充当前约束：时间、风险、文件、分支、主机或失败命令。
- 如果你需要的是下一步动作，就不要要求宽泛战略。
在转换点使用它
监督器最适合任务开始、卡住、换负责人或需要交接时使用。它不适合变成持续旁白。
- 多步骤任务开始前生成启动简报。
- 命令失败或输出混乱后请求恢复简报。
- 暂停、委派或关闭工作区前请求交接简报。
先让证据可见
监督器应基于当前工作区证据推理，而不是旧聊天记忆。先打开相关文件、终端输出、浏览器状态和 Git 上下文。
- 请求下一步前先打开最相关的改动文件。
- 运行或粘贴当前失败命令输出。
- 如果问题和 UI 有关，暴露浏览器截图、控制台错误或 URL 状态。
把计划当作需要操作者审查的指令
监督器应该减少歧义，但范围、风险和执行顺序仍由操作者确认。
- 拒绝不命名文件、命令或验证方式的模糊步骤。
- 优先使用可以快速执行和检查的短计划。
- 当真实目标变化时更新工作区目标。
有用的监督器提示词
- 说明当前目标以及为什么重要。
- 命名相关文件、主机、分支、URL 或失败命令。
- 说明已经尝试过什么。
- 要求给出接下来 2 到 4 个具体动作。
- 要求最后提供验证或交接输出。
Supervisor output should name concrete files, commands, checks, or handoff notes. If it stays vague, tighten the workspace objective first.