Claude Code is the lead developer. Everything around it exists for two reasons: keep its context, its working memory, for judgment, and turn my working method into steps it cannot skip.
8Claude Code skills used 10+ times in the last 30 days30 days to 14 October 2026
17different hooks that fired in the last 30 days30 days to 14 October 2026
1,425tasks handed to local workers in the last 30 days30 days to 14 October 2026
1,880notes in the project vault (its knowledge base), 482 of them decisionson 14 October 2026
A
The big picture
Claude Code sessionmrs-toolkit plugin · about 40 skills + guard hooksClaude Code · Opusdc (dev-conductor), an in-house command-line tool · gives each session its own copy of the code, merges, deploysClaude sub-agents (cloud) · Sonnet collects, Opus judges
Tools over MCPMemoryDocumentationLocal workersSensorsNotificationsBrowser
Home serverMemory engine · project vault (notes in Git) + docsInference gateway · one model at a time per GPU · call logGPU 0 · MoE · bulk workGPU 1 · dense · judgmentMessaging bridge
Each tool is plugged into Claude Code over MCP, the standard way to connect a tool to an AI agent. Knowledge comes from memory, bulk reading goes to local workers (small agents on local Qwen models), the hardware state is measured by sensors, and a messaging channel reaches me when I am away from the screen.
B
Method as skills
A skill is a written procedure Claude Code loads when a task calls for it, such as /analyze.
/analyze
145 runs
searches project memory, surfaces constraints, writes the plan
/dev
285 runs
implements in its own worktree, checking memory before each file
/critic
41 runs
a local judge compares the code changes with the plan
dc land
merges in a throwaway worktree, never the shared working copy
dc deploy
build, start, health check
/vault-sync
89 runs
records decisions, mistakes and gotchas
The two locks: no code edit before the plan is written, no merge before the critic’s verdict. Runs over the 30 days to 14 October 2026.
Decide and test
/decision pressure-tests a costly choice: it checks what the project already has, surveys the state of the art, attacks the strongest version of the choice, then gives a go or no-go. /test-ui drives the app like a real user, in a browser, to prove a change end to end. /prompt-work is loaded before editing any text a model reads.
Sessions and discipline
/session-start opens an isolated git worktree, a separate working copy of the repository, through dc, so parallel sessions never collide. /track logs a broken rule so it comes back next session.
C
Hooks: gates that refuse, cues that remind
A hook is a script Claude Code runs on its own at set moments: at session start, before an edit, before a command.
Gates · they refuse
No code edit before a written plan, nor outside /dev. No edit in the shared working copy: open a worktree. No merge before the critic’s verdict. No edit to a prompt before /prompt-work is loaded. No large read without delegating it or saying why.
Cues · they remind at the right moment
At session start, the three rules Claude breaks most. When it is about to start a cloud sub-agent: could a free local worker do the job? Before a risky shell command, such as killing every process of one name: the rule it would break. After the context is compacted: search the vault again, since what it found there is gone.
Housekeeping · they keep track
Skill and sub-agent runs are logged, the plugin version is checked at start, and long answers end on a short TL;DR.
D
Local workers and the split of tasks
Claude CodeOpus · orchestrator
one question per task
self-contained prompt
run_agentsMCP server
starts the workers in parallel
re-reads every cited line
retries implement until green (5 rounds max)
returns the real git diff
pi worker 1fresh session
pi worker 2read · grep · find
pi worker None role each
Gateway2 × RTX 5090
MoE: summarise, list
dense: cite, judge
Each worker is pi, an open-source coding agent, on one of the two local Qwen models: the MoE (mixture of experts, fast, for volume) or the dense one (slower, it cites and judges). Only the short answer comes back into Claude’s context · zero API cost.
One question per taskPacked into one prompt, a six-item checklist got a generic answer 3 times out of 3; given as six separate tasks, all 6 were answered.
Self-contained promptsEach worker starts with no memory of the conversation: working directory, exact question and output format are all in the prompt.
A role per taskinvestigate, digest, review, challenge, implement, research, each with its own tools; review and challenge also read the project memory.
The model fits the jobThe MoE summarises and lists; only the dense model cites file and line numbers. On 8 hard cases run twice, the MoE invented 23 of its 41 citations, the dense model none of 31.
Citations re-checkedThe server re-reads every cited line and marks any gap; Claude only acts on a confirmed citation.
Writes are isolatedimplement runs in a throwaway worktree with a verify command, retried up to five rounds until it passes; what comes back is the diff git observed, not the worker’s account.
E
One memory engine for the agent and the product
MRS Memory · two instances
Claude Codeand the judging workers
Dev instanceproject vault + docs
Vault1,880 notes in Git (482 decisions)
MRS Studio assistantproject 03
Product instanceuser and workflow memories
Conversations, mailextracted and consolidated by the assistant
Outside MRS Memory · Claude Code’s notebook · about 460 notes
Same pipelineEmbeddingGemma-300MBM25RRFCross-encoder+ linked notes (wiki-links)
One search engine, two separate memories. The first holds the project’s knowledge (vault and docs) and serves Claude Code. The second, inside MRS Studio (my AI assistant app, project 03), holds what the assistant learns about its users; Claude Code has no access to it. Separately, Claude Code keeps its own notebook of short notes, whose index it re-reads at every session start.
When Claude uses it
Before editing a file, to see what was decided about it. After a context compaction, when a hook tells it to search again. At the end of a batch, when a skill writes the decisions and corrections and pushes them, searchable within seconds. Over three months to July, 73% of coding sessions checked a file’s notes before the first edit.
How it searches
Exact questions first (this file, this tag, these links), then by meaning: keywords and embeddings merged, reordered by a cross-encoder, with linked notes up to two links away. On 35 test questions in May, a relevant note was in the top five for 76% of them, against 64% with one method alone.
How it stays reliable
A duplicate check runs before any new note. A note that sets a constraint must carry a proof one can re-run (a command output, a file and line, a commit), and a linter checks it. Each note lists the code it describes and its last check date, so an old one comes back flagged. The note points, the code confirms.
F
Design choices, with the measurements behind them
How do I know a change works?
The hooks and the local workers keep logs, and a tracker counts how often Claude breaks each rule it can observe. Two versions are compared by running them alternately in the same time window, so the time of day cannot explain the gap, and a result from a handful of runs is checked on a larger sample. Example: a first test of 8 runs suggested that agents never delegate on their own. A larger one, on a single task, gave 6 of 12 without a reminder and 12 of 12 with it. Fisher’s exact test gives p = 0.014: if the reminder did nothing, a gap this large would appear by chance about once in 70 tries. In everyday sessions the rule was followed far less often (see Limits), so it is now enforced by a hook.
Why hooks rather than instructions?
An instruction in prose gets lost as the context fills; a hook acts at the moment of the action, and it works because it blocks. Measured over two months on the same sessions: when a hook blocked an edit in the shared working copy, the command it named followed within ten minutes in 72 cases out of 103; when a local model only added a warning to an action that went ahead anyway, none of its 33 warnings was taken into account. A gate that blocks must offer a cheap way out: opening a worktree takes four seconds, and the plan gate lifts as soon as the plan’s checklist is written.
72 of 103 (70%) · 0 of 33 · June to August 2026
Do the local workers invent citations?
Measured: of 1,669 checkable citations, 129 (7.7%) had an invented line number, hence the re-check described in section D. In the safest setup, a single-target lookup on the dense model, 398 of 398 checkable citations were correct (312 runs).
129 of 1,669 (7.7%) · 398 of 398 · August 2026
Local worker or cloud sub-agent: who gets which job?
The orchestrator’s context is the scarce resource, so I split work by whether a failure would show. Verifiable bulk reading goes to local Qwen workers, at no cost; web collection to a cheaper cloud model (Sonnet), where a wrong answer can be filtered afterwards; judgment that cannot be re-checked stays on the strongest one (Opus), because a weak judgment is invisible.
How do parallel sessions avoid colliding?
Each session has its own branch and git worktree. dc land merges in a throwaway worktree, never in the shared working copy. dc deploy refuses to overwrite diverged local work on the server and reports failure when the health check is red.
G
Limits
One user
It runs for one person, on two machines, Windows and Linux, with the same plugin. It is how I work, not a team platform or a hosted service.
Delegation gets forgotten
“Delegate bulk reading” is the rule Claude breaks most. A reminder after the fact was followed 8.4% of the time (28 of 335, five weeks to August), so a hook now stops the first large read, and the rule comes back at session start.
The notebook has no history
Claude Code’s notebook, about 460 short notes of corrections and lessons, keeps no history: a note that is overwritten or deleted is gone for good, whereas every change to the vault is kept. This was the first gap found in a comparison of the harness with public practices in September.