Team
Cut Claude Code's own token consumption by up to 99% — delegate the heavy lifting to free opencode agents, keep Claude in the reviewer's or manager's seat.
npx -y skills add xWael9/ClaudeBoss --skill teamAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Delegate a task to a free opencode agent, wait for its output, then review and implement it together with the user. Use when the user says "team mode", "/claudeboss:team", or wants Claude Code and opencode working as a pair on a task.
SKILL.md
2.5 KB, as published. Nobody here has run it
ClaudeBoss — Team Mode
You (Claude Code) and a free opencode agent work as a pair on one task. Opencode does the first pass; you review it like a second engineer would, then implement/finish it yourself.
Drift-prone. Free model catalogs (OpenCode Zen, OpenRouter) change without notice. Model selection happens live via
opencode modelsevery run — never assume a specific model id still exists.
Prerequisites
Run once per machine: claudeboss install — checks/installs the opencode CLI, verifies a free model is reachable, and prints manual OpenRouter fallback steps if not (no automated account creation, by design).
Workflow
-
Classify the task into one of:
code,write,research,general(use/claudeboss:planinstead, first, if the task itself is "figure out the right approach"). Coding tasks (features, fixes, refactors) →code. Prose/docs/copy →write. Fact-finding/comparison →research. Anything else →general. -
Delegate. Run:
claudeboss run <task-type> "<precise task description — same detail you'd give a human contractor>"This is a blocking call — wait for it to return, don't poll.
-
Review the output like a code review, not a rubber stamp. Check:
- Does it actually satisfy the request, not just look plausible?
- Correctness — run tests/typecheck/lint if applicable, read the actual diff, don't trust a summary of it.
- Fit with the existing codebase's conventions.
-
Implement. You apply the result yourself — edit files with Edit/Write, run verification (tests, the
runskill, a browser check for UI), and fix anything opencode got wrong or left incomplete. Treat its output as a first draft from a teammate, not a final answer. -
If opencode's draft is unusable (wrong approach, missed the point), don't loop forever — after 2 failed delegations, tell the user directly and offer to just do the task yourself. Free models are weaker than you; don't over-trust them on hard problems.
What this mode is NOT
Not autonomous. You still show your work and changes to the user like any other task. Team mode changes who writes the first draft, not the review/verification bar.