GitHub repos deep-dive

GitHub Prior-Art Scan — Multi-Machine Claude Code Fleet

Scanned 2026-05-11. Evaluating 8 repos as direct analogs or pattern sources for a multi-machine Claude Code fleet with named agent variants, vault-based canon, and drift mitigation.

Source files saved under ./<repo-name>/ alongside this summary.

---

1. sethdford/claude-fleet

• URL: https://github.com/sethdford/claude-fleet
• Stars: 2 · Last push: 2026-02-02 (3+ months stale, but README/docs are mature)
• Direct analog? Partial — closest in name and intent, but very different scope.

What it does

Single-host TypeScript orchestration server (Express + WebSocket on port 3847) that spawns Claude Code workers as child processes via NDJSON streaming. Coordinates them through 7 named roles (Lead, Worker, Scout, Kraken, Oracle, Critic, Architect) running in “waves” — Scout/Oracle in parallel → Architect → Worker/Kraken → Critic. Persists via SQLite (WAL mode). Exposes 98 tools via MCP. Includes a JWT-authed REST API, RBAC, JSON metrics, Prometheus, swarm blackboard, pheromone trails, belief consensus, credit auctions, FTS5 knowledge base, policy guardrails, and session lineage (trim/continue chains with token accounting).

Patterns worth stealing

• Named role taxonomy with allowed-tool whitelists (docs/ARCHITECTURE.md §1, README “Agent Roles”) — Lead/Worker/Scout/Critic/Architect each carry a distinct system prompt, tool allowlist, spawn depth limit, and default priority. Direct parallel to Pepper/Stark/Lens/Nagatha — formalize the per-role authority surface.
• Wave pattern with explicit quality gate (README “Wave Flow”) — parallel exploration → sequential design → parallel impl → critic gate → loop. Mirrors Wes’s “scope-small ship-fast” with structured re-entry.
• Handoffs as first-class storage rows (ARCHITECTURE.md §3 + endpoint /handoffs/:handle) — pending-handoff queue per worker, injected on spawn. Drop-in replacement for ad-hoc handoff JSON.
• Session lineage chains (/sessions/:id/trim, /lineage) — trim/continue with token accounting tracks the actual context budget across child sessions. Wes’s compaction-and-continuity-protocol gets a real read-model.
• Worker health states (starting→ready→working→stopping→stopped, heartbeat 10s, degraded@30s, unhealthy@60s) — concrete supervisor contract for the fleet-monitor visibility goal.
• Worker auto-restart with bounded retry (up to 3 attempts, ARCHITECTURE.md §2) — replaces the bespoke launchd/systemd/schtasks restart loops with a documented spec.
• Storage factory with pluggable backends (src/storage/factory.ts) — start on SQLite, escape to Postgres/D1 without rewriting routes. Maps to the D1 read-model.

What’s overengineered or wrong fit

• Single-host assumption — server lives on one machine; “fleet” here means workers spawned by one orchestrator. No SSH, no Tailscale, no cross-machine identity. Wes’s fleet is fundamentally multi-host; this only covers the per-machine layer.
• JWT + RBAC + rate-limiting (100 req/min/IP) — heavy auth scaffolding for a solo operator. Skip until there are non-Wes consumers.
• Rust acceleration layer (8 crates: compound, search, lmsh, dag, swarm, ringbus, etc.) — vanity engineering for a 2-star repo. The crates have JS fallbacks; the whole thing is bloat.
• Swarm primitives (pheromone trails, credit auctions, belief consensus, governance proposals/votes) — biology-inspired noise. Wes runs 18 named variants; this is for actual N≫18 swarms.
• 98 MCP tools — most are CRUD wrappers over the same storage. Wes’s MCP surface is already in ~/.mcp.json; adding 98 more would obliterate context budgets.
• Cron scheduler + webhook triggers + workflow executions — duplicate of launchd/systemd/Task Scheduler already running on each fleet machine.
• The continuous “audit loop” (npm run audit) — Claude in a while-loop until typecheck + lint + 701 tests + e2e all pass. Cute, but it’s a fix-the- product gimmick, not a fleet pattern.

Specific source citations

• Role taxonomy: README lines 124-136
• Wave flow: README lines 138-152
• Worker lifecycle: docs/ARCHITECTURE.md lines 86-117
• API surface: docs/ARCHITECTURE.md lines 247-377
• Storage tables: docs/ARCHITECTURE.md lines 125-138
• Layer dependency rules: CLAUDE.md lines 23-31 (“types.ts → nothing”)

---

2. wshobson/agents

• URL: https://github.com/wshobson/agents
• Stars: 35,230 · Last push: 2026-05-11 (today — actively maintained)
• Direct analog? Steal-only — it’s a plugin marketplace, not a fleet.

What it does

Plugin marketplace: 80 single-purpose Claude Code plugins bundling 185 specialized agents + 153 skills + 100 commands organized in 25 categories. Each plugin is auto-discoverable, isolated, and loads only its own agents/ commands/skills into context. Notable plugins: agent-teams (uses the experimental CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 flag with teammateMode: "tmux" — directly relevant), conductor (Context-Driven Development with persistent conductor/ artifact dir), context-management, full-stack-orchestration. Includes a quality-eval framework (plugin-eval) with 3 layers (static, LLM judge, Monte Carlo), 10 weighted dimensions, and Bronze/Silver/Gold/Platinum badges.

Patterns worth stealing

• Plugin = self-contained agent/command/skill bundle (CLAUDE.md §Repo Structure) — .claude-plugin/plugin.json + agents/, commands/, skills/ subdirs. Auto-discovery means you only edit one file when adding a new variant’s surface. Maps Pepper/Stark/Lens into proper plugins instead of scattered ~/.claude/agents/*.md.
• teammateMode: "tmux" in ~/.claude/settings.json from the agent-teams plugin README — Anthropic’s official multi-agent display mode. Pair this with Wes’s variant supervisors and you replace homegrown tmux orchestration with a vendor-supported path. Currently behind the experimental flag.
• PluginEval anti-patterns (CLAUDE.md §PluginEval) — explicit list of skill smells: OVER_CONSTRAINED (>15 MUST/NEVER), EMPTY_DESCRIPTION (<20 chars), MISSING_TRIGGER, BLOATED_SKILL (>800 lines no refs), ORPHAN_REFERENCE, DEAD_CROSS_REF. Apply this as a vault-canon linter for Fleet/protocols/*.md and ~/.claude/agents/*.md.
• 10 weighted dimensions for skill quality — triggering_accuracy (25%), orchestration_fitness (20%), output_quality (15%), scope_calibration (12%), progressive_disclosure (10%) etc. Use as a calibration rubric for variant persona docs.
• team-lead/team-reviewer/team-debugger/team-implementer role archetypes (plugins/agent-teams/README.md) — same archetypes Wes already has (Pepper/Stark/Nagatha/Bilby) but with vendor-blessed prompt templates.
• Frontmatter convention (CLAUDE.md §Plugin Authoring) — name/description/model/color/tools for agents; name/description for skills. Color is purely cosmetic but useful for tmux pane differentiation.

What’s overengineered or wrong fit

• 80-plugin marketplace — Wes has 18 variants; he doesn’t need 185 agents. Don’t install — pattern-mine.
• conductor plugin’s persistent conductor/ artifact dir — product.md/tracks/spec.md/plan.md hierarchy is Notion-PM-as-code. Duplicates hinesipedia. Skip.
• Monte Carlo evaluation layer (50-100 LLM calls per skill, ~2-5min) — burn rate on a 153-skill corpus is enormous. Static + LLM-judge layers are useful; Monte Carlo is academic.

---

3. crichalchemist/agent-pi

• URL: https://github.com/crichalchemist/agent-pi
• Stars: 0 · Last push: 2026-05-10 (active but brand new)
• Direct analog? Steal-only — small, single-purpose, well-written.

What it does

Claude Code plugin that wraps pi.dev (Pi multi-model agent runtime) as an MCP server with 7-8 tools (pi_list_models, pi_spawn_agent, pi_steer_agent, pi_followup_agent, pi_poll_agent, pi_get_result, pi_terminate_agent). At session start, queries Pi for available models and notifies the main session via a [pi-models] line before the user even types — Claude reads this and tier-routes (fast/balanced/frontier) without manual config. Stores session state in ~/.claude/claude-pi/sessions/<sid>.jsonl (JSONL per session) with atomic tmp-rename writes; statusline reads status.json for ● 2 running ✓ 3 done. Detects the superpowers plugin and surfaces a separate skill for routing read-only workflow roles.

Patterns worth stealing

• Session-start notification injection (CLAUDE.md §Architecture) — one-shot script via monitors/monitors.json emits a notification line to the conversation before any user interaction. Direct fit for Wes’s “load fleet state on SessionStart” goal: emit [fleet-state] 18 variants alive, 2 degraded, last handoff 12m ago so Claude sees current verified state without reading 17 files.
• Atomic JSON writes via tmp-rename (status-writer.ts) — ~/.claude/claude- pi/status.json written via tmp + rename so the statusline never reads a half-written file. Use for enabled-agents.json and registry-overrides.json.
• Per-session JSONL event logs with serialized writes — file naming <session-id>.jsonl, append-only, serialized through a promise chain to guarantee line order. Drop-in for fleet event logs.
• Tiered model routing (fast/balanced/frontier table in README) — concrete routing rubric: formatting/boilerplate→fast, standard coding→balanced, novel reasoning/architecture→frontier. Wes’s fleet should have an explicit tier doctrine for opus[1m] vs sonnet vs haiku per machine/task.
• Plugin detection at startup (list-models.ts detects superpowers on disk) — if-detected-then-surface pattern. Apply to optional MCPs: only surface client-skills if their MCP keys exist in integrations-keys.env.
• Sentinel-guarded CLAUDE.md edits (install.sh appends a block with sentinels; uninstall removes cleanly) — Wes’s hook installers should use the same pattern instead of overwriting files.

What’s overengineered or wrong fit

• Nothing meaningful — repo is 98-line CLAUDE.md, focused, no fat.
• Pi.dev itself is a third-party dependency; you wouldn’t actually run this, just steal the patterns.

---

4. smtg-ai/claude-squad

• URL: https://github.com/smtg-ai/claude-squad
• Stars: 7,423 · Last push: 2026-03-28 (6 weeks stale but mature)
• Direct analog? Steal-only — same problem space (manage multiple agents), different scale (single machine, single user, single repo at a time).

What it does

Go-language TUI (cs binary) that manages N parallel Claude Code / Codex / Aider / Gemini sessions inside one terminal. Each “instance” gets its own tmux session (isolated terminal) and its own git worktree (isolated branch). TUI shows session list, preview pane, diff tab. Hotkeys: n new, D kill, enter attach, s commit-and-push, c checkout/pause, r resume. Optional -y autoyes mode auto-accepts all prompts for background work. Profiles in ~/.claude-squad/config.json let you name multiple program configs (claude, codex, aider). Requires tmux + gh. AGPL-3.0.

Patterns worth stealing

• tmux session per agent + git worktree per agent (README “How It Works”) — exactly the per-variant isolation model. Each variant gets a tmux session and a worktree; the supervisor doesn’t have to coordinate file conflicts.
• autoyes background mode (-y flag) — explicit experimental flag for “don’t ask, just do it.” Maps to Wes’s --dangerously-skip-permissions + bypassPermissions pattern, but at the supervisor level.
• Profile-based program selection in config.json — { name, program } pairs. Replace bespoke launch scripts in ~/scripts/sessions/*.json with the same shape.
• Pause/resume via commit checkpoint (c checkout) — pausing a session commits work and parks the worktree. Resume picks it back up. Pattern fits fleet handoff: any variant can be paused with a git-backed checkpoint.
• Diff view before push — review changes from any session before they ship. Maps to Wes’s “approval required for external-facing output” boundary.

What’s overengineered or wrong fit

• Single-machine only — no SSH, no cross-host coordination.
• Go binary — not aligned with the JS/Python/bash tooling already on the fleet. Pattern-mine, don’t adopt.
• Limited to one repo’s worktrees per cs instance — Wes runs cross-client work; would need N cs instances.

---

5. nielsgroen/claude-tmux

• URL: https://github.com/nielsgroen/claude-tmux
• Stars: 157 · Last push: 2026-04-17 (active)
• Direct analog? Steal-only — tactical tmux UX, not architecture.

What it does

Rust TUI (ratatui + crossterm) that runs as a tmux display-popup. Lists all tmux sessions containing a claude pane, detects per-session status by analyzing pane content (Working / Idle / Waiting-for-input / Unknown), shows live preview with ANSI color, supports create/kill/rename/filter. Bound to Ctrl-b, Ctrl-c to pop up from any tmux session. ~7 Rust source files total.

Patterns worth stealing

• Status detection by pane-content pattern matching (README §“Status Detection”) — Working = ❯ + “ctrl+c to interrupt”; Idle = ❯ no interrupt message; Waiting = [y/n]. Concrete heuristics for the fleet monitor’s “is variant X waiting for me?” view.
• display-popup as the variant dashboard — bind-key C-c display-popup -E -w 80 -h 30 ~/.cargo/bin/claude-tmux. A tmux popup is dirt-cheap UI for the fleet — no Electron, no browser.
• Filter sessions by name/path (/ hotkey) — fuzzy search across 18+ variants. Better than scrolling.
• Sort attached-first — sessions you’re currently in float to the top. UX detail worth copying for the monitor.

What’s overengineered or wrong fit

• Rust adds zero value over a shell script for this use case. The Rust dependency stack (ratatui, crossterm, ansi-to-tui, anyhow, dirs, unicode-width) is overkill for ~150 lines of logic.
• Single-machine only. Detects local tmux sessions; no SSH/Tailscale story.

---

6. pchalasani/claude-code-tools

• URL: https://github.com/pchalasani/claude-code-tools
• Stars: 1,777 · Last push: 2026-04-19 (active)
• Direct analog? Steal-only — toolkit, not architecture.

What it does

A grab-bag toolkit of Python + Rust CLI tools, hooks, skills, agents, and plugins for Claude Code: aichat (session management), tmux-cli (terminal automation), lmsh (natural-language shell), vault (secret handling), env-safe, statusline tools, gdocs/gsheets integrations, voice plugin, session-repair tool, alt-LLM-provider routing, safety hooks plugin. Published as claude-code-tools on uv-tool; aichat-search is a separate Rust binary. The README mostly redirects to a docs site. Useful piece for this scan is docs/claude-code-tmux-tutorials.md — a curated list of community tmux+CC resources.

Patterns worth stealing

• tmux-cli — terminal automation primitive (separate from claude-squad, more programmable). Use for the supervisor scripts that already drive variant panes; replaces the bespoke tmux send-keys strings in clear-and-terminate- protocol.md.
• vault tool — explicit secrets handling that doesn’t leak into Claude’s context. Maps to Wes’s existing integrations-keys.env discipline; worth comparing whether their pattern is cleaner.
• env-safe — env-var loading that strips secrets before they hit the process env where logs might capture them. Direct fit for the recurring “secret leaked into jsonl” feedback issue.
• fix-session — repair corrupted Claude Code session files. Wes will hit this eventually; bookmark it.

What’s overengineered or wrong fit

• README is a wall of card-images linking out to a docs site — not great for pattern-mining. You’d need to dig the docs site.
• It’s a personal toolkit (one author, 1.7k stars). Pieces are good; the collection itself is not a doctrine.

From docs/claude-code-tmux-tutorials.md specifically

The tmux tutorials doc is a literature review. Highlights:

• Kazuph’s “Claude Code Company” tmux command collection — boss-worker pane hierarchy. Direct analog to Wes’s Pepper-leads-PC-workers model.
• Studio Prairie’s “Claude Code Max fully-automated parallel dev system” (Japanese) — multi-agent orchestration with tmux.
• The Japanese community has the most sophisticated tmux+CC patterns; English-language coverage is thinner.

---

7. shanraisshan/claude-code-best-practice

• URL: https://github.com/shanraisshan/claude-code-best-practice
• Stars: 52,455 · Last push: 2026-05-11 (today)
• Direct analog? Steal-only — reference doc, not infrastructure.

What it does

Encyclopedia-as-repo. Curated index of every Claude Code feature (concepts, hot/beta features, workflow comparison table across 12 famous methodologies like Superpowers/SpecKit/BMAD/HumanLayer/Compound Engineering), agent collections, skill collections, plus an 83-tip section sourced from Boris Cherny, Thariq, Cat Wu, Dex, Matt Pocock and others. Each item links to either the official Anthropic docs, an X/Twitter source, or an “Implemented” reference in the repo’s .claude/ folder (with weather-orchestrator as the canonical demo of Command → Agent → Skill chains).

Patterns worth stealing

• CLAUDE.md ≤200 lines target (their own CLAUDE.md, README tips section) — matches Wes’s MEMORY.md warning about 206 lines. Hard cap, not aspirational.
• .claude/rules/*.md with paths: YAML frontmatter for lazy-loading — load rules only when Claude touches files matching the glob, instead of bundling everything into CLAUDE.md. Direct fix for the “fleet root is getting fat” problem.
• Wrap domain rules in <important if="..."></important> tags to stop Claude ignoring them as docs grow — humanlayer’s pattern. Adopt for the longer protocol docs in Fleet/protocols/.
• Command → Agent → Skill orchestration pattern (README §Orchestration Workflow + orchestration-workflow/orchestration-workflow.md) — slash command invokes a subagent that has a preloaded skill. The skill is the what, the agent is the who, the command is the trigger. Cleaner than ad-hoc Task tool calls.
• Separate commits per file (CLAUDE.md §Git Commit Rules) — granular git history, cherry-pickable. Strong opinion worth at least considering.
• Context budget heuristics from Thariq/Dex (Tips §Context): “dumb zone kicks in around ~40% context”; “context rot at ~300-400k on 1M model”; “rewind

  correct” (double-Esc) — concrete numbers, not vibes. Update Wes’s compaction protocol with these.

• /compact with hint beats letting autocompact fire — manual /compact focus on X, drop Y is more deliberate than waiting for the autocompact at the least-intelligent point. Document in handoff-protocol.md.
• The Workflow comparison table — 12 famous methodologies all converging on Research → Plan → Execute → Review → Ship. Use it as the source-of-truth table when evaluating “should we adopt SpecKit / BMAD / Superpowers / etc.”

What’s overengineered or wrong fit

• The actual .claude/ directory in this repo is mostly a weather-API demo — it’s a doc/index repo, not a deployable system. Don’t install or fork.
• 52k stars is from the curation, not from anything you’d run in production.

---

8. thedotmack/claude-mem

• URL: https://github.com/thedotmack/claude-mem
• Stars: 74,948 · Last push: 2026-05-12 (today, very active)
• Direct analog? Partial — direct analog for memory layer, not fleet.

What it does

Persistent context system. Plugin installs 6 lifecycle hooks (Setup, SessionStart, UserPromptSubmit, PreToolUse[Read], PostToolUse, Stop) that pipe every tool call to a per-user worker daemon (Bun + Express, port 37700 + (uid % 100)). The worker uses the Claude Agent SDK to compress observations asynchronously and stores them in SQLite (~/.claude-mem/claude-mem.db) + ChromaDB (vector embeddings). Search via the mem-search skill (HTTP auto-invoked when user asks history questions). Web viewer UI on http://localhost:37777. Supports privacy via <private>...</private> tags stripped at the hook layer. Multi-account isolation via CLAUDE_MEM_DATA_DIR

• CLAUDE_MEM_WORKER_PORT env vars. Graceful degradation: transport errors exit 0 so the worker never blocks Claude Code.

Patterns worth stealing

• Worker daemon + hooks for capture, SQLite + vector DB for storage (README §How It Works + docs/architecture-overview.md) — exactly the shape of the vault canon + hinesipedia indexing problem. Hooks capture, worker compresses, DB stores, skill retrieves. Maps to Wes’s “fleet-node KV + vault canon” with semantic search added.
• Graceful degradation rule: worker failure NEVER blocks Claude Code (docs/ architecture-overview.md §Graceful Degradation) — transport errors → exit 0; client bugs → exit 2. Codify the same rule for fleet hooks; the load-handoff and load-memory hooks should NEVER block session start.
• Atomic exit-code semantics — exit 0 success / 1 non-blocking error / 2 blocking error. Document this contract for ~/.claude/hooks/.
• Privacy tags stripped at hook layer (<private>...</private> removed before data hits the worker) — apply to the recurring secret-leak feedback rules. Strip INTEGRATIONS_KEYS_ENV blocks at the pre-tool-use hook before anything is logged.
• Multi-account via env vars (CLAUDE_MEM_DATA_DIR, CLAUDE_MEM_WORKER_PORT) — clean isolation pattern for Wes’s “two Claude accounts” gotcha. Same machine, different data dirs, different ports.
• Per-user port via uid % 100 — automatic collision-avoidance when multiple shells/users on one box. Lift this for fleet-node-like services.
• Pending message queue with retry/backoff (1s/2s/4s, max 3 restarts before giving up) — bounded retry, never an infinite loop. Apply to peer-send and D1-write paths.
• Two session IDs (contentSessionId from Claude Code, invariant; memorySessionId from SDK, changes on worker restart) — disambiguates transport identity from canonical identity. Same distinction Wes already draws between peer_id (transport) and canonical_name (identity); this validates the model.
• Content-hash deduplication (SHA256 of session+title+narrative truncated to 16 hex chars, 30s window) — avoid duplicate writes when hooks fire redundantly. Useful for peer-broker and handoff writers.
• Citations via URL (http://localhost:37777/api/observation/{id}) — every stored memory has a stable retrieval URL. Fleet handoffs should be similarly citable.

What’s overengineered or wrong fit

• Auto-translation README into 33 languages — vanity. Skip.
• ChromaDB vector embeddings — semantic search is nice but it adds a Python toolchain (uv, chromadb) just to do “find similar observations.” Wes already has Obsidian search; FTS5 (already in SQLite) would carry most of the value.
• OpenClaw gateway integration — third-party gateway-as-a-service. Skip.
• Pro features architecture — the “headless core + paid enhanced UI” model is a SaaS pitch, not a fleet pattern. Skip.
• Bun runtime dependency — auto-installed if missing, but adds yet another JS runtime alongside Node. The fleet is already Node-heavy; adding Bun is cost without clear benefit unless you actually need Bun’s perf.
• Daily maintenance “upgrade everything to latest including majors” rule in CLAUDE.md — terrible practice for a fleet; you want pinned/audited deps.

---

Top 3 by leverage

Ranked by how much each one moves the multi-machine-fleet design forward:

1. thedotmack/claude-mem — single biggest lift. The worker daemon + hooks + SQLite + graceful-degradation + atomic-exit-codes + multi-account env-var isolation + two-session-ID model are exactly the missing scaffolding for Wes’s vault canon and read-model. Steal the architecture wholesale; skip ChromaDB/Bun/OpenClaw/Pro-features. The “worker NEVER blocks Claude Code” rule alone is worth the visit.

2. sethdford/claude-fleet — the closest name analog, and even at 2 stars the docs are mature enough that the role taxonomy, wave pattern, session lineage chains, and worker lifecycle states are directly portable. Strip out the swarm/Rust/RBAC/JWT nonsense and you have a clean per-machine variant supervisor. Pair this with claude-mem’s daemon model and you cover most of the design surface.

3. shanraisshan/claude-code-best-practice — not infrastructure, but the highest signal-to-noise reference for every other decision. The 83 tips from Boris/Thariq/Dex with concrete numbers (40% context = dumb zone, 300-400k token rot threshold, <important if> tags, paths: frontmatter, /compact with hints), plus the Workflow comparison table across 12 methodologies, lets Wes calibrate without re-deriving from scratch. Mine the tips; ignore the encyclopedia framing.

Honorable mentions: wshobson/agents agent-teams plugin (one-line teammateMode: "tmux" setting + experimental flag is the vendor-blessed path for what Wes is hand-rolling); agent-pi (session-start notification injection is a tiny but high-leverage pattern).

Skip: claude-squad (single-machine), claude-tmux (single-machine, Rust overkill), claude-code-tools README (redirects to docs site, harder to mine).