This is an update to my June agentic workflow.
The basic setup is still Codex, agent-scripts, repo instructions, and a review loop. I still start by talking through what I want. Once the problem is clear enough, I want the agent to implement it, test it, and bring back something I can inspect.
The biggest change is that more of that work now reaches outside the code editor. I have been using the workflow to build tools that start Maya on another machine, load a plug-in, run a scenario, and collect the result. That puts a different kind of pressure on the setup.
It also exposed a weakness in the issue workflow I liked so much in June. Small issues and passing tests can still leave you with a product that does not work end to end.
The issue workflow needed a stronger acceptance rule
I still use the Matt Pocock-style flow I described last month. grill-with-docs helps challenge an idea against the repo. to-prd turns the discussion into a concrete outcome. The ticket skill splits that into work an agent can own, and tdd makes the behavior testable.
That is useful. But it is possible to follow all those steps and miss the point.
I ran into this with Maya Stall. The agent could finish a command, a transport layer, or a result format and show passing tests for each. Then I would try to use the tool and find a gap between those parts.
The issues had become too much about the implementation. They needed to say what I could actually do after the change.
A useful slice for this project is something like: take this plug-in build, load it into Maya on the Windows host, run the scenario, and bring back the result. That crosses several parts of the codebase. It also leaves behind something I can demonstrate.
So I tightened the acceptance rule. Start with one complete path, even if it is rough. Then make each issue extend that path. A test around a fake broker is useful during development, but it cannot close an issue that promises real Maya behavior.
The live proof gate now makes that distinction explicit. Skipping the live test cannot count as passing it.
I still want small patches. I also want each patch to leave the tool more usable than it was before.
A real example: Maya Stall
Maya Stall is the July equivalent of the gohealthcli example from June.
The problem is straightforward. If an agent changes a Maya plug-in, I want it to test that plug-in in Maya. Compiling the C++ and passing Python tests gets us part of the way. The binary still has to load, the scene has to work, and the result has to match what the tool claims to do.
Maya Stall handles the repeatable run. A scenario describes the plug-in artifacts, scripts, expected results, and visual evidence. The runner reserves a host, prepares the run, talks to the Maya session, and collects what happened.
The skills around it keep the agent from rediscovering the same setup on every task:
maya-devhandles the managed development session and the Mac-to-Windows connection.maya-plugin-e2edescribes the plug-in testing workflow.hermes-winsupplies the operating knowledge for my Windows host.autoreviewreviews the code after the relevant checks.
The distinction between the shared skill and the project matters. The skill explains how to run the proof. The plug-in repository owns what the proof must assert. Host configuration stays separate because it describes my infrastructure, not the product.
That gives me one Maya testing workflow I can reuse across plug-ins. I do not want to maintain a slightly different copy in every repository.
The work started with Maya Stall itself and its use by gg_klv_push. It then carried over to CurveDeform. A second consumer is a useful test of whether the workflow is reusable or just happens to work for the project that created it.
This is the part I wanted agents to take over. They already know how to change the code. Giving them a repeatable way to try the result lets them catch more of their own mistakes before I get involved.
The maintainer loop now has clearer ownership
The maintainer loop from June grew into bram-maintainer-loop-v2.
It still coordinates the work rather than implementing every feature itself. The useful change is clearer ownership between the coordinator and the project tasks.
For portfolio work, the model is one persistent Codex app task per repository. That task owns the repository queue and its implementation. The coordinator watches progress, handles dependencies, and brings me decisions that need my input.
I want to be able to return to a project task and see what it was doing. A short-lived subagent is useful for a bounded investigation, but I do not want unfinished implementation hidden several levels down in a conversation tree.
Running more agents also makes ordinary coordination rules matter. Check whether someone already owns the project. Preserve unfinished changes. Do not start a replacement just because a worker has gone quiet. Let active work reach a safe stopping point before changing its assignment.
Independent repositories can move in parallel. Shared hosts and overlapping work still need an order.
I removed the old maintainer skill once v2 took over. Keeping both would have left the agent choosing between two sets of instructions for the same job.
Claude for the conversation, Codex for implementation
Another useful addition is codex-first.
This is a routing skill for Claude Code. It lets me keep the conversation, specification, and review in Claude while delegating the repository work to Codex CLI.
That includes implementation and fixes, but also exploration and Git operations. Claude writes a work order with the relevant context and expected proof. Codex works through that request, and Claude can assess the result.
PDTBar gave this a practical workout. The requests covered test discovery, linting, retries, pagination, cancellation, and performance. Each work order named a bounded problem and the evidence needed to settle it.
One example I liked was the Swift test runner. A filter that matches no tests can still return a successful exit code. The work order required the runner to check whether tests actually ran.
That is exactly the kind of detail I want the loop to catch. A green command is only useful if it means what we think it means.
One place for the skills
The portability I talked about in May needed some maintenance too.
I added scripts/sync-skills so Codex and Claude Code discover the same canonical skills. Before that, a skill could be sitting in the repository without being available in both tools.
The first sync cleaned up broken links and made roughly 20 existing skills available to Claude that it had been missing. Nothing clever there. The agent has to find the instructions before it can follow them.
craft-prompt also became part of this shared setup. It turns rough notes into a usable prompt by asking one material question at a time. I used it for review prompts and implementation briefs, especially when I knew what I wanted but had not stated the constraints clearly.
It belongs before the ticket when the request is vague. Once the behavior and proof are clear, I want the agent to move on.
I also refreshed autoreview from its canonical upstream source. It gained diff secret scanning and clearer handling of findings that belong in the patch, in a follow-up, or in a decision for me.
The rule from June stays the same. Review output is advisory. The agent has to verify the finding against the real code, fix accepted findings, and rerun the relevant checks.
Peter Steinberger’s setup remains useful source material for these changes. I am more deliberate about what I bring over now. His machine paths and project assumptions do not belong in my setup just because the workflow around them is useful.
A note on models
GPT-5.6 Sol took over from GPT-5.5 as the daily coding model during July. High reasoning effort became the usual setting. Some GPT-5.5 work continued during the transition, including sessions at xhigh.
The broader split stayed familiar. Codex handled the implementation loop, and the review setup kept a separate Claude Opus 4.8 route for work that required it. codex-first made that division usable from Claude Code too.
I also added codex-huge-context, which documents the direct Responses API route for long-context work. It leaves room for output and compacts before reaching the full limit.
My opinion about context has not changed much since May. More room is useful for a long investigation. I still want the important decisions in repo docs and the current task in a focused work order. A bigger window does not make stale instructions more useful.
What I want the agent to bring back
The daily loop still uses familiar skills. Triage to choose ready work. TDD where a local test can prove the behavior. autoreview before closeout. The Maya skills when the result depends on the real application.
What changed is how far I expect that loop to go.
For a plug-in, I want the candidate loaded and the scenario exercised. I want the result and the screenshots. That also led me to start PatchProof, after looking at how Theo’s T3 Code work kept screenshots and videos with pull requests.
The evidence should stay with the change so I can inspect it later. Getting that into the normal handoff is the next part of the setup.