Colin’s dotfiles

Personal dotfiles plus a batteries-included Claude Code config for shipping software with AI agents — slash commands for review, planning, and merging; skills for platform CLIs and common frameworks; and a multi-model review and audit toolkit (MBOT) that runs the same diff past Opus, GPT, Gemini, and friends in parallel.

Highlights

• Code review workflows. /colin-review runs a focused single-agent review, while /colin-ultra-review fans out across MBOT models and roles, dedupes findings, and posts inline comments on GitHub PRs or GitLab MRs.
• Spec critique and group decisions. /colin-critique and the MBOD debate skill stress-test plans before you write code.
• Production-readiness audit. /colin-ultra-audit runs three roles (hardening, operability, stewardship) against the current repo state, grouped by severity.
• Boring shell quality of life. Sensible Bash, Git, tmux, Vim, Delta, and Starship configs with non-clobbering installs for .bashrc and .gitconfig.
• Yours to configure. Models, harnesses, and providers come from plain-prose Markdown profiles you own.

Contents

• Quickstart
• Uninstalling
• What gets installed
• Shell helpers
• VS Code dev containers
• AI tools reference
  • Plugins
  • Agents
  • Slash commands
  • Skills
  • Using MBOD
  • Customizing MBOT
  • Typical flows
• License

Quickstart

Clone the repo and run install.sh. The script never overwrites .bashrc or .gitconfig — it appends an include directive so the .colin variants load alongside whatever you already have.

git clone https://github.com/colinmollenhour/dotfiles.git ~/.dotfiles
cd ~/.dotfiles

# Interactive — choose what to install
./install.sh

# Install everything
./install.sh --all

# Install only the AI agent configs
./install.sh --agents

# Install only the dotfiles
./install.sh --dotfiles

# Install only the standalone CLIs (snip-upload) to ~/.local/bin
./install.sh --bins

# Everything except the CLIs
./install.sh --all --no-bins

# Show every flag
./install.sh --help

First-time install on an existing system — if destination files already exist, an interactive run lets you keep, overwrite, back up, or diff each conflict. You can also keep or overwrite all remaining conflicts. Non-interactive runs skip conflicting files; pass --force to overwrite them all:

./install.sh --all --force

Subsequent runs are safe without --force: the script tracks which files it installed and their hashes, so it only updates files it owns that haven’t been manually changed. Copied files retain the repository source’s modification time, making a destination with a newer mtime an easy visual indicator that it was subsequently saved by a user; hashes remain the authoritative conflict check.

After installation, run colin-help for the cheat sheet of aliases, shortcuts, and tools. The same content lives at the top of .bashrc.colin.

Plugin and skills installation

For Claude Code, install only the plugins you want:

/plugin marketplace add colinmollenhour/dotfiles
/plugin install whiteboard@colin-dotfiles
/plugin install colin-shipping@colin-dotfiles
/plugin install megamind@colin-dotfiles
/plugin install colin-frameworks@colin-dotfiles
/plugin install colin-visuals@colin-dotfiles

Megamind declares colin-shipping as a dependency, and shipping declares colin-cli-bridges. Claude Code installs those dependencies automatically. Whiteboard is independent: it bundles its Node server, template, styles, and browser scripts, and needs Node.js 20 or newer. Publishing a board also needs the optional snip-upload CLI (./install.sh --bins); drawing and serving boards do not.

Plugin skills use a namespace: /colin-shipping:colin-review, /megamind:megamind, and /whiteboard:whiteboard. Personal skills installed by install.sh or the skills CLI keep their short names, such as /colin-review. Choose one route per host to avoid duplicate skills.

For Codex, OpenCode, and other supported agents, use the skills CLI:

npx skills add colinmollenhour/dotfiles --list
npx skills add colinmollenhour/dotfiles -g --skill whiteboard
npx skills add colinmollenhour/dotfiles -g --all

# Optional: settings, native agents, and Pi/OMP integration, without skill mirrors
./install.sh --agents --no-skills

The skills CLI installs skills, not Claude plugin agents or dependency manifests. When selecting individual skills, also select the helpers a workflow calls: Megamind uses MBOT/MBOD, the PR/MR and educational brief skills, and the CLI bridge skills. MBOD needs MBOT beside it for helper scripts.

full-send takes a change through verification, MBOT code review, a PR/MR, CI and review feedback, and a protected merge. full-stop runs the same workflow but leaves the request open for you to merge, with automatic merge and queue/train enrollment off. modernize checks whether an old PR/MR still solves a useful problem before rebasing it; it can recommend rework or closure without performing either. These workflows are explicit invocations and support GitHub and GitLab.

For an individual skills CLI install, full-stop needs full-send; full-send needs modernize, MBOT/MBOD, colin-mr-description, educational-brief, the matching gh-cli/glab-cli, and the CLI bridge skills selected by your MBOT profile. modernize uses MBOD for disputed decisions. colin-fix-comments, colin-fix-pipeline, and colin-review-merits are optional helpers; the new workflows include guidance for when those are absent. No tstack-only helpers or T3 Code tools are required. The three adapted skills retain Theo Browne’s MIT license and upstream revision.

install.sh --agents remains a complete personal installation route: it copies every plugin’s skills into ~/.claude/skills and ~/.agents/skills (plus ~/.gemini/antigravity-cli/skills when ~/.gemini/antigravity-cli is present), installs native agents/settings, and sets up helper CLIs and the optional whiteboard user service. --no-skills skips the skill copies and their CLI/service setup; it preserves existing copies. Remove old copies with the installer that owns them before switching routes (./uninstall.sh --agents for dotfiles, or npx skills remove for the skills CLI). The dotfiles uninstaller does not remove marketplace plugins; use /plugin uninstall for those.

Uninstalling

Uninstalling is fast and clean. To remove installed dotfiles, agent configs, and shell/git includes:

# Interactive — choose what to remove
./uninstall.sh

# Remove everything installed
./uninstall.sh --all

# Remove only AI agent configs
./uninstall.sh --agents

# Remove only dotfiles
./uninstall.sh --dotfiles

# Show every flag
./uninstall.sh --help

uninstall.sh reads the manifest written during installation (~/.local/share/colin-dotfiles/manifest) to safely remove installed files, clean up empty created directories, restore settings backups, and revert the include and source directives in .gitconfig and .bashrc. Files modified since installation are preserved unless you pass --force.

What gets installed

Dotfiles

The installer tracks every file it owns in ~/.local/share/colin-dotfiles/manifest. On each run it:

• Prompts on conflicts in a TTY, with options to keep, overwrite, back up, or view a unified diff.
• Skips conflicting files in non-interactive runs and warns you (use --force to overwrite anyway).
• Deletes installed files whose source was removed from the repo, but only if you haven’t modified them locally. A local copy that no longer matches the last-install hash (for example the clickup skill refreshed by cup skill) is left in place and dropped from the manifest so later runs do not keep warning about it.

Running ./uninstall.sh uses this same manifest to cleanly undo installation at any time.

Claude Code config

Skills from plugins/*/skills/, agents, and Claude settings install into ~/.claude/. The --agents flag also mirrors skills into the shared ~/.agents/skills/ directory used by Codex and OpenCode, and into ~/.gemini/antigravity-cli/skills/ when ~/.gemini/antigravity-cli is present. Workflows that used to live in .claude/commands/ are skills now; leftover copies under ~/.claude/commands and ~/.opencode/commands are deleted on install. Side-effect skills (/colin-review, /megamind, commit/push/cleanup, and similar) set disable-model-invocation: true so they only run when you type /name. Library skills (gh-cli, many-brain-one-task, ORM/docs helpers) set user-invocable: false so they stay off the / menu. Claude settings.json / settings.local.json are merged in place and rewritten only when the merge actually changes the file.

CLIs

--bins installs standalone tools from bin/ into ~/.local/bin, and --all includes them unless you pass --no-bins. An interactive run asks about each one. ./uninstall.sh --bins removes them.

• snip-upload — Upload a file or the clipboard to an S3-compatible bucket and print a public URL, with a random suffix so the URL can’t be guessed. Images are converted to WebP. Needs bun.
  • snip-upload auth sets up the bucket interactively. It walks you through creating a Tigris bucket (public, directory listing off, optionally a lifecycle rule that expires old snips) and an access key scoped to that bucket. It then checks the keys with a test upload and public read, confirms the bucket can’t be listed publicly, and writes ~/.local/colin/snips.json with 0600 permissions. An interactive install offers to run it, and an upload with no config prompts for it.
  • snip-upload auth status [--verify] shows the configured bucket without revealing the secret, and exits 3 when nothing is configured. --verify runs the live check. Agents use it as a preflight (the whiteboard skill does before publish).
  • snip-upload , snip-upload xclip, snip-upload wslclip — see snip-upload --help.

Shell helpers

• colin-help — list every alias, command, and tip.
• note [text] — display a styled terminal sticky note, prompting for its contents when text is omitted.
• install-recommended, install-packages, update-packages — package installers backed by brew, npm, apt, and raw curl | bash.
• Fuzzy finders for files, Git branches, Docker containers, processes to stop, SSH hosts, exported variables, and unset variables.

VS Code dev containers

Drop this into your settings.json to auto-install on every dev container:

{
  "dotfiles.repository": "colinmollenhour/dotfiles",
  "dotfiles.targetPath": "~/.dotfiles",
  "dotfiles.installCommand": "~/.dotfiles/install.sh --all"
}

---

AI tools reference

A reference to the skills and agents in plugins/ and .opencode/agents/. The examples below use personal skill names; Claude plugin installs prefix them with their plugin name (for example /colin-shipping:colin-review). Skills load automatically when relevant or you can name them in a prompt.

Concepts

• Slash commands (/name) kick off workflows. You type them.
• Skills are reusable procedures Claude loads on demand, often invoked internally by commands.
• MBOT agents are dedicated subagents backed by specific models. The review, critique, audit, and MBOD commands use them to gather multi-model opinions. Which models run, and through which harness, is driven by MBOT-style profile files — see Customizing MBOT.

Plugins

The plugin directories are the canonical skill sources. Marketplace entries use paths relative to the repository root, such as ./plugins/whiteboard. Each plugin can be copied on its own; its scripts and assets stay inside that directory. MBOT and MBOD share one plugin because MBOD calls sibling MBOT helpers.

Agents

megamind

megamind is the autonomous large-task delivery agent. Give it an objective, spec, issue, task URL, or plan file, and it drives the work from intake to delivery with only one optional human checkpoint: review after a non-unanimous MBOD decision.

At a high level, it:

• Resolves the task source, records repo context, and creates a durable .tmp/megamind-/ run directory for plans, critiques, decisions, agent reports, reviews, CI logs, and final delivery notes.
• Uses MBOT to critique the starting plan, then produces a refined implementation plan. If the plan has unresolved choices, it bundles them into one MBOD decision round, asks for human review only when the MBOD result is not unanimous, and folds the result into plans/final.md.
• Splits implementation into one to three disjoint work packages, creates the feature branch before implementation, launches coding agents, inspects their reports and diffs, runs integration checks, and commits each work package once its checks pass.
• Runs repository-aware ultra-review discovery across state/lifecycle, contracts/integration, and failure/security; validates every candidate against source evidence; performs whole-change convergence rounds; assigns fix work; and rechecks both the fix delta and final branch state. Megamind’s Roborev integration is disabled by default. With --roborev, Megamind checks whether the repo is already enrolled, uses the existing daemon integration to review milestone commits, and drains failing reviews before the ultra review and after fix rounds.
• Runs final local gates, optionally drains remaining Roborev reviews when --roborev is active, pushes the branch’s milestone commits, and opens or updates a GitHub PR or GitLab MR with artifact links and test results.
• Launches an educational synthesis sub-agent after the PR/MR exists, validates its claims against Megamind artifacts and diffs, then appends a dense journey/design/architecture/lessons brief to the PR/MR.
• Monitors CI after the PR/MR exists, fixes minor CI failures autonomously, optionally drains Roborev reviews of CI-fix commits when --roborev is active, and stops only when CI is green or a blocker file documents the exact evidence and next action.
• With --evidence, packages the completed run artifacts into a ZIP and attaches it to the PR/MR. Evidence packaging is skipped by default.

Use megamind for long-running work where the desired output is not just code, but a completed branch, review item, local gate results, and CI status. Use --dry-run to have it write the execution outline without launching agents or changing code, pass --roborev to opt into Roborev detection and review drains for an already enrolled repo, include skip human review to have it make the best call autonomously after a split MBOD result, or pass --evidence to attach the final artifact archive.

Multi-Harness Integration & Platform Support

Megamind supports native integration across 5 AI development platforms:

• Claude Code: Native agent at plugins/megamind/agents/megamind.md and skill at plugins/megamind/skills/megamind/SKILL.md (disable-model-invocation: true). Invoke via /megamind or /agent megamind.
• OpenCode Pi: Native agent at .opencode/agents/megamind.md (installed to ~/.opencode/agents/megamind.md) configured with mode: primary and tool declarations. Invoke via /megamind or agent selection in OpenCode TUI.
• Oh My Pi (omp) & Pi: Installable npm package at pi-megamind/. Supports omp install ./pi-megamind and pi install ./pi-megamind with slash command /megamind and mode: main execution.
• Grok CLI: Installed to ~/.grok/agents/megamind.md. Supports headless batch fan-out via grok --prompt-file with --always-approve and --disallowed-tools Agent.
• Antigravity (AGY): Native skill loaded via ~/.gemini/antigravity-cli/skills/megamind/SKILL.md (when ~/.gemini/antigravity-cli is present) or ~/.agents/skills/megamind/SKILL.md. Leverages native define_subagent and invoke_subagent for parallel MBOT/MBOD worker orchestration.

Install all targets automatically via:

./install.sh

The OMP route defaults MBOT/MBOD delegation to native task batches. The Pi route defaults to Pi-backed participants and prefers the lightweight pi-fast-subagent extension when available.

Slash commands

These are skills under plugins//skills//SKILL.md. Typing /colin-review still works; Claude Code, OpenCode, and Codex load them from the installed skill directories. Skills that post, push, delete, or run Megamind are user-invoked only.

colin-* — day-to-day dev workflow (name-spaced to avoid conflicts)

Shipping

Reviewing

Both review commands resolve the target the same way. Pass no argument to review the open PR or MR for your current branch. Otherwise the target accepts: a PR or MR URL or number, last N commits, whole repo, branch NAME, or a Git rev spec like SHA..SHA.

/colin-review [target] [flags] — standard single-agent review. Triages, buckets large diffs (≤ 5,000 lines runs as a single pass; otherwise ~3,000-line buckets grouped by top-level directory), reviews each bucket directly, validates and deduplicates issues, posts inline comments, and applies the :Reviewed-By-AI label. It does not use MBOT or colin-mbot-* agents; use /colin-ultra-review for multi-model fan-out.

In Git-diff mode (when the target is a rev spec rather than a PR or MR) the command always behaves as --no-post — nothing is posted, just displayed.

/colin-ultra-review [target] [agents] [flags] — the heavyweight, repository-aware variant. It runs 3 bug-hunting lenses × N models per behavioral bucket: state (behavior and lifecycle invariants), contracts (callers, consumers, schema, and deployment compatibility), and failure (errors, concurrency, adversarial input, and security). A whole-change integration pass follows the buckets. Discovery favors candidate recall; an independent source-evidence pass decides what is safe to post. Fresh full-state integration rounds continue until a round finds no new confirmed issue or the configured cap is reached.

How ultra-review fans out across MBOT

Primary files are bucketed by behavior and data flow, targeting roughly 800–1,500 changed lines. Generated files, lockfiles, snapshots, fixtures, and vendored code remain available as context instead of disappearing. Small diffs may be embedded; larger reviews send a compact change index and require reviewers to inspect the exact base/head diff plus unchanged callers and consumers using read-only repository tools.

Buckets may run sequentially to bound load. Within a bucket, the three lenses invoke MBOT in parallel, and each MBOT call fans out to N models. Candidate findings then feed a full-participant integration pass and independent validation. Unique findings are retained unless source evidence disproves them.

/colin-critique [target] [flags] — adversarial multi-model critique of a spec or plan document, not code. Flags contradictions, gaps, poor naming, and inferior design choices. Never suggests scope expansion or “nice-to-haves”. The target is a file path, current plan (the in-session plan), or a ClickUp TaskID. With no target, it searches for SPECS-*.md then PLAN*.md.

/colin-ultra-audit [scope] [agents] [flags] — production-readiness audit of the current repo state, not a diff. Runs 3 roles × N models per module bucket: hardening (security and resiliency), operability (observability, deployment, config, performance, dependencies), and stewardship (docs, tests, code quality). Findings merge and group by severity (Blocker, High, Medium, Low). Display only — no PR comments, no labels. Expensive — reserve for pre-launch or quarterly checkups.

Planning and porting

Skills

Claude loads these automatically when a task matches, or you can reference them by name.

Platform CLIs

• gh-cli — GitHub operations through gh (PRs, issues, runs, inline comments, raw API).
• glab-cli — GitLab operations through glab (MRs, pipelines, discussions, raw API).
• clickup-task-authoring — Author a ClickUp task from a conversation, plan, or spec as CUFM via cup task-sync: fidelity ledger, rich description structure, workspace field conventions, post-write audit. CUFM syntax and task-sync flags live in the clickup skill shipped with cup (cup skill).
• github-security-advisories — End-to-end GitHub Security Advisory (GHSA) handling: validate a report, prepare advisory fields, push fixes to the GHSA private fork.

Code generation and review

• many-brain-one-task (MBOT) — Run the same prompt across many models and compare or merge results. Powers /colin-critique, /colin-ultra-review, and /colin-ultra-audit. Configurable — see Customizing MBOT.
• many-brain-one-decision (MBOD) — Coordinate a multi-round debate across MBOT agents with distinct personalities until they converge on a decision or hit the configured round limit. Use it for prompts like “decide which option is best”, “debate this tradeoff”, or “propose a solution to this problem”.
• educational-brief — Creates grounded journey/design/architecture/lessons briefs for delivered PRs, MRs, branches, features, or agent runs.
• generate-e2e-test — Drives Playwright MCP through a workflow, then generates the E2E test code.
• cli-design — Design and review CLIs against clig.dev guidelines: flags, help text, errors, and scriptability.
• docs-writer — Write or restructure technical docs against Diataxis, Google, Microsoft, and Write the Docs style guides.
• skill-writer — Author new .claude skills with correct frontmatter and structure.

Frameworks and stacks

• coolify — Generate a docker-compose.coolify.yml for the current project using Coolify conventions and SERVICE_* secrets.
• drizzle-orm — TypeScript-first ORM patterns for Postgres, MySQL, and SQLite: schemas, queries, migrations, relations.
• nuxt-ui — Nuxt UI components. Fetches current docs from ui.nuxt.com/llms.txt so APIs are accurate.
• nuxt-content — Author Markdown and MDC content files for Nuxt Content sites.

Media

• nano-banana — Required for any image generation or editing. Wraps the agy (Antigravity) CLI.

• whiteboard — A poor man’s dev.fast whiteboard. The agent sketches an explanation (Mermaid diagrams, cards, stickies, diffs, code) in a plain HTML file, and your browser tab reloads on every save at the same scroll position. It’s driven by the whiteboard CLI, a zero-dependency Node server that --agents links into ~/.local/bin:

  • whiteboard start / new / / status / stop manage the server and boards. Boards live in ~/.whiteboard by default. The live server’s index at / lists them all, which is fine because only you reach it over Tailscale. Published copies have no index (see publish below).
  • The server listens on the Tailscale address by default; pass --host 0.0.0.0 for every adapter. status shows connected viewers and their remote addresses.
  • whiteboard errors prints the JS and Mermaid errors that open browsers report back, so the agent can fix a broken diagram without seeing the screen.
  • whiteboard publish bundles the board and its local CSS, JS, images, and fonts into one self-contained HTML file and uploads it with snip-upload. Each copy is reachable only by its random-suffixed URL, since the bucket can’t be listed.
  • One server is shared by every session and worktree, and boards are kept apart by / folder. whiteboard start always succeeds: it reuses a running server and prints its URL, and a lock makes concurrent starts safe. Boards are plain files, so removing a worktree leaves nothing running.
  • publish runs snip-upload auth status first, and if no bucket is configured it tells you to run snip-upload auth.

Using MBOD (Many Brain One Decision)

many-brain-one-decision reuses the same MBOT agent pool, but the host thread acts as a moderator instead of sending every model the exact same task. It gathers the current chat context into a decision brief, assigns each selected model a distinct debating personality, runs debate rounds in parallel, summarizes the results, eliminates weak options when appropriate, and returns a final decision with dissent and risks.

Example prompts:

Use many-brain-one-decision to decide which pizza toppings are best in 3 rounds or less.
Use MBOD to debate whether we should use Postgres triggers, app-layer events, or a queue.
Use many-brain-one-decision to propose a solution to this scaling problem: [facts...]

Decision modes

• Fixed choice — when the user gives explicit options or asks for multiple choice. MBOD preserves the supplied options and has each debater choose, score, and argue.
• Open proposal — when the user provides facts and asks to propose, design, or solve. Round 1 lets each debater organically propose a solution; the moderator clusters those proposals into candidate outcomes for later rounds.
• Hybrid — when the user gives initial options but allows alternatives. MBOD includes the supplied options plus WRITE_IN.

Round behavior

• Default max rounds: 4.
• The user can override naturally: “in 3 rounds or less”, “one round only”, or --rounds 2.
• Consensus means all active debaters choose the same outcome.
• Without consensus by the final round, MBOD recommends a winner by vote count, average score, least-regret score, then host judgment against the stated criteria.

Routing and profiles

Harness routing follows MBOT’s rules with one cost-sensitive exception: Claude-backed debaters use native Claude agents or the claude CLI first so usage stays on the Claude Max plan. Use colin-mbot-opus or colin-mbot-sonnet only when the CLI does not work or the user explicitly requests OpenCode-routed Claude. Claude-hosted runs drive OpenCode-backed debaters through sibling mbot-run.ts.

Profiles live beside the installed many-brain-one-decision/SKILL.md and use the same plain-prose style as MBOT profiles. If an MBOD profile is missing, the skill falls back to the sibling MBOT profile for agent selection. Profile lines may also pin personalities:

Use the following:
- OpenCode with GPT-6.1 Sol with "high" variant as "tech-bro"
- OpenCode with Grok 4.7 as "truth-seeker"
- Claude Opus with "max" thinking as "pragmatic-operator"

Customizing MBOT (your models, your harness)

Set up your own MBOT profiles. The defaults shipped in this repo are one person’s preferences — your API keys, entitlements, and trust in specific models will differ. Every review, critique, and audit run consults these profile files to decide which models to launch and through which harness.

How profile resolution works

When MBOT starts, it resolves exactly one profile:

1. An explicit --profile X loads X.md.
2. A known task type (code-review or critique) loads the same-named file.
3. Anything else loads defaults.md.
4. If the chosen file is missing, MBOT falls back to defaults.md; if that is also missing, it uses hardcoded defaults.

Profile names are exact: --profile foo loads foo.md and nothing else. The repo ships defaults.md and code-review.md beside SKILL.md; install.sh --agents, the skills CLI, and Claude plugin installs include them. Plugin updates can replace cached profile files; keep backups of personal customizations and reapply them after updating.

Before launch, MBOT records the resolved profile path plus every participant’s display name, exact model/provider ID, harness, reasoning effort, and backup in .tmp//participants.json. Every raw result and metadata record is persisted under .tmp//results/, including native subagent output.

Shipped defaults.md

Preferred models:
- Opus 5.5 (high)
- GPT 6.1 Sol (high)
- Grok 4.7 (xhigh)

Backup model (never more than one and ONLY these):
- Qwen3.8 Max (xhigh)
- GLM 5.3 (xhigh)

Do not use OpenCode Zen or OpenRouter providers except for the backup models.

Shipped code-review.md

The review profile uses the same model families, requires fresh independent sessions with read-only repository tools, and persists every final result. Kimi is the configured backup when a primary cannot run.

Writing your own profile

Copy one of the examples above and edit to taste. You can specify:

• Which models (e.g. Opus 5.5, GPT 6.1 Sol, Grok 4.7, Kimi K3, MiniMax M3).

• Which harness drives each model (claude CLI, grok CLI, codex, gemini, opencode). Constraints:

  • Claude Code can only run Claude models natively. Non-Claude models go through another harness (prefer grok CLI for Grok; otherwise typically OpenCode).
  • OpenCode must call claude for Claude models, and should prefer the first-party grok CLI for Grok when installed; other non-Claude models run as OpenCode subagents.
  • Grok CLI can run Grok models natively (or via headless grok --prompt-file); shell out for everything else.
  • Codex drives only OpenAI models natively. Same story for the Gemini CLI.

• Which provider or route (e.g. via OpenCode Zen, via Z.ai Coding Plan, via OpenRouter). Prefer coding-plan routes over generic openrouter/ or opencode/ when you have entitlements — they are cheaper or uncapped.

• Model-specific knobs (e.g. "max" thinking, "xhigh" variant).

• Backups — list fallbacks so a failed primary swaps automatically.

• OpenCode server attach — point MBOT at a running opencode serve instance instead of spawning a fresh local OpenCode per agent. Add a global line like Attach OpenCode to 127.0.0.1:4096 (applies to every OpenCode agent in the run) or via attach 127.0.0.1:4096 on a single agent line (overrides for that agent only). MBOT puts that on plan.json ("attach") so mbot-run stays in attach mode (no --spawn).

  Environment variables. mbot-run honors OPENCODE_SERVER_HOST, OPENCODE_SERVER_PORT, and OPENCODE_SERVER_PASSWORD. If those are already set (host config, systemd, Seamus gitlab.env), they win over the attach URL. It talks HTTP: /api on OpenCode 2, /session on OpenCode 1. Prefer an IP when the Claude sandbox proxy cannot resolve a hostname.

  Path-prefix requirement: the remote server must see the project at the same absolute path as the host. The container’s home directory has to match the host’s home directory prefix (host /home/colin/proj/foo → remote also resolves /home/colin/proj/foo). When the remote runs in a container, bind-mount or symlink so $HOME matches. Without this, --file .tmp/... and --dir . resolve to the wrong place on the remote and the run fails. Falls back to local OpenCode when the remote is not reachable.

Profiles are prose. MBOT reads them naturally and translates them into the right CLI or subagent invocations. No JSON schema, no YAML, no tooling required.

Overriding per run

• [agents] on /colin-ultra-review (positional, e.g. gpt gemini kimi) overrides the profile for that run only.
• --agents opus gpt gemini on /colin-critique does the same.
• --profile X in a prompt forces profile X.md.
• --dry-run in a prompt makes MBOT report its execution plan instead of launching anything. Useful for verifying a new profile.

MBOT subagent registry

The .opencode/agents/colin-mbot-*.md files register each model as a callable OpenCode subagent (read-only: edit and task denied; bash limited to git show/diff/log). They are how OpenCode-hosted MBOT runs dispatch to a specific model. You normally do not invoke them directly, but you reference them by short name in profiles and [agents] overrides.

Sorted roughly by capability:

Add your own by dropping a new colin-mbot-.md into .opencode/agents/ with mode: subagent, the desired model:, and the same permission: block as the existing files (edit/task deny, read-only git bash allowlist). Copy it next to the others; install.sh installs them to ~/.opencode/agents/.

Typical flows

• Shipping a change. Make edits → /colin-review → /colin-commit-and-push → on feedback /colin-fix-comments → on red CI /colin-fix-pipeline.
• Autonomous delivery. /full-send continues through merge; /full-stop stops with an unmerged handoff. Plugin installs use /colin-shipping:full-send and /colin-shipping:full-stop.
• Reviving an old request. /modernize reassesses its intent, then rebases and updates it only if the implementation still fits.
• Planning a feature. /agent-sops-pdd → /colin-finalize-spec → /colin-critique --summary → /agent-sops-code-task-generator.
• Important merge. /colin-ultra-review --no-post → review the output → post if it looks right. Use --re-review on subsequent pushes.
• Picking up someone else’s context. Ask them to run /colin-handoff and commit the resulting Markdown.

License

MIT — see LICENSE.