claude-public

Bits of my Claude Code setup that seem worth sharing — skills, settings, and the working rules I've landed on after running Claude Code as an orchestrator across a lot of projects.

Nothing here is a framework. Each piece is standalone: copy the one you want, ignore the rest. Anything specific to my own machine or private tooling has been stripped out, so the paths are generic and you'll want to adjust them.

CLAUDE-delegation.md        the delegation policy + working rules that sit at the top of my CLAUDE.md
skills/wrap-up/             end-of-session close-out ritual
skills/tmux-dispatch/       hand a task to another LLM CLI running in tmux
skills/handback/            the worker-side reply ping that closes the tmux loop

Skills go in ~/.claude/skills/<name>/ (global) or .claude/skills/<name>/ (per project). Restart Claude Code and it'll pick them up.

/wrap-up

The thing I use most. Sessions have a habit of ending with work half-shipped, decisions living only in the transcript, and no clear starting point for next time. /wrap-up is a five-phase checklist that closes all of that out in one go:

1. Ship it — commit what's uncommitted, check files ended up where they belong, run the deploy script if the project has one, tidy the task list.
2. Remember it — decide where each thing learned this session should live: CLAUDE.md for permanent conventions, .claude/rules/ for file-type-scoped instructions, memory for patterns and quirks, CHANGELOG.md / docs for anything user-facing.
3. Record tasks — every tangent, follow-up and leftover gets written to the tracker with why it matters, so a future session doesn't have to reconstruct the reasoning.
4. Review & apply — scan the conversation for what went badly (things I had to ask for twice, repeated manual steps, missing knowledge) and fix the cause rather than noting it.
5. Hand it over — produce a ready-to-paste prompt for the next session, anchored to the plan rather than to the tail of this one.

Two details that make it behave rather than being a rubber stamp:

The project profile. Before it starts, it resolves work_style, tdd, test_command and commit_policy — from .claude/wrap-up.json if you've written one, otherwise detected. This stops the two most annoying failure modes: being told to "write failing tests first" in a repo with no test surface, and having a session commit-and-push when I only wanted a diff to look at. commit_policy defaults to approve (commit locally, ask before pushing), and only an explicit config file may set auto.

Phase 5 anchors forward, not backward. The handover prompt is framed by the current phase's goal, with this session's leftovers slotted underneath it. Left to its own devices a model will happily write you a next-session prompt that's entirely residue from the rabbit hole it just came out of. The ordering rule is explicit: remove a blocker, meet the nearest exit criterion, advance the next milestone, and only then session follow-ups.

If your projects don't use a task tracker, the skill falls back to a plain markdown backlog file — the write path is described at the top of the skill and is the one thing worth adapting to whatever you actually use.

Agent delegation

CLAUDE-delegation.md is the block at the top of my global CLAUDE.md. The core of it:

You are the ORCHESTRATOR and ADVISOR — delegate every unit of work to backgrounded agents (Opus for complex tasks, Sonnet for general, Haiku for explore/read). Subagents should return concise findings, not full logs/diffs.

The point isn't speed, it's context. The main session's context window is the scarce resource in a long session — every file dump, log tail and grep result you read directly is capacity you don't get back. Subagents read the mess and return the conclusion.

The advice that took me longest to arrive at:

• Default down, not up. Mechanical work — classification sweeps, file-by-file transforms, log parsing — goes to Sonnet or Haiku. Opus is for judgment. If the prompt could be executed by following a checklist, it doesn't need the expensive model.
• Say which model, every time. Passing model and subagent_type explicitly is the difference between a considered fan-out and an accidental one.
• Subagents are terminal. They don't spawn further agents. The built-in general-purpose agent carries the Agent tool, so if you don't say so in the prompt it can and will spawn its own — and you lose all visibility. Every agent prompt of mine opens with "You are a terminal agent — do not spawn further agents." If work needs fanning out, the orchestrator fans it out itself as parallel siblings.
• Prefer fork when context matters. A fork inherits the parent's context and reuses the prompt cache; a fresh agent pays cold cache creation every time.
• One agent per file. Give parallel agents non-overlapping files, or use isolation: "worktree" so each gets its own copy. Two agents editing the same file is a silent overwrite, not an error.
• One review pass. At most one review agent per phase, after the build agent says it's done. A second review needs a named failing test or behaviour — "final audit" and "double-check" are how you burn tokens confirming what you already know.

The same file carries the 14 working rules (context discipline, surgical changes, fail loud, match the codebase's conventions) and a small glossary. The glossary is more useful than it looks — pinning one word per concept stops the model inventing synonyms halfway through a session and makes your own notes searchable later.

settings.json

Lives at ~/.claude/settings.json (global), .claude/settings.json (project, checked in), or .claude/settings.local.json (project, gitignored). Run /config for the common ones — the rest you edit by hand.

Environment variables I have set, and why:

{
  "env": {
    // Cache prompts for an hour instead of five minutes. The single biggest win for
    // long sessions and for /loop-style work that wakes up periodically — a wake-up
    // 20 minutes later still hits a warm cache.
    "ENABLE_PROMPT_CACHING_1H": "1",

    // Language-server-backed navigation (go-to-definition, references) instead of
    // grepping for symbols. Cheaper and more accurate in typed codebases.
    "ENABLE_LSP_TOOL": "1",

    // Keep the version pinned. Auto-updates mid-session change behaviour under you,
    // and plugin/MCP versions can drift out of step with the CLI.
    "DISABLE_AUTOUPDATER": "1",
    "DISABLE_INSTALLATION_CHECKS": "1",

    // Scratch files land somewhere I control and can clear, rather than in /tmp.
    "CLAUDE_CODE_TMPDIR": "/Users/you/.claude-temp/",

    // Correct colours when Claude Code is running inside tmux.
    "CLAUDE_CODE_TMUX_TRUECOLOR": "1",

    // Don't nag about being idle for ten minutes — long agent runs are not idleness.
    "CLAUDE_AFK_TIMEOUT_MS": "600000",

    // I don't use the claude.ai-hosted MCP servers; off keeps the tool list short.
    "ENABLE_CLAUDEAI_MCP_SERVERS": "false"
  }
}

And the top-level settings worth knowing about:

{
  "model": "opus[1m]",          // 1M-context Opus as the default
  "outputStyle": "Concise",     // lead with the outcome; no preamble, no recaps
  "effortLevel": "medium",      // reasoning effort; raise per-task rather than globally
  "autoCompactEnabled": false,  // I'd rather /wrap-up and start clean than be compacted mid-thought
  "tui": "fullscreen",
  "agentPushNotifEnabled": true,
  "statusLine": { "type": "command", "command": "ccstatusline", "padding": 0 }
}

A few notes. outputStyle: "Concise" does more work than you'd expect — it's the difference between a paragraph of throat-clearing before every answer and a straight result. autoCompactEnabled: false is a preference, not a recommendation: compaction is genuinely useful if your sessions run long and you don't have a close-out ritual — I turned it off because /wrap-up plus a fresh session is a cleaner boundary than a summarised one. And env values are per-install, so if you run more than one Claude Code install (different providers, different configs) they each need their own.

Some of these flags are undocumented and version-dependent — check they still do what you expect on your version rather than trusting this file.

/tmux-dispatch + /handback

A file-based contract for handing work to another model — Codex, GLM, a second Claude — running in a tmux session, and getting an event back when it's done.

Useful when a task genuinely benefits from an independent second opinion (research, review, design exploration), or when the work is too big to hold in one context. The orchestrator writes a self-contained prompt file, points the worker at it, and carries on; the worker writes its output to an agreed path and pings back.

How it fits together:

• tmux-dispatch goes in the orchestrator — the session doing the handing off.
• handback goes in every worker — it's the side that runs the ping script.
• The contract is: one tmux session per project per model, named <project>-<model>, with its cwd set to the project root, running in full-permissions mode.

Setup is a small shell wrapper per CLI so that launching it always produces that shape. Mine is a zsh function called codex that shadows the real binary: if you're already inside tmux it runs inline, otherwise it creates a session named after the current folder, starts the CLI in $PWD, and passes the bypass-approvals flag. Plus alias codex-raw='command codex' as an escape hatch. The full example is in the skill's § Setup — repeat the pattern for each CLI you want available as a worker (a second Claude Code install pointed at a different provider is just the same function with different env vars and a -glm suffix).

The bypass-approvals flag is the part people skip and then wonder why dispatches hang. A worker sitting on Approve this command? looks idle in a pane capture but will never finish — so the wrapper has to guarantee it can't happen. Only do this for sessions you're deliberately running unattended, in a repo you're happy for the model to change.

The hard rules in the skill are all failures I actually hit: never send keys to a busy pane, never trust a session name to tell you which model is in it, always put the prompt in a file rather than through send-keys, and always declare both an output path and a handback target. Without the last one you're left polling and guessing whether it's done.

Take what's useful. Issues and PRs welcome if something's broken or unclear.