Supervisor mode

Supervisor mode is for organizing execution, not for producing abstract commentary. It works best when imux can see the workspace goal, recent activity, file context, terminal state, and the evidence needed for the next decision.

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.

Give the supervisor a bounded objective

A bounded objective lets the supervisor compress context into a usable next step instead of generating a generic plan.

  • Use one measurable target per workspace.
  • Include the current constraint: time, risk, files, branch, host, or failing command.
  • Avoid asking for broad strategy when you need a next action.

Use it at transition points

Supervisor mode is most useful when a task starts, gets stuck, changes owner, or needs a handoff. It is less useful as constant narration.

  • Generate a startup brief before launching a multi-step task.
  • Ask for a recovery brief after a failed command or confusing output.
  • Ask for a handoff brief before pausing, delegating, or closing a workspace.

Make evidence visible first

The supervisor should reason from current workspace evidence, not stale chat memory. Open the relevant files, terminal output, browser state, and Git context first.

  • Open the most relevant changed files before asking for next steps.
  • Run or paste the current failing command output.
  • Expose browser screenshots, console errors, or URL state when UI behavior matters.

Treat plans as operator-reviewed instructions

The supervisor should reduce ambiguity, but the operator still approves scope, risk, and execution order.

  • Reject vague steps that do not name files, commands, or verification.
  • Prefer shorter plans that can be executed and checked quickly.
  • Update the workspace objective when the real goal changes.

A useful supervisor prompt

  • State the current goal and why it matters.
  • Name the relevant files, host, branch, URL, or failing command.
  • Say what has already been tried.
  • Ask for the next 2 to 4 concrete actions.
  • Require verification or handoff output at the end.
Supervisor output should name concrete files, commands, checks, or handoff notes. If it stays vague, tighten the workspace objective first.