Theo Walks Through Three Markdown Skills He Says Changed How He Ships Code

Theo starts by acknowledging how far the video's subject has moved from his earlier work. He says he used to sit down and present new technologies, frameworks and ways of building software. Now he is making a whole video about three markdown files, which he admits feels a little silly, while also saying those files have meaningfully changed how he builds.

He says he has been using the three skills, sole loop, full send and full stop, a lot recently and has received many questions about them, which is why he decided to explain them. He stresses that they were not designed from a clever concept. Instead, they came from behaviors he found himself repeating and then turned into skills, which he says helped him solidify how he builds.

He puts numbers on how much the skills appear in his work. When he works on T3 Code, almost half of his threads use one of the three skills. He also says he would bet that the changes merged into main almost always use at least one of them.

Theo says the easiest way to follow the skills is to start with an overview of how he manages them. He keeps a repo on his computer called fleet, which he describes as the only repo he almost ever opens in VS Code. It stores data about his fleet of machines, the different computers he works on. With T3 Code he can connect to many machines and control them from one app or a phone app, but keeping them synced, including auth, skills and MCPs, can be annoying, so he tracks all of it in fleet.

Inside the repo he groups skills into folders: some he only wants in Claude, some only on one particular machine he calls command center, and some he wants on nearly everything. He says he will probably go through and delete many of them because he has not been using as many as he expected.

He notes that he still pulls out a Matt Pocock grilling skill now and then, but most of his use comes from sole loop, full send, full stop and his PR-related skills, such as file PR and babysit PR. He also mentions a simple skill that tells agents to state which model they are and that they are responding on his behalf when they leave comments through his account.

Theo says he has said many times that writing these instructions yourself is a good idea, and he still believes it even though he does not always follow it. For sole loop, he let agents take over more. He first wrote it by hand, but noticed a few things Claude was doing wrong and told it to update the skill to fix those mistakes. When he read it again recently he found it had become quite bloated, and he plans to clean it up.

He then explains that descriptions in skills are not what they sound like. A description should not describe what the skill is. It is an indicator to the model about when the skill should be used. Most of his descriptions are short triggers. For sole loop, the skill is named sole loop and its description is use when the user says sole loop, so it should not be pulled in unless he mentions it or another skill does.

The skill itself, as he summarizes it, has the agent own the code while a reviewer called Soul reviews it. The agent fixes what is right, pushes back on what is wrong, and stops when it agrees or the budget ends, aiming for the smallest change that meets the intent. He says he rewrote the description himself after noticing the first version contained some slop that he attributes to Opus. The stated purpose is to make code changes more correct before or sometimes after filing a pull request, and his summary is that the model should use Soul to review code in a loop, making the most minimal possible changes to appease the reviewers.

Theo calls the guidance to be careful about scope creep and not be scared to push back very important. He describes the risk: with several agents holding different opinions and talking over each other, a review can quickly leave the scope blown up and the PR much larger than it needs to be. He says the simple addition of these lines helps prevent much of that.

The skill includes a budget section, because he says otherwise the loop would go on forever. The budget is three rounds total. Round one is a full review, and later rounds check only changed code and open findings. It extends to five rounds only if there is a security issue, a risk of data loss or another risky case. The loop also stops early if a round returns only nits, and reviewers decline nits, comments, docs and other less important items.

There are two more constraints. Only one reviewer runs at a time, and Soul must not start sub-agents or its own reviewers, since that would nest very quickly. The skill also tells the agent to track what the reviewer reports, along with a section on the scope and on how to call Soul.

Theo says he mostly uses this skill with Opus 5.5, which he finds to be a much better collaborator, overall smarter, writing much better code and generally more pleasant to work with. For reviews, however, he prefers GPT-6 Soul, which he describes as more thorough. He says it really does feel like a Rottweiler: it grabs onto the problem and doesn't let go, which is why he likes using it for reviews. He says this skill and workflow have prevented PRs from ending up in an infinite review loop once they are on GitHub.

Theo says that since he is not using his Codex subscription much lately, this has been a good way to keep using it while doing his daily work in Opus. He adds a small feature he finds useful. When a PR is filed or updated, a blurb at the end tells the agent to add a section to the bottom that states the PR was reviewed with the Soul loop, with N rounds and a given model.

He also adds a Soul verdict line, for example approved. He says he added it because he has noticed a few times that Opus almost seems to want to hide the fact that Soul was not happy with the changes, and the new line calls that out directly. He notes that this is why it matters to edit these files yourself, and says he is shipping the updated sole loop skill and pushing it across the fleet.

Theo explains that the easiest way to give Claude Code access to Soul is to set up CLI proxy so that all auth lives in one place. He says he has used it for a while and customized his dashboard heavily to see how fast he burns through rate limits and where traffic goes. He even set it up to dump all requests and responses into a ClickHouse database he can query. Once it is set up, the models it exposes can be used in whatever tools he wants.

He warns that the Claude models should be used carefully in other places. If someone uses a Claude Code subscription, Anthropic is very upset if the system prompt is not the Claude Code system prompt, so he says Claude subscriptions should only be used with Claude Code. He uses his Codex subscription with Codex, and his Claude subscription with Claude, but he also uses his Codex subscription in other tools, including Claude through this setup, because in his words OpenAI does not care where tokens are used while Anthropic cares a lot.

Theo says that if you worry about getting banned for this setup, you do not need to, because Tibo quote-tweeted it, calling it a blessed solution and saying that if it does get someone blocked, he owes them a reset. Theo says this is allowed as far as the providers have officially stated. He adds that this setup lets you keep Claude Code, with its sub-agents, while still getting the reviews.

Theo suggests a simpler way to start for anyone who does not want to scale it up yet: delegate to N sub-agents, compare the answers, refine the dispatching, and repeat as needed. He shows a verdict from Soul in one thread that reports no important product-code findings and that all seven tests passed, followed by other issues it cares about.

His conclusion is that when he invokes this skill, the PR that goes up has fewer issues, is more likely to be correct, and gets through review and merges faster. He admits that opening the PR takes longer to start when he sends the prompt, but he says far less time passes before it is closed. He says he values most that he does not want to throw a bunch of slop at his team, and that the skill reduces the chance slop moves from a T3 Code thread, or whatever tool he is using, into a pull request.

Before getting to full send and full stop, Theo explains a mindset change for T3 Code: treat the sidebar as an inbox. When work is done it should go away. He calls settling a thread similar to archiving it. Once the thing has merged, or he is throwing it away, or he has solved the problem, he should not be scared to settle it, and ideally he keeps only a small number of threads at any time.

He illustrates with a thread whose PR he reviewed and found fine. He says the PR was merged on GitHub in about 60 seconds at most, and the thread was marked merged. He had turned off auto-settling for that thread because it was long-running, but he says that if the flag were not off, the thread would have simply disappeared. His stated goal is that every thread should be either working or gone, so he optimizes for getting PRs merged, though he clarifies that he does not mean merging a pile of slop. He wants to reduce what is waiting on him and make it as easy as possible to merge with confidence.

Theo says the point of the full send skill is to lean into the idea of not taking up space in his brain unless it has to. When PRs merge, the thread is auto-archived. He also uses an optional working section in T3 Code, which he describes as a beta feature he likes and might make the default soon. He notes that Claude Code just made a similar change to its default. The section holds threads that are currently working, because they do not need his attention and should stay hidden until they are ready.

He points out a trade-off: he will not see what those threads are doing while they wait, such as a thread running ten sub-agents, and output he needs might be stuck under the section. He thinks that is ideal. If a thread asks a question through the question tool, it is pulled out and placed in his inbox.

He wants the ability to agree with the model, know roughly what it will do, and know it will verify and test its work. For a small fix he already understands, he does not want to return to the thread, be interrupted again to re-remember the context, or just click merge. His ideal is that once he and the model have gone back and forth and he trusts that it knows what he wants, the model does not bother him again unless it gets stuck.

Theo says some of the bullet points in the full send instructions exist because OpenAI models were doing things he did not like. The flow is to finish the change, prove it, file the PR, babysit the PR, merge, and report. The proof section matters most to him: he wants the model to find a way to verify its changes worked. He also mentions other skills to make sure it properly babysits and watches pull requests. He says a babysit PR skill had been leading OpenAI models not to use T3 Code's built-in watchers, so he added an instruction to use the watch pull request feature and to call unwatch first if it stops before merging.

He defines proof as evidence the model observed itself in the session, such as command outputs, reproductions and screenshots, using the most direct proof the change allows. The expected sequence is to reproduce the original failure, apply the fix, then watch the same reproduction pass. The model should run the checks the repo's CI runs and, when the behavior has no test and the repo has a test setup, add one focused test that fails without the fix. For UI and runtime behavior it should run the app and look at the change. He puts it bluntly: green mocked tests do not prove the user experience. A file-upload skill lets it attach screenshots or videos as proof.

The merge gate sets out what must be true before it merges: proof covers every change, required checks are green, all review bots have finished and their findings are fixed or dismissed in writing, no human reviewer still requests changes, and the branch is up to date with the default branch and GitHub reports it as mergeable.

Theo says the most important section concerns how the model gets hold of him. His aim is that when he is done with a thread he does not have to look at it again, and he trusts it to land the change without a final check. The model needs to know how to reach him when he is ignoring the thread. A question in a normal message goes unseen and makes the thread look done, so the model must use the harness's question tool so the thread shows it is waiting. He names the tools in Claude Code, Codex, and similar tools such as Antigravity.

Each question should include the PR link, what is blocking the model, and the options it recommends, listed first. He adds a gate saying to ask only when the model cannot continue alone, because after adding the section he noticed it was asking all the time. If the model lacks access to something it needs, it should take the safe path.

Theo says he can query his own usage from a database on his network, and in the limited window he was checking he had 32 times where he said full send. Of those, 27 merged without him having to look at them again. He says that is remarkable, and acknowledges it may seem insane not to look. He ties it to a principle he has described in other videos: build good verification systems so agents can check whether the thing works, and also build good safety nets so failures are caught before they reach a large share of users.

He says T3 Code has a nightly build that goes out every six hours and gives immediate feedback if something breaks, so a fix can land before the next stable release. He cites a lead developer on the Claude Code desktop app who publicly said the default might change to grouping by status to better fit this kind of workflow.

He argues that more developers are trying to build workflows where the agent can verify itself and ship confidently, while also being able to undo broken changes when they happen. He stresses that no matter how good the agents, verification systems or developers are, mistakes will happen, so they must be undoable with as little damage as possible. He says that across the 32 uses in recent days, 27 merged themselves and none of the threads he used this on caused problems. He adds that after enough agentic coding, a developer learns what the models can and cannot do and verify, and can judge what needs an extra look.

Theo says full stop is the final skill, and he admits it is pretty much entirely slop, joking that it should be called full slop. It exists because he liked the full send workflow so much that he missed it on the scarier changes he did not want to merge automatically. He wanted those changes to get everything else done, so that by the time they reached him they were ready to go.

Full stop is in effect Claude rebuilding his full send skill with one big change. The agent owns the work until the PR is ready for him to merge, keeps fixing, verifying and reviewing, and never merges it. He puts it this way: do everything in your power to verify the changes, talk to other agents and models for verification, put up the PR, babysit it, handle CI failures, handle review bots and his teammates' comments, and do not bother him unless something hard blocks it or it thinks the PR is ready to merge.

He says this has quickly become his most-used skill, to the point that when he started streaming that day, people sent him PRs they wanted him to look at, and he opened most of them and immediately wrote figure it out, full stop.

Theo gives an example. A viewer reported a bug in Twitter DMs and sent two PRs meant to fix it. He did not feel like going through them, so he pasted the message and wrote that a friend sent it, triage and takeover, full stop. He also has a separate takeover skill, which he calls simple, that he thinks of as a maintainer's tool for taking over existing work. It is used when the user asks to take over a PR branch, agent thread or request, taking responsibility for finishing the original goal while preserving the original contributor's credit.

He built it after seeing PRs that fixed things that mattered, but which he could not necessarily trust or did not want to push a pile of changes onto. The skill reads the PR and its description, judges whether the code is good enough to continue or should be scrapped and used as a reference, and then either makes a new PR with all the changes or contributes to the existing one, crediting the original authors. He says this matters to him because he does not want people to feel he is just closing their PRs and cloning their ideas, and that it is too much work to get contributors to make a PR perfect.

Theo describes a simple skill he calls modernize, for when a PR is out of date. It rebases on main, checks that nothing else has merged in the meantime that addresses the same issue so the team knows whether the change is still needed, and closes the PR if it is no longer necessary. He says it came from repeating the same instruction to models: make sure the PR is up to date, and close it if it no longer makes sense because similar things merged.

He lays out how the skills grew. He began with modernize because he kept doing that flow. Then he kept telling threads to take over PRs and branches and made takeover a skill. He wanted more use of sub-agents to review, which he had done by hand, so he made sole loop. He found the code quality better than expected, so he added full send to carry the work to the end. He missed that flow on riskier changes, so he made full stop to get as much as possible done without being bothered.

He then explains how he updates the skills across the fleet. He says he thinks a script in the repo runs when he does it, but he does not care, because he would rather say what he wants and trust the models to do it. He also addresses viewers who asked why he does not disable model invocation, which is an option in the skill standard that stops the model from pulling in a skill itself. He says that option would stop him from triggering several skills at once in some cases.

Theo says he almost never invokes skills manually, except the Matt Pocock grilling skill because that is how it is provided. He writes descriptions that describe the trigger phrase, so he can type something like soul loop takeover, full stop, or speak into a speech-to-text button saying full stop takeover soul loop, and the right skills are picked up without special syntax.

He gives a real case from the day he started his stream. Someone linked an issue they had fixed with a PR that opened Explorer in Windows. Theo took the PR, pasted it in, said take over and get this landed, then full send. He says two skills were invoked, the fix was merged, the old PR was closed because it was no longer needed, and the merge credited the original author. The combination let him take a PR he had not looked at, make a new PR based on it, credit the user, verify the fix, and merge, without ever looking at it. He says it also tested the fix in a Windows PowerShell VM. His skill says to make sure the change is working and safe before merging and to call him if not, so he is confident he would not need to see the thread again.

He then notes a technical problem he learned from a viewer named Alex: when a skill is invoked manually in Claude Code, the prompt is injected as an argument to the skill, so the whole prompt ends up in context twice. He calls that not ideal and says not to invoke manually.

Theo says the way he thinks about skills shows why he is enjoying them, and that many viewers have asked him to put all of this in a repo somewhere. He says he is leaning toward doing that, and he announces a new project he says is going with T-Stack. He says he will not have it ready soon, but viewers should watch for a T-Stack video in the future.

He also talks about a course he is making, which he says is his first. He says it is not likely to be worth it if you lack a full-time software job and are not paid real money, but he suggests that if an educational budget or an employer can cover it, it could be useful. He says he has spent months on the first chapter with other creators and that it will show how to use AI to ship at real companies rather than being a standard build-an-app course. He says buying it should be because your job covers it and you want to level up, not to get a job.

Theo closes by saying he hopes viewers take away a lesson rather than copy his markdown files because he is super smart. The lesson is to see how he finds solutions to problems he has, and to note that he is building a more abstracted workflow in which he is involved at a different layer than before. He says, in a way, he is becoming a manager of himself.

He advises that to get the most from agents, you should analyze your own flow, work out what you do and do not trust agents with, and start encoding that in things like skills so you can ship more effectively. He signs off by mentioning the coming T-Stack and asking viewers to subscribe.