cmaster

Idea

AI command center for local machine… Inspiration from claude-ops: https://codeberg.org/sigil/claude-ops But will use tmux shell

Workflow

  • Full docs WORKERS.md
  • Entry point in commands cmaster and cworkers
  • master is the main claude thread that I interact with.
    • It will /spawn workers to execute specific tasks
    • and will follow up with the workers with a /reap-workers call
  • Run /start to begin a session used for cold sessions (after clear)
    • also useful after a long break even without a full clear — if you've been away long enough to forget context
  • Run /done when a coherent chunk of work is finished and are switching gears
  • Run /done + /clear as a hard reset. Do this when everything important is on disk. When to clear:
    • End of day / end of a major topic — always clear.
    • Mid-session checkpoint /done — probably don't clear. You're just snapshotting, not actually done.

The practical test: ask yourself "would I be annoyed if this session died right now?" If yes → /done but don't clear yet. If no, you're actually done → /done + /clear.

Once a week run /reflect and /foresight /reflect - looks for gaps or open threads that we havent closed also worth running after a particularly long or chaotic session — it catches things /done misses /forsight - tries to look ahead to what I can do now to anticipate future needs

Usage

cmaster and cworkers close workers from cworkers Call \spawn from master \reap-workers

Logs

12 May 2026 Tuesday

  • cmaster should actually open the master session if closed and other workers are running

11 May 2026 Monday

  • Moving coworkers to emacs cmaster
  • [X] mu4e like scolling p and n scroll up the preview

01 May 2026 Friday

  • Helper function for spawn*

28 April 2026 Tuesday

  • [>>] command in to rerun kinitFNAL from cworkers
  • [X] command to respawn closed workers from claude –resume

20 April 2026 Monday

  • Thinking about how to orchistrate remote claude sessions from cmaster
  • Got it setup … looks good
  • Can now spawn remote workers and intereact with them in cworkers just like I can with local workers.
  • Will try this out.
  • Bash commands
  • spawn-falcon and spawn-cmslpc are bash commands.
  • Setup spawn-local
  • adding interactive flag to spawn workers with … interactive is the new default

06 April 2026 Monday

  • Need to attach with tmux -u att .. or cmaster
  • moved /check-workers to /reap-workers
  • Workers write result.md when done; /reap-workers pulls the archive into master context
    • –auto flag on /spawn for fully autonomous workers (no approval prompts)

05 April 2026 Sunday

  • [ ] Why spawn from tmp files and not ClaudeBrain files ?
  • [X] What is the benifit from courier ? (see below)
  • [X] What is the minder doing in this system ? (see below)
  • [X] How do workers get cleaned up \spawn \checkworkers \closeout
  • [X] Default to spawn for all tasks
  • Cleanup a summary of what was done should be written somewhere
  • Writting peek-worker and check-worker CLI
  • [ ] +tab complete for peek-worker ?
  • Updated the workers CLU
  • [X]

    How to get closed worker contexts back to master ?

    • Have master keep a list of "spawed" workers, cron job to check when closed
    • call /clear

Calude-ops MCPs

Courier

Courier was a message-passing MCP server that let the leader and workers send each other real-time messages through named "relays" (basically named channels). Each task got its own relay.

The main use cases:

  • Worker → Leader: "I'm blocked on X", "milestone reached", "done"
  • Leader → Worker: "here's the context you asked about", "change direction on X"

In our design, we're replacing this with:

  • Worker → Master: writing to status.md and result.md files in ClaudeBrain
  • Master → Worker: you just switch to the tmux pane and talk to the worker directly

The file-based approach is simpler but not real-time — /check-workers polls rather than getting push notifications. The tradeoff is worth it since you can always just glance at the tmux pane.

Minder

Minder was a cron-style scheduler that could run tasks on a timer. The main use in claude-ops was auto-running /check-workers every 10 minutes so the leader would periodically poll worker status without the user asking.

We don't need it — Claude Code already has /schedule (cron triggers) built in. If you wanted periodic worker checking, you could set that up natively.

Backlinks