The most useful rule I added was the one that deletes rules.
I have spent most of this year building Twinpage, a split-testing tool for websites, with Claude Code doing most of the typing. At the last count it is 153 features. Somewhere in the middle my setup stopped being a CLAUDE.md file and became a process: roles, checklists, a retro after every feature, and, the part I did not plan for, a scheduled audit that throws rules away.
I have open-sourced that process as Morphness. The five lessons below stand on their own, whether or not you install it.
1. One agent cannot check its own work
Early on, "done" meant the agent said it was done. That held until I started finding features that compiled, passed the tests the agent wrote, and still did not do what I had asked.
The fix was splitting the job into roles that do not trust each other:
- A Technical Lead in the main chat plans each feature with acceptance criteria I can test, and waits for my approval before anything is built.
- A Full-stack subagent builds it.
- A separate QA subagent checks every criterion and records evidence: the commands it ran, their exit codes, the screenshots it opened. The feature's pull request stays a draft until QA passes, so nothing looks ready for review before it is.
The point is not that QA is smarter than the builder. It starts with a fresh context and a list of claims to verify, instead of a memory of having written the code. There is a light mode for one-file quick fixes and doc changes, but the default when unsure is the full loop.
2. The plan is where most bugs die
The cheapest place to catch a mistake is before any code exists. Over time the Lead's planning checklist grew from a handful of lines into the most valuable file in the repo. It asks things like: which loading, failure and timeout states does this screen have, which entry points trigger this action, what must not move when two UI states are compared, and which facts about a third-party service are we assuming instead of reading?
That last one came from real pain. A plan leaned on a platform default that had changed, and nobody had read the vendor's changelog. Now, for every vendor fact (a price, a limit, a plan tier, a default), the plan has to say whether an agent can read the source from the session. If it cannot, the fact stays out of the plan or becomes a human step.
3. Every feature ends with a retro
After each full-harness feature, the Lead writes a short retro: what went wrong, why, and what rule would have prevented it. A rule lands in the narrowest file that every agent who needs it already reads, with the feature that taught it noted in parentheses at the end, so a later audit can find its evidence.
Some of the rules that came out of this:
- Prove a regression test with a negative test. Restore the bug, run the new test, watch it fail, restore the fix. A test that passes with and without the fix guards nothing, and nobody notices until the bug comes back.
- QA opens a screenshot per planned state. On two features, QA had opened 5 of 24 and 12 of 88 screenshots, and missed visible defects.
- A review result never ends the Lead's turn. A thread once sat idle after a code review until I asked what was happening.
None of these are clever. All of them are things I would not have written up front.
4. Rules only grow, unless you prune them
Here is the problem with retros: they only add. After a few dozen features, the rules file was long enough that the agent was clearly skimming it, and every session paid for context that mostly did not apply.
So every 10 features, the Lead runs a prune. It audits each rule added or touched since the last one and marks it with evidence:
- fired: a retro records it catching something, so it stays.
- never fired: no failure or retro has mentioned it since it landed.
- too new to judge: it landed in the last 3 features.
- insurance: it rarely triggers but prevents a costly failure, and the audit has to name the cost.
A rule that never fires in one window gets questioned. One that never fires in two windows moves to an on-demand file that agents read only when it applies, or it goes. A prune also runs early if the Lead's rules file passes 20 KB. The Lead only proposes; I approve each row, and a prune that cuts nothing is a valid result.
The first prune was humbling. Rules I had been proud of had never once caught anything. Removing them did not make the agents worse. The rules that remained were the ones that had earned their place, and the agents actually read them.
5. A rule that earned its place in one repo can help the next
After 153 features I had a set of rules with something most advice about AI coding lacks: a record. Every one notes how many features ran while it existed, and about half record how many times they fired. The rest are marked unknown, because my early audits did not count.
That is what Morphness ships with: 112 lessons from Twinpage. 83 are already part of the default kit. The other 29 are specific to a stack or a service (Next.js, Supabase, Playwright, Vercel, Paddle and a few more) and are offered only when they match your project.
The part I am most curious about is what happens next. When a rule proves itself in your repo, /morph-share strips out your project's names and paths and drafts it as a lesson for the catalog, with its evidence attached. Right now every lesson comes from one project. I would like yours to be the second.
How to try it
Morphness is a Claude Code plugin, MIT licensed:
/plugin marketplace add antarsoft/morphness
/plugin install morphness@morphness
/morph-init
/morph-init works on new and ongoing repos. On an ongoing one it scans the code first and uses what it finds as suggested answers, then asks one question at a time: what you are building, who approves, your stack, your branches and environments, the commands behind each check, and which optional modules you want. It keeps your CLAUDE.md, copies the kit without overwriting your files, and lands everything on a branch for you to review.
After that, you start a feature with plan <feature> and the Lead takes it from there. Every hand-off ends with the prune counter, and at 10 it tells you a prune is due. When the kit improves upstream, /morph-update lists what changed and applies only what you accept, merged with the edits your harness has made to itself.
What I would do even without it
If you take one thing from this: give your agent rules a delete button. Write down why each rule exists, check whether it ever fires, and remove the ones that do not. Short, earned context beats long, hopeful context.
The repo is at github.com/antarsoft/morphness. I would especially like to hear what breaks when you install it on a stack that is not Next.js, and whether every 10 features is the right prune cadence for your project.
Top comments (0)