Claude Code

Anthropic's coding agent. It runs in a terminal (also as a desktop app, a web app, and IDE extensions), reads and writes files in a working directory, runs shell commands, and keeps going until a task is done rather than returning a single completion. This vault is written and maintained by it, which is why the schema in CLAUDE.md reads like instructions to a process rather than notes to a person.

Seventy-five pages across wiki/ and toolbox/ mention it. Until now none of them was about it.

How it gets extended

Four mechanisms, and the vault has opinions about most of them.

CLAUDE.md is a file in the project root that is loaded into context at session start. It is the closest thing to configuration-as-prose: conventions, glossary, directory layout, workflow steps. This file is one.

Skills are directories containing a SKILL.md — a markdown file with frontmatter declaring a name and a description, plus whatever supporting scripts and reference documents it needs. The description is what gets matched against the task; the body loads only when the skill fires. mcp-vs-skills argues the line between a skill and an MCP server is knowledge versus access — a skill teaches the model to use a tool that already exists on the machine, an MCP server provides the tool. Skills that begin "first install this CLI" are on the wrong side of that line.

MCP servers connect the agent to services over a typed tool interface. Hooks run shell commands at fixed points in the agent's loop — before a tool call, after one, when the session stops — which is how deterministic policy gets enforced rather than requested. peon-ping is a hook that plays Warcraft voice lines; statewright is a state machine that decides which tools are callable in each phase of a task.

Subagents are separate contexts spawned for parallelizable work, reporting back a result rather than a transcript.

The wrapper ecosystem

More than forty toolbox pages exist because of Claude Code, and they cluster into recognisable shapes.

Retargeting it at other models: claude-code-router routes requests to other providers per task slot, cc-mirror clones the install into isolated per-provider variants each with its own command name, config, and theme. tweakcc patches an installed copy to change prompts, themes, spinners, and toolsets outright.

Giving it memory and issue tracking, because a fresh context forgets: beads, kata, agentmemory, hippo-memory, stash, ctx.

Containing it, because an agent with shell access is an agent with shell access: hazmat uses a separate Unix user plus Seatbelt and pf on macOS, superhq runs it in a microVM with credentials injected host-side, sandbox-agent-sdk sells the same idea as a service. See sandboxing-ai-agents and matryoshka-isolation.

Running many at once: botctl supervises scheduled autonomous agents defined by a BOT.md file, kanbots gives each kanban card its own git worktree, mclaude arranges file-based locks and mail so two sessions can share one repo without fighting.

The cc-mirror approach — one installation reachable under many command names, each presetting different behaviour — is the same user model as a multicall-binary, reached by a different mechanism.

As a subject rather than a tool

The vault's arguments about coding agents are mostly arguments about this one. agents-vs-daemons reads skill and tool manifests as capability contracts, the same shape as a daemon's configuration. skill-atrophy-supervision-paradox is about what happens to the human. cult-of-vibe-coding and llm-critics-are-right-use-anyway take opposite positions on whether that matters. who-manages-the-agents asks the org-chart version of the question.

Related: llm-wiki-pattern, the pattern this vault implements; codealmanac, the same idea pointed at a codebase instead of a knowledge base.