Alexandre Blause
← Back to the work

AtelierUpdated Nov 2026

How I work with coding agentsThe system is mine: the architecture, the rules and the review.

I run Claude Code as a pair programmer, inside rules, skills and hooks I wrote. It proposes and executes; I decide, and nothing merges without my review. Below: the skills I wrote for it, the mistakes that became rules, what is enforced rather than asked, and where it still fails.

Agent
Claude Code
Its role
Pair programmer. Never merges alone.
Reviewed by
Me, every change
Works in
Parallel git worktrees, one task each

From ticket to merge

The system I built, then one real run of it, with each decision I took.

MERGE
Merge gate, freed only by the keyThe ticketAgents do the work through skills, rules and hooks I wrote; a hook stops the carriage until its check passes. Nothing merges until I turn the key, and a rejected ticket becomes a new rule.
  1. feature-prior-art11 ranked rules from how developers show their agents, sources cited
  2. ui-ux-designJourney, wireframe and two placements, sent for review
  3. Alexandre“Placement A. Build it.”
  4. 2 agents in parallelOne draws the figure, one the mascot; the page is built here
  5. Alexandre“Drop the counts. Skills first, like a video game.”
  6. ux-reviewer6 findings: 2 fixed, 1 declined with its reason
  7. Alexandre“Credit me. Cut the skills that read as chores.”
  8. pr-lifecyclePR opened, before and after attached, no conflict
  9. Alexandre“I review first.”
My decisionsAgent stepsReplayed from the session that built this page and the workshop section.

Skill tree

Every skill the agent can use. I designed and wrote the first six classes; the last one is Anthropic's official review, security and skill tooling I run on every change.

ArchitectShape it before it is built

  • feature-prior-artActiveResearches how established products solve a screen or a flow, and returns ranked rules with sources.
  • ui-ux-designActiveJourney, hierarchy, every state and a wireframe, approved before any code.
  • product-coherenceActiveMaps a feature against every path in the product: no second route to the same outcome, no copy that over-promises.

DebuggerProve it, then fix it

  • bug-diagnosisActiveA command that fails on the bug first, one falsifiable hypothesis at a time, then the same command passing.
    Read an excerpt of the skill
    ## 1. Build a command that fails on this bug

One command you have run at least once, that is:

- on the user's exact symptom: it asserts what they saw, not "it does not crash", so it cannot pass while this bug is still there;
- deterministic: same verdict every run;
- fast: seconds, so it can run after every change;
- unattended: you run it, not the user.

## 3. Hypotheses that can be wrong

Write three to five, ranked, before testing any: a single one anchors on the first plausible idea. Each states its prediction: "if X is the cause, changing Y makes the bug disappear".
  • mobile-devicesActiveDrives iOS simulators and Android emulators through their view hierarchy as text, never by window clicks.
  • ux-reviewerCompanionA fresh-eyed reviewer that checks every built screen against the design rules it did not write.
  • fact-checker-verifierCompanionChecks every figure and date against two sources before anything is published.

ShipperFrom branch to merge

  • pr-lifecycleActiveFrom first push to confirmed merge: CI watched after every push, conflicts resolved, merged only on my word.
  • worktree-isolationActiveRuns a dev server or a migration in its own worktree, on its own port and database.
  • before-and-afterActiveCaptures a UI change before and after and attaches both to its pull request.

OrchestratorMany agents, one direction

  • coordinatorActiveSplits a feature into tasks, one agent per worktree, then reviews and merges their pull requests.
  • parallel-agentsActiveRuns independent fixes in parallel subagents, then integrates and verifies once.
  • handoffActiveSends side work found on the way to its own worktree and agent, never into the branch in hand.
  • foremanActiveWatches every background session across projects, spots what is stuck and proposes the next move.

OperatorPlan the day, improve the system

  • daily-planActiveEach morning, ranks the day's work from open PRs, production errors, issues and product data.
  • weekly-agent-auditActiveReads a week of sessions and proposes fixes to my own rules and skills. Nothing changes without approval.

GuardianHooks that are always on

  • machine-locksPassiveQueues simulators, databases and ports between parallel sessions, and blocks commands that would hit them all at once.
  • review-nudgePassiveRaises a review prompt as soon as a diff grows past a size worth a second look.
  • where-we-arePassiveKeeps a live line on where the work stands and what the next action is.
  • config-syncPassiveCommits and pushes any agent config change left behind when a session ends.

From AnthropicOfficial, run on every change

  • code-reviewOfficialReviews every diff for correctness bugs before it merges, up to a multi-agent review in the cloud for large changes.
  • claude-securityOfficialScans a codebase or a change for vulnerabilities, then turns findings into patches checked by a panel of agents.
  • skill-creatorOfficialBuilds and benchmarks new skills with evals, so a skill is measured before it is trusted.
  • claude-apiOfficialReference for building product features on the Claude API: models, tool use, prompt caching.

Third-partyanatomy

Mistakes that became rules

  1. MistakeThe agent read a stale database client as a live foreign-key violation, and a stale mail library as broken auth.Rule nowRestart the dev server after a schema, client or dependency change, before concluding anything.
  2. MistakeIt handed back screenshots it had not looked at, and I spotted the fault first.Rule nowRead every capture you take and say what is on it, including what you did not expect.
  3. MistakeIt called a mobile app done because the build and the tests were green.Rule nowLaunch it on the platform it ships to and read a capture before saying it works.

Asked, and enforced

  • Asked, in a ruleStop only what you started: end a process by its PID or its own port, never by name, because parallel worktrees run the same servers.
  • Enforced, by a hookBefore any shell command runs, a hook checks it against the machine's locks. Commands that would hit every session at once, such as killall Simulator or adb kill-server, never run.

Where it still fails

  • It can be confidently wrong. That is why I review and merge every change myself.
  • A green test suite says nothing about an app on its device: it has to launch the app and look.
  • It forgets between conversations unless a rule or a memory note carries it over.
  • My hooks read the command text: they stop a slip, not a script written to get around them.

Tooling I built for it

  • herdr-flutter ↗: open source: a coding agent watches and hot reloads a running Flutter app
  • RunnerDock: self-hosted GitHub Actions runners on Apple Silicon
  • worktree-ports: parallel git worktrees with their own ports and databases
  • ask-me-by-phone: the agent calls me when it is blocked
  • hermes-os: a persistent product studio of agents

References

I researched this page with feature-prior-art, designed it with ui-ux-design, had agents build it in parallel, and reviewed every change before merging it.