Resources·Claude Code: the four extensions we install first
Claude Code: the four extensions we install first
Claude Code has been on your machine for a few weeks. Every morning it starts from nothing: it does not remember yesterday's decisions, it reads a 30,000-line log to find one error, and the text it writes can be spotted from across the room. You have seen the lists of twenty "essential" plugins, ranked by how often they were shared.
We kept four, chosen by problem rather than by popularity. They run on the repository of our own website. Each fixes one specific thing, each is under a free licence, and each has a limit its author states in the README. Here is what they do, what they send off your machine, and the order to install them in.
Which four tools, and which problem does each one fix?
| Tool | Problem it fixes | Form | Licence |
|---|---|---|---|
| claude-mem | The agent forgets everything between sessions | Claude Code plugin, local service | Apache 2.0 |
| Headroom | Tool output floods the context window and the bill | Local proxy, library or MCP server | Apache 2.0 |
| Humanizer | Generated prose reads like generated prose | One skill, one file | MIT |
| Task Observer | Your skills only improve when someone remembers to | A skill that watches the others | CC BY 4.0 |
The first two act on what the agent reads. The last two act on what it writes, and on how
you steer it. None of the four replaces a well-written CLAUDE.md or a human reviewer,
which is the subject of
our guide on adopting Claude Code as a team,
currently available in French.
What should you check before installing any extension?
A Claude Code plugin bundles skills, agents, hooks and MCP servers. Anthropic's documentation is direct about one thing: a plugin runs with your privileges on your machine, and Anthropic does not verify what third-party plugins contain. Before we install one, we run five checks.
| Check | The question | Where to look |
|---|---|---|
| A specific problem | Which symptom, this week, does this extension remove? | Your session history, not the project's landing page |
| What leaves the machine | Account required? Cloud sync? Telemetry? A third-party model reading what? | The README's install section and its environment variables |
| Context cost | How many tokens does it add to every turn? | The /plugin panel, "Context cost" row, before installing |
| Reversibility | Can it be removed in one command without breaking anything? | The uninstall command, and what stays on disk afterwards |
| Maintenance | Who maintains it, under which licence, since when? | The repository: last update, licence, open issues |
The /plugin panel also lists, for each extension, exactly what it will install, and later
flags the ones you have not used for two weeks across at least ten sessions. It is the
most useful sorting tool available, and the least consulted.
claude-mem: how do you give Claude Code memory between sessions?
Anyone who has picked up a task the next day knows the problem: the agent no longer knows which decision was taken, why, or which file was touched. You explain it again, in tokens and in patience.
claude-mem hooks into five points of the Claude Code lifecycle (session start, prompt submitted, tool call finished, stop, session end). At each one it captures what the agent did, compresses it into short observations, and stores them in a SQLite database on your machine. At the next session, the relevant observations are injected at startup, with their token cost shown.
The useful part is layered search. Four MCP tools let the agent query a compact index first and load the detail only for the observations it keeps. The project states roughly ten times fewer tokens consumed by filtering before fetching than by loading everything at once. That is the project's own figure, not an independent measurement. What we see on this repository is that session start summarises yesterday's decisions in a few lines instead of re-reading the history.
Two caveats to read before installing.
The installer asks for an account. Installation goes through an email sign-in. It activates a hosted "observer", free for thirty days, that runs the compression outside your Anthropic plan. After that, compression falls back to your plan unless you subscribe. You can also supply your own OpenRouter or Gemini key. You need to know which model reads your sessions, and where.
The database is local; the sync is not. Default storage stays on your machine. Backup
to the project's cloud is optional. For a team whose code or data cannot leave the
perimeter, leave it off, and wrap sensitive content in <private> tags, which the tool
excludes from storage. It is the same question as for any company data, and our usual
answer is a local AI integration rather than an exception.
Requirements: Node.js 20 or later, Bun and uv, installed automatically.
Headroom: how do you cut the tokens spent on tool output?
A coding agent spends most of its context reading things nobody reads: a hundred search
results of which three matter, a ten-thousand-line deployment log with one line that says
FATAL. You pay for every line, and the context window fills with noise.
Headroom sits between the agent and the model and compresses what the agent reads before it reaches the model: tool output, logs, files, conversation history. Compression runs on your machine; no content is sent to a third party to compress it. For Claude Code, one command:
headroom wrap claude
It starts a local proxy and relaunches Claude Code routed through it. headroom unwrap claude undoes it.
The project publishes reproducible, offline benchmarks using the provider's tokenizer. Here they are as published, bearing in mind the vendor produced them.
Token reduction measured by Headroom across four agent scenarios
| Code search (100 results) | 21 % |
|---|---|
| SRE incident debugging | 57 % |
| Codebase exploration | 42 % |
| GitHub issue triage | 30 % |
What makes this acceptable on a real project is that compression is reversible. Originals are cached locally and the model has a tool to retrieve the full text when it needs it. The compute cost is negligible: under a millisecond on a ten-thousand-token JSON result, according to the project.
The limits, in the authors' own words: short conversational exchanges, prose and
already-dense output gain little or nothing. And an anonymous telemetry beacon is on by
default. It reports how compression behaved, never content, and is switched off with
HEADROOM_BEACON=off. On a company machine, turn it off before anyone asks.
Requirements: Python 3.10 or later.
Humanizer: how do you review the prose Claude Code writes?
You asked the agent to draft a pull request description, a release note, an email to a client. The result is correct, and everyone can tell a machine wrote it: inflated words, groups of three, dashes everywhere, a closing that restates what was just said.
Humanizer is a single-file skill. It rewrites a
text against thirty-five patterns from Wikipedia's "Signs of AI writing" page, maintained
by WikiProject AI Cleanup: inflated importance, vague sources, passive constructions, fake
alternatives, filler phrases, drafting leftovers in the final text. Invoke it with
/humanizer followed by the text, or on a file.
The rule that matters is the one the author added in version 2.9: the skill invents no facts. Names, numbers, dates and quotes must come from the source text or from you. A text made natural but wrong is worse than a text that is heavy but right. It is also the rule we apply to everything we publish, this article included.
Install in Claude Code:
/plugin marketplace add blader/humanizer
What Humanizer does not do: it does not make a text true, it does not make it interesting, and it does not know your voice. Give it two or three paragraphs you actually wrote and it uses them as a reference. Without that, it swaps one generic style for another, slightly less visible one.
Task Observer: how do you improve your skills without spending your evenings on it?
Once a team has written a dozen skills, a problem appears: nobody maintains them. A correction made during a session stays in that session. The skill stays ambiguous, and the team corrects the same thing the following week.
Task Observer, published by Eoghan Henn under CC BY 4.0, is a skill that watches your work sessions. It notes three things: corrections you make to the agent's output, which signal an unclear skill; manual or repetitive work that could be systematised; and its own blind spots. Each session, it produces a structured observation log with the skill concerned and the suggested improvement.
It changes nothing itself. Observations and proposed updates are written to files you review and apply, or not. The author recommends a scheduled review session to work through them; his runs three mornings a week. Over seven months he reports more than 1,200 observations logged across his 70 skills, most of them turned into improvements. That is one person's experience, not a study.
The limit is in the README, and it is the most honest of the four: the tool's value grows with the size of the library. With a handful of skills, the agent's built-in memory and editing the file directly do the same job with less overhead. Adopt it early if you expect the library to grow, or come back to it the day manual editing stops keeping up.
Install: place the folder at .claude/skills/task-observer/ in the project, keeping its
references/ and scripts/ subfolders.
Which one should you install for your situation?
| If… | Then | Not |
|---|---|---|
| You re-explain the project to the agent every morning | claude-mem, with cloud sync off | a memory before you have written the CLAUDE.md |
| Your sessions read logs, JSON, search results | Headroom, with telemetry off | Headroom for short prose exchanges |
| The agent writes text that humans read | Humanizer, with two paragraphs of your own writing | Humanizer on code or figures |
| You maintain more than a dozen skills | Task Observer, with a weekly review on the calendar | Task Observer with three skills |
| Code or data cannot leave the perimeter | Headroom and Humanizer only, then a proper scoping | claude-mem with an account and sync |
And not all four on the same day. Each adds a layer to understand, and a problem that appears after four installs can no longer be diagnosed.
An install order that limits surprises
- 1HumanizerOne file, no dependencies, no service. Nothing to break.
- 2HeadroomA local, reversible proxy. Turn telemetry off, check with headroom doctor.
- 3claude-memAn account, a local service, a database. Decide what may be stored before installing.
- 4Task ObserverWhen the skill library outgrows what you can maintain by hand.
What mistakes come up most often?
Installing from a list. A list ranked by shares measures enthusiasm, not your problem. Start from the symptom, then look for the tool.
Not reading what will be installed. The /plugin panel lists the hooks, MCP servers
and skills an extension adds, and its context cost per turn. An always-on hook costs on
every session, not only the ones where it helps.
Leaving the defaults. An account, a sync, a telemetry beacon: each of the four has at least one setting that decides what leaves the machine. Decide it at install time, not at the first audit.
Confusing memory with conventions. claude-mem remembers what the agent did. It does
not remember what it should have done. That is the CLAUDE.md, and no extension writes it
for you.
When are these extensions the wrong answer?
Three cases where we advise against spending time on them.
You do not have a serious CLAUDE.md yet. Memory between sessions does not make up
for the absence of written conventions. The agent will remember, very well, rules nobody
set. Write the repository's manual first, then give it a memory.
Your constraint is regulatory, not technical. If your data cannot leave your infrastructure, a tool that requires an account and offers cloud sync is a compliance question before it is a tooling question. The answer is not one more plugin; it is a decision about what leaves and what stays.
Your team has no skills to observe and no prose to review. Two of the four tools fix problems you may not have. A single developer, on one project, with three skills, needs neither an observer nor a prose reviewer. They need tests.
Where to start
If your technical team already uses Claude Code and the question is how to equip it properly, the shortest route is a twenty-minute conversation about what is blocking you today: context, memory, output quality, or skill maintenance. We will tell you which of the four to install first, and which to ignore.
If the question is wider, a coding-agent rollout in a team that has not yet framed it, that is what consulting is for. And if the first need is to build the team's skills, our AI training covers Claude in professional use; a dedicated Claude Code programme is being built with the first teams who ask for it, and this page says where it stands.