It's public. Please don't install it
The harness I have been writing about since June is public: github.com/dangnhh92/viber-harness, MIT. It is the rules file, the five agent definitions, the memory store and the one-file Python CLI that I start every project on. I use it to build the apps on this site and to run Claude as my day-to-day assistant. The README lists what is in it and what each part is for, so I will not repeat that here.
What I want to say is how to read it, because the wrong way to read it is obvious and tempting.
The wrong way
Clone it, run the four install lines, and now you have my habits. I have already written why that fails: every rule in there is a scar from a specific afternoon I lost, and your afternoons will be different. I have also written why chasing the tool of the week slows you down when you do not yet know where your own friction is. Putting the harness on GitHub changes neither argument. It makes the temptation one command shorter.
The README says it plainly: use Claude Code as it is until you hit a real problem in the way you work, then find the fix for that problem. Everything in the repo is something I wrote after hitting the problem, and the order I hit them in is not the order you will.
The right way
The part of the README worth your time is a two-column table: a pain on the left, the mechanism that answers it on the right. "The agent says done and it is not." "Numbers in memory go stale." "The same mistake repeats." Read down the left column. If none of them stings, close the tab. You do not have the problem yet, and installing the fix would only give you something to maintain. If one does sting, read the right column for that row and build your own version of it, in your own words, in your own CLAUDE.md. The unit you take is a row of that table. The repo stays where it is.
Some rows carry a longer story than the table has room for. The stale-numbers row, for instance, came out of a test I ran on my own memory files, where a written rule held on the strong model and did nothing at all on the cheap one. One row deserves a fuller telling here, because it is the row that reversed something I had said in print.
The row that reversed me
In June I wrote that a swarm of agents, one to plan, one to code, one to review, one to orchestrate, is the most expensive mistake people get talked into, and that almost nobody needs more than one good agent managed well. The public repo has an orchestrator, four working agents and a reviewer. So either I was wrong then or I am wrong now, and it is worth being exact about which.
I stand by the June version of the problem. Agents talking to each other, each reading the others' output, is cross-talk you pay for and cannot audit. What changed is that in August I measured my own reviewing and found it had stopped working. When a project fits in your head, review is just reading. Once it outgrows your head you keep reading diffs the same way, they look fine, you approve them, and what you have approved is that nothing obviously failed. I had done that for about six weeks on two games. The post ended on a question: for each piece of work, what is the cheapest check that fails loudly, and where does it have to sit so that neither I nor the agent can walk past it.
The review gate is the answer for one kind of work. A feat, fix or refactor commit does not happen until a fresh reviewer has read the whole diff against a scope contract written before the work started: the anchor symbol, the base commit, the file globs the work was allowed to touch, and the acceptance criteria. A high finding blocks. A medium finding inside the contract blocks. Two rounds at most; if something is still open after the second, there is no commit, and the orchestrator decides what to do instead of running a third. Each finding is recorded by file and problem, so when the same one comes back after a "fix", the harness raises a repeat signal on its own rather than filing it as new.
Measured against the June complaint, this is a different shape. The reviewer never talks to the agent that wrote the code. It gets a diff and a contract, returns a list, and is thrown away. The orchestrator carries the list back verbatim. Nobody negotiates. It is one manager and a second reader, sitting exactly where I had stopped reading, and it costs one reviewer pass per commit. The June post was about coordination. This is about the one check a writer cannot run on their own work, which is why a second reader exists in any craft.
I would not have built it in June. I did not have the problem in June. That is the point of the whole repo.
If you do install it
Four lines, in the README. The only command you ever type is init; the orchestrator runs everything else in the CLI. Copying into an existing project overwrites CLAUDE.md, AGENTS.md and .gitignore, so extract into an empty folder first if you already have those. There is no update command. You pull, run the same archive line again, and diff CLAUDE.md before overwriting your edits. That is deliberate. The file is supposed to have your edits in it.
The plugins section is a list of problems, each next to the one plugin I added when the problem stopped being theoretical. Start with none. Three of the popular ones overlap with what the harness already does, and the README names them, so you can decide before enabling them rather than after.
It keeps changing as I keep building. When it stops fitting how I work, it will change again. Yours should do the same.