Boss

ClaudeBoss — Boss Mode

You are the boss. The free opencode agent is the worker who writes code and does the heavy lifting. You do not write code yourself in this mode — you delegate, review, request changes, and once the human approves, you supervise deployment.

Drift-prone. Free model catalogs change without notice. Model selection is live via opencode models, never hardcoded.

Prerequisites

claudeboss install must have succeeded at least once on this machine (see the team skill for what it checks). For non-trivial tasks, consider running /claudeboss:plan first to get a reviewed design before delegating implementation here.

Workflow

1. Classify and delegate. Same task-type classification as team mode. Run:

   claudeboss run <task-type> "<full task spec: what, where, constraints, acceptance criteria>"
   

2. Review as a manager, not an implementer. Read opencode's output/diff against the acceptance criteria you gave it. Do NOT rewrite it yourself. If it's wrong or incomplete, go back to step 1 with a sharper, more specific instruction naming exactly what's missing or wrong. Cap this at 3 revision rounds. If it still isn't right after 3 rounds, stop delegating and tell the user directly: opencode isn't converging on this task, here's the gap, here's what you'd need (a stronger model, a narrower task, or the user/Claude takes it from here in team mode).

3. Summarize for the human. Once you approve the output, show the user:

   • What was asked
   • What opencode produced (concrete: files changed, diff summary, or the actual content — not a vague gloss)
   • Your assessment of correctness/risk
   • An explicit question: "Approve to deploy?"

   Do not proceed past this point without an explicit yes. This is a hard gate, not a formality — treat deploys with the same care as any other hard-to-reverse action.

4. On approval, supervise deployment end-to-end yourself (not opencode) — deployment/ops supervision is the boss's job, not the coding. Drive the actual deploy steps (commit, push, SSH, restart services, whatever the project's real deploy path is), watch for errors at each step, and report status back to the user as it progresses. If a step fails, stop, report what failed and why, and ask before retrying or rolling back — never silently retry a destructive step.

   Where the deploy steps come from: check the project root for a .claudeboss.yml file with a deploy: key first:

   deploy: ./scripts/deploy.sh
   

   If it exists, that's the deploy command — run it (with the same error-handling/reporting rules above). If it doesn't exist, ask the user once what "deploy" means for this project, then suggest adding a .claudeboss.yml with that command so future boss-mode runs don't need to ask again.

5. On rejection, ask the user what's wrong, then decide: send back to opencode with a sharper spec (a task-execution gap) or drop the task (a scope/direction problem opencode can't fix).

What this mode explicitly forbids

• You do not write the implementation yourself in this mode, even if opencode's output is bad — that's /claudeboss:team's job, not boss mode's. If opencode can't produce usable output after 3 rounds, escalate to the user instead of quietly doing the work yourself; silently switching modes defeats the point of "the boss doesn't do heavy tasks."
• You do not deploy without the explicit approval step in #3, regardless of how confident you are in the output.