Theo’s Three Skills for Reviewing and Shipping with Coding Agents

I used to talk about new technologies and frameworks; now I am making a video about three Markdown files. They have meaningfully changed how I build. The skills are sol-loop, full-send and full-stop, and they grew out of behaviors I repeated rather than concepts I invented in advance.

Almost half my T3 Code threads use one of these skills, and I suspect most changes that reach main use at least one. They encode the way I already work, helping me delegate more consistently and decide when a thread needs my attention.

I keep my skills in a repository called fleet, which tracks configuration across my machines. T3 Code connects to multiple machines, but synchronizing authentication, skills and MCPs still takes work. The repository groups skills by where I want them available: everywhere, on a particular machine, or only in a particular harness.

I use fewer skills than I initially expected. Besides these three, I often use pull-request skills for filing, monitoring and commenting. One asks an agent using my account to identify its model and disclose that it is responding on my behalf.

I still think writing and reading your own skills is important. I first wrote sol-loop myself, then asked an agent to update it after noticing mistakes. On rereading it later, I found language I wanted to change; the file should describe the workflow I actually want, not simply accumulate instructions.

The sol-loop description is a trigger: use it when I say sol-loop. The working agent owns the change while a Sol model reviews it. The goal is the smallest change that meets the intent; fix valid findings, push back on incorrect ones and stop when agreement or the review budget is reached.

Scope creep is a real risk when agents with different opinions review each other. My default budget is three rounds: a full first review, then reviews of changed code and open findings. It can extend to five for serious risks such as security, permissions or data loss. Stop early for nits, and use only one reviewer at a time without nested reviewers.

I generally find Opus 5.5 pleasant to collaborate with and good at writing code, while GPT-6.1 Sol is especially thorough in review. This is my experience, not a universal ranking. Running the review locally before filing a PR catches issues before review bots and teammates see them.

I also want the PR to state how many sol-loop rounds ran, which model reviewed them, and the verdict. I added the verdict because I noticed the working model sometimes seemed inclined to hide an unfavorable review. Inspecting and editing the skill is how I fix that behavior.

There are several ways to give a working agent access to a different model. I use a CLI proxy and keep request data in ClickHouse so I can inspect usage. Subscription rules differ between providers, so I caution viewers to pay attention to the conditions for each service rather than assume every arrangement is interchangeable.

T3 Code's Orchestrator V2 offers another approach: one agent can delegate to other agents in their native harnesses. In my example, a Claude Code thread asks several models to review SQLite-related changes. Each reviewer has its own thread and can report back to the main one.

Different models are trained differently and tend to notice different problems, much as reviewers with different experience do. I find OpenAI models particularly thorough and Claude useful for unusual risks, while other models can also contribute. My observations are subjective, and I still evaluate the feedback instead of automatically accepting it.

You can try the general pattern without copying my skill: delegate to several reviewers, compare their answers, refine the dispatch and repeat. In my experience this can delay opening a PR but reduce issues during review, so the change gets merged faster and I send less poor-quality work to my team.

To understand full-send, think of the T3 Code sidebar as an inbox. A completed or abandoned thread can be settled and disappear from the active view. My goal is not to merge poor changes quickly; it is to avoid a large backlog of threads waiting for me while making it easy to merge with confidence.

Working threads can stay in a separate section until they need attention. If the agent asks through a question tool, the thread returns to the inbox. For a small change where I understand the intended approach, I do not want to revisit the thread just to press merge after the agent has finished and verified it.

Full-send is triggered only when I explicitly request it. It tells the agent to own the work through a merged PR and not assume that level of autonomy otherwise. In my own skill I explicitly authorize merging after the gates pass and force-pushing the PR's own branch with force-with-lease after a rebase.

The workflow is to finish the change, prove it, open the PR, monitor it, merge and report. I edit the skill when I see an agent miss a step. For example, I explicitly tell it to use T3 Code's PR watcher and to stop watching if it ends before merge.

Proof means evidence observed in the session: command output, a reproduction or screenshots. Reproduce a bug, fix it and see the reproduction pass; run the relevant CI checks and add a focused test where appropriate. For UI behavior, run the app and inspect it, because green mocked tests do not establish the user experience.

My merge gate requires evidence covering the changes, passing required checks, completed review bots with findings addressed or dismissed in writing, no outstanding human request for changes, and an up-to-date branch that GitHub reports as mergeable. Only then may the agent merge under my explicit authorization.

An agent also needs a reliable way to reach me when I am not watching. I instruct it to use the harness's question tool, include the PR and blocking context, and ask only when it cannot proceed alone. An ordinary message can go unseen, making the thread look finished when it is actually waiting.

In one limited usage window I found 32 full-send requests, of which 27 merged without another look from me. That is my own observation, not a general success rate. The workflow depends on verification and safety nets: T3 Code ships nightly builds every six hours, giving us feedback and a chance to fix problems before stable release.

No verification system is perfect. As you gain experience with agents, you develop a sense of what a model can verify and what needs another human look. The ability to roll back mistakes with minimal harm matters even when the agent and its checks are good.

Full-stop exists because I liked the full-send workflow but wanted a boundary for riskier changes. It should keep fixing, checking and reviewing until a PR is ready for me to merge, but never merge it. It should handle CI failures, review bots and team feedback, and interrupt only for a real blocker or when the PR is ready.

I also use a takeover skill for existing PRs or branches. It asks the agent to understand the original goal and decide whether to continue on the existing work or use it as a reference for a new PR. In either case, preserving the original contributor's credit matters to me.

A modernize skill handles stale PRs: rebase on main, check whether other changes have already solved the problem, and close the PR if it is no longer needed. These skills form a graph. I turned repeated modernization and takeover work into skills, then added review, end-to-end completion and a stop-before-merge variant as my needs changed.

People ask why I do not disable model invocation and use slash commands for every skill. Manual invocation is useful when you want a skill to run only by a specific command, but I prefer to describe trigger phrases in the skills. I can type or dictate combinations such as takeover, sol-loop and full-stop without remembering special syntax.

Some harnesses also make it difficult to invoke several skills manually at once. My approach lets the agent recognize multiple requested workflows from ordinary language. The descriptions need to be precise enough that a skill with significant authority does not activate accidentally.

For example, I asked an agent to take over a contributor's Windows Explorer fix and full-send it. It created and verified a replacement PR, merged it and credited the original author. The important ingredients were the combined skills, the explicit merge authority and a check that the change worked and was safe.

I am considering sharing these skills in a project called T-stack; the video's description links to the repository. The lesson is not that everyone should copy my Markdown. It is to notice repeated problems in your own workflow and encode the decisions and boundaries you want your agents to follow.

My role has shifted toward managing the workflow at a different layer. To get more from agents, examine what you do and do not trust them to handle, and put those expectations into skills. The abstraction should help you ship effectively while retaining the verification and intervention points your work needs.