Run a self-improving Claude Code review and handoff harness for a team

Anatolii Landyshev grew a set of Claude Code skills, hooks and tools for a mobile app rewrite; five engineers used it daily and about 70 harness commits came from its own retrospectives.

Done withClaude CodeCodex· Oct 20, 2026

What they did

Landyshev led the rewrite of a sports-tech company's iOS and Android app from February 2026 and built a harness on top of Claude Code one problem at a time. It started with a /branch-review skill that checks changes against the documented architecture and conventions, a /retro skill that turns each session's friction into proposals he approves, and skills that sync docs and gate merge requests. Later came a /handoff skill that runs the retro and writes a resume prompt for a fresh session, review by 2 to 4 agents each with its own lens, a hook that blocks git commands with no working directory, worker subagents in git worktrees for mechanical pieces, and a manager session that keeps a shared task board for parallel sessions. The skills moved into the repo so the whole team got them. Near the end he had Codex models review what Claude wrote.

How it went

By the end it was 13 shared skills, 4 subagents, 23 small tools and some hooks, used daily by 5 engineers, most of whom moved to Claude Code for it. About 70 commits to the harness came from retrospectives. An overnight loop of up to 4 review rounds was made the default and reverted 12 days later, because rounds 3 and 4 found only comment fixes at about 250k tokens each. On a ported physics library, 6 review rounds found nothing, but a hand-written review that mutated the code 60 times showed the tests missed 14. A merge request reviewed only by the session that wrote it let a major defect through.

Worth knowing

He ran no controlled comparison, so there is no proof the harness raised productivity. Rules written as prompts kept failing until they became scripts or hooks, such as a tool that edits one board row after a session overwrote the whole file. The self-editing harness drifted, with stale instructions the retros did not catch.

Try it

With Claude Code· 3 parts to fill in

You are working in [repository] with conventions documented in [docs folder]. Review the changes on [branch] against those conventions, citing the rule for each finding and saying when the docs are silent. Then run a short retrospective on this session: what took longer than it should have, sorted into tools, prompts, docs and process, with one concrete change proposed for each. Where a rule keeps being broken, propose a script or hook that checks it instead of another instruction. Show me the proposals and wait for my approval before editing any skill, doc or hook.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related