Back in July I wrote up the Solo Agent Context Kit and mostly left it alone. Since then it has been running on real projects, not just the template repo, and like anything that survives contact with actual work it did not stay the same shape. I want to log what changed and why, partly so I remember, and partly because I know a few people picked up the template.
The biggest addition happened before this week. I was running a metaproteomics analysis on RM 8048, a NIST reference material, and learned the hard way why you pin an external data snapshot before you start, and why you tripwire a derived count before you trust it. Numbers drift if you are not careful about where they came from, and once I actually got burned by it the fix was obvious. That became the reproducibility and tripwire sections in AGENTS.md, plus the broader rule everything else hangs off: never assume, always check.
This week I went back through the kit with Claude and found three real problems.
First, my commit messages were bad. Long, narrated, more explaining than a commit message needs. So now commit messages, and everything the agent writes in PLAN, NOTES, and JOURNAL, follow ASD-STE100. It is the simplified technical English standard aerospace maintenance manuals use, short sentences, one idea each, no padding. Turns out it is a good habit for an agent’s own writing too, not just what it hands to a human.
Second, PLAN and NOTES kept blending into each other, and not just in one project. A finished phase in PLAN would get a full writeup, what was built, which files changed, usage examples, and NOTES would often get a near duplicate of the same thing under its own phase heading. Neither file was doing its actual job anymore. PLAN was turning into a journal, and NOTES was quietly growing a second, unfiltered history alongside its real job of holding decisions. The fix is boring but it works: once a phase is checked off, it collapses to one line under Completed, not a full rewrite. NOTES only takes non-obvious rationale, and only resolved rationale. Nothing open-ended lives there anymore.
Third, the verification gap. I was looking at a separate project’s context files after they had been running for about six weeks, and it had grown its own verification section, born out of a real session where the agent had a contradicting test result sitting right in front of it and argued its way around it instead of accepting it. The kit’s original prime directive already covered acquiring facts honestly, read the file, run the check, do not trust memory, but it never said anything about what happens after you already have the number and do not like it. So I added a line for that: a contradicting result outranks your hypothesis, report it and stop, do not re-interpret it until it agrees with you.
One more small thing, because I liked it enough to mention it. Before committing that last rule I had Claude audit the kit’s language for the pink elephant effect, telling someone not to do something can prime the very behavior if there is nothing positive attached to replace it. We went through every “do not” and “never” already in the kit. All of them pair with a concrete action, or point at a specific tag like (locked) or dead-end, none of them are just a vague thing to avoid. Nothing needed to change, but I was glad we checked before adding one more.
Three things I only noticed after the fact
None of this was planned when I first put the kit together, but sitting with it for a few weeks, and going back through it this week, a few things became obvious that were not obvious in July.
The first is how a problem actually gets promoted into the kit. Every fix so far has come from spotting a real, live problem in an actual project, RM 8048 for the reproducibility rules, a separate project’s own verification section for the contradicting-result rule this week, and pulling exactly the one rule that fixed it back into the template. I thought for a while I might want a standing place to log problems as they happened, a little mistakes.md, and only promote the ones that kept recurring. Turns out that is the wrong shape. A repo of accumulated lessons only pays off if you actually go read it, and there is no good moment to do that, read it every session and it is mostly noise for whatever you are working on that day, leave it unread and it never gets used at all. What actually works is asking on demand, go look at how this specific project’s files actually turned out, and mining the real thing instead of maintaining a summary of it. My projects are already the knowledge base. I do not need a second one.
The second is that PLAN and NOTES, without me setting out to build this, ended up being a changelog and an ADR system for one person. Real architecture decision records exist because a team of people, spread out across time, need a reason a decision will not get silently relitigated by someone who was not in the room. Real changelogs exist because someone downstream, who did not read the diff, needs to know what changed. I do not have either problem, it is me and an agent, synchronous, one thread of work, so NOTES does not need a status field and PLAN does not need version numbers, but the underlying shape is the same one, just sized down to an audience of one.
The third I only noticed by accident. I was comparing the kit against one of Anthropic’s own guides on keeping token costs down, mostly out of curiosity, and realized the kit was already doing most of it without me trying to. Cold start means every session only reads a handful of small, targeted files instead of a whole project’s history, so a session stays well under whatever the actual context window is, even the bigger ones, without me ever managing that on purpose. Progressive disclosure, targeted edits only, skimming NOTES instead of reading it end to end, all of that turned out to be cost discipline wearing a different name. I built it to survive a cold start with zero memory. Keeping the context window small turned out to be the same problem solved twice for free.
Full changelog below. If you want the original writeup and the file templates, they are still at the first post, and the live template is at github.com/neely/agent-context-project-template.
Changelog
2026-08-17 / 08-18
- Commit messages, and everything the agent writes in PLAN, NOTES, and JOURNAL, follow ASD-STE100.
- NOTES.md is resolved-only. Open items live in PLAN.md, never NOTES.
- Finished PLAN phases collapse to one line under Completed instead of keeping a full writeup around forever.
- PLAN.md opens with a Purpose and Non-goals line now, asked for on first run.
- Added a fourth line to the prime directive: a contradicting result outranks your hypothesis.
2026-08-05
- Generalized the prime directive to every project, not just data-heavy ones.
- Removed the duplicate copy of the guide that had been living in the repo itself. It just links here now.
2026-08-03
- Added the self-consuming first-run section. Asks its setup questions once, then deletes itself.
2026-07-27
- Added the prime directive, reproducibility pinning, and tripwire sections, straight out of what RM 8048 taught me.
2026-08-12
- Added a non-commercial license.
2026-07-13
- Original kit, and this post’s first version.