In September I shipped a new version of mira-mode to the two machines where my coding agent runs, a Mac and a cloud VM. The install checks passed on both. On the VM, one small helper command still pointed at the previous version, which was no longer installed. A background service that needed that helper was skipping its work. The install check never looked at the helper, so its green result said nothing about it. It only showed up when the VM was inspected directly.
That is the kind of problem this post is about. The agent's instructions can be right in the repo and still fail to reach it, or reach it and still be wrong. First, what mira-mode is.
What mira-mode is
My coding agent is a general model with a set of skills. A skill is a markdown file of instructions the agent reads before it starts work. mira-mode is the main one. It decides how the agent approaches a task: whether to investigate first, try a quick prototype, or build; what proof it needs before it calls the work done; and who reviews it. The goal is to take an issue all the way to a merged pull request I can trust, without me approving each step along the way.
The structure is not mine. mira-mode grew out of poteto-mode, part of pstack, the skill pack published by Lauren Tan (poteto). poteto-mode reads a request, picks a playbook such as bug fix, feature or investigation, and will not report the work as finished until it has been checked against the real thing. I kept its playbooks and principles, pinned to a specific upstream commit with the MIT licence notice, and adapted them so they load in the tools I run: Codex, Claude Code and Grok. Cursor now gets the same guidance too. pstack is mostly about execution. I also borrow from Matt Pocock's skills, which are mostly about the thinking before any code gets written. mira-mode blends both.
One rule I added myself. Every change gets reviewed by models from each of the other providers I use, never by the one that wrote it. On 2 October, for example, Claude wrote a change and Codex and Grok reviewed it. Gemini had run out of its weekly quota that day, so that review ran with two.
When the instructions are the problem
Most failures are ordinary. A test fails, a command errors, and the agent fixes it as part of the task. Some failures keep coming back because the instructions point the agent the wrong way. Those need a change to the skill itself, and I handle them in a separate loop. In my notes I call it skill loop engineering. It has five steps.
- Write down the miss with evidence: what was asked, what the agent did, what it should have done, and the file or log that shows it.
- Find where it came from. An outage, or an old copy of the skill on one machine, is not a wording problem. Rewriting the skill would not fix either.
- Make the smallest change in the place that caused it. That might be one sentence. If it is a mechanical check, it might be a script instead.
- Test the failure, and test a nearby case that must not change.
- Ship it to every machine and confirm each one actually has it.
One trip round the loop
On 1 October a batch of mira-mode changes landed that had never been run against a model. The next day I ran 22 scripted scenarios against them. In each one, a model plays the agent with mira-mode loaded and a second model grades the result out of 10. 19 passed.
One failure went like this. The agent was partway through work I had already approved and was asked for a status update. It answered and stopped. Here is how that went through the five steps.
- The record was the scenario, the agent's reply and a grade of 4.
- The cause was the wording. The rule to keep going was there, buried in the middle of a longer sentence.
- The change was one new sentence: answer in a sentence or two, then do the next safe approved step in the same turn.
- The rerun scored 10. A second scenario asks for status on work I have not approved, where the agent should report and change nothing. It scored 10 before and after, so the fix did not spill over.
- I released it as a new package version to the Mac and the VM, and compared a hash of the installed package on both. They matched.
The same run found two more single-sentence failures. I wrote that test up in more detail separately, including the one thing the rerun could not prove.
Checking delivery is its own step
Step 5 is where the September problem lived. The repo tests passed and the package was installed. The helper command on the VM was a separate piece that nothing checked. The next release repointed it, and a direct check on the VM showed the helper now pointed at the new version and ran. On 14 September, the day after the fix, the install doctor gained a check for that helper, and for three similar helper commands that could break the same way. On 23 October I widened it. Another command link had pointed at a removed copy for twelve days, so the doctor now fails on any of its own command links whose target is gone.
Knowing where a rule came from
I also check where each rule in a skill came from. One of my planning files contained the line "The goal is not fewer gates. The goal is sharper gates." It was being treated as my policy. I never wrote it. A backlog automation added it in June, and I corrected the record on 2 October. The note about it now says who actually wrote it.
Skills I borrow carry the same kind of record. They name the upstream repository and commit they came from, which is how the pstack material stays pinned to a known version. When an upstream pack changes, the new version goes through checks before it replaces the one in use. Between 7 and 10 October those checks held back four newer versions of Matt Pocock's pack in a row. The latest one changed a script and added wording about publishing and secrets, which the checks treat as sensitive. The version in use stayed on the last one that passed.
What is in place and what is not
In place today:
- Each skill change is an ordinary commit, so undoing one means reverting it.
- Reviews from the other model providers on every change.
- Upstream skill packs are checked before an update replaces the version in use.
- Some actions still wait for me. On this site the agent can open and merge routine fixes, but blog posts like this one stay as drafts until I have read them.
Not in place yet:
- A durable list of skill fixes that were tried and rejected. The loop's instructions say to record each one and why, but there is no single place that keeps them yet, so the loop could still propose the same bad fix twice.
- Repeated trials. The scenario set has grown from 22 to 63 cases since that run, but each case still runs once, so a single score change of a few points is noise to me.
The questions I ask for each repeated miss
- What did the agent do, what should it have done, and which file shows it?
- Is the cause the wording, or something else, such as an outage or an old copy on one machine?
- What is the smallest change, and where does it belong?
- Which test shows the failure is fixed, and which shows the nearby behaviour has not changed?
- Has every machine that runs the agent got the new version, including the helpers around it?