My Claude Code setup
A setup that grew by accumulation — and holds because it was learned, not copied.
By accumulation, not by plan
I never designed this workshop. It grew. One small problem fixed, then another, then a convention that hardened because it had been forgotten twice in a row. At some point, what looked like loose string next to my projects became the project next to the projects — the one that holds everything else together.
I didn’t notice the shift while it was happening. I noticed it when I wanted to talk about it.
Going public
At some point I’d seen enough starred Claude Code repos going around — Awesome Claude Code, LinkedIn posts from practitioners — to land on a simple thought: if I want to be credible on AI, I’d better share what I do with it.
I don’t pretend this is pure generosity. There’s a specific target behind it: a LinkedIn audience, a personal brand in the making, a professional stake in my current role. Might as well say it upfront. The rest of this story is more interesting if we don’t hide that.
”How do I make this mine?”
Whenever a repo or a post catches my eye, I paste the link into a Claude.ai conversation and ask the same question: how do I make this mine?
The verb matters. Not “how do I install it,” not “how do I translate it into French.” Making it mine is the filter. Does this tool solve a problem I already have? Does it fit the rest? Does it create more friction than it removes?
Recent example: RTK, a tool that cuts the number of tokens consumed by the standard Claude Code commands. On paper, appealing. In conversation with Claude, we landed on overkill for your setup — the context window had just moved to 1M, I’m on a subscription, the economic stake had melted. Deliberate choice of a lean approach: fewer well-appropriated tools rather than more tools that almost do the job.
That moment taught me something: Claude is a good gatekeeper against my own enthusiasm. It pushed back. It was right.
The crisis that structured everything
One evening I was stuck on a My Tsundoku bug. After searching the library, I couldn’t reorder the book cards. Looks trivial on the surface. Much less trivial underneath.
Claude shipped a fix. Then a second. Then a fifteenth, confidently every time. The logs spoke for themselves: by the fifteenth or twentieth attempt, the session was torched and so was I.
I eventually typed the magic phrase: start from scratch. Claude re-architected the component and swapped the library. The bug fell.
The rule “after 2 failures at the same level, STOP” wasn’t born in the heat of the moment. It came afterwards, in a meta-conversation with Claude.ai where I was trying to understand how to keep this from recurring. Here’s the honest part: the rule is a codified post-mortem, not a seasoned engineer’s instinct.
A caveat: in practice, the rule isn’t self-enforcing. I still have to remind Claude, push it a bit to escalate rather than retry. The models have also improved a lot since — fixes land faster, which shrinks the problem at the source. Honestly, a good chunk of the win comes from that, not from the rule.
Agents, in three waves
The agent system orchestrating my workshop today wasn’t laid down all at once. It arrived in three waves, each one in response to a named problem.
First: implementer. An agent to delegate execution, and mostly to manage model routing — Haiku for passive audits, Sonnet for day-to-day work, Opus for architecture. That’s the tool brick, before any idea of a system.
Second: troubleshooter. Right after the My Tsundoku episode. An agent that isn’t allowed to write production code — its only job is to diagnose when the implementer has failed twice, and produce a plan the implementer can follow. The rule and the agent were born together.
Third wave: portfolio-sync, docs-checker, portfolio-audit. When I decided to lay a synchronization and global-management layer over all the initiatives. By that point every project had a .portfolio.yml, every project had a README.md and a CLAUDE.md, and every project drifted in its own direction. The three agents answer the same need: hold coherence across worlds that each want to live their own life.
Tools first. A rule to repair one incident. A system to hold the whole. That’s the order it came in, and I’m not sure it can be reversed.
What it does, today
If someone at a bar asks what this workshop lets me do, I give three answers:
- Apps that are coherent with each other — same quality bar, same conventions (dark/light mode, EN/FR, author signature in the footer), same deployment pattern, same respect for free tiers. 15 apps that look like 15 apps, not 15 improvisations.
- A portfolio that tells a story — mine, and the story of what interests me. The portfolio’s recent pivot toward stories rather than a grid of apps — this piece is part of that.
- A concrete experiment in what AI changes for software development. Not a theoretical take. Code that runs, apps that actually serve people — my wife on Bas de Laine daily, Léa on Belle Forme — and field notes that hold up.
For you, if you want to borrow from it
The claude-code-setup repo is public. You can clone it tomorrow morning. I wouldn’t call that the right idea.
Here’s what to understand first: this setup carries my pet conventions. Bilingual FR/EN because my audience lives on both sides. Dark/light mode everywhere because I care about it. “Made with care by William” signature because I stand behind my authorship. Your pet conventions aren’t mine.
So the real move is the same one I made with every repo that inspired me: paste the link into a Claude conversation and ask — how do I make this mine? List your own pet conventions before importing mine. Strip what doesn’t fit. Add what you’re missing.
The sturdiest tools in this workshop aren’t the agents or the skills. They’re the conventions held over time. And conventions don’t get cloned — they get chosen.
→ The repo: github.com/w2ur/claude-code-setup