📄 Three markdown files, and the disclosure 0:00
He opens by acknowledging the absurdity: he built a channel on frameworks and now he is doing thirty minutes on three markdown files. The defence is the usage data — nearly half the threads he opens in T3 Code use one of these three skills, and he suspects almost every PR that gets merged uses at least one.
The skills are Sol Loop, Full Send and Full Stop, with two companions (Takeover, Modernize) that arrived as supporting cast.
🚢 The fleet repo: one place for every machine 2:24
Before the skills themselves, the management layer — and it is the part most people skip. He keeps a single repository called fleet that holds the state of all his machines: which skills live where, which MCP servers are configured, auth setup. Folder structure by scope:
| Scope | Contents |
|---|---|
| Claude-only | Skills that only make sense in that harness |
| Per-machine ("command center") | Skills tied to one box |
| Global | Skills every machine should have |
| PR workflow | file-PR, babysit-PR, leaving review comments |
He notes he is about to delete a chunk of them — the pile of skills you accumulate is larger than the set you actually use. His own survivors, beyond the three headline skills, are the PR plumbing: opening PRs, babysitting them, and leaving comments (with a small skill that makes an agent disclose which model it is and that it comments on his behalf).
🎯 Descriptions are triggers, not documentation 4:22
The single most useful technical point in the video: a skill's description field is not a summary of what the skill does — it is the model's cue for when to load it. His are therefore deliberately narrow:
That inverts the usual instinct to write a rich description so the model "understands" the skill. For high-autonomy skills — the kind that end with a merged PR — accidental invocation is the failure mode, so a trigger phrase is the safety mechanism.
🔁 Sol Loop: a review loop with a budget 4:50
The premise: your agent owns the code, GPT-6.1 Sol reviews it, and you iterate until they agree — bounded so it cannot run forever.
| Rule | What it says | Why it matters |
|---|---|---|
| Goal | The smallest change that meets the intent; reviews make it correct, not bigger | Stops the loop from inflating the PR |
| Budget | Three rounds total. Round one full; later rounds check only changed code and open findings | Later rounds cost little and cannot reopen settled ground |
| Escalation | Extend to five rounds only for security, permissions, data loss or similar risk | Risk buys more review; taste does not |
| Early stop | If a round returns only nits, stop — decline nits, comments and docs | The most common way loops become infinite |
| No nesting | One reviewer at a time; Sol must not spawn its own sub-reviewers | Nested reviewers multiply cost and contradictions |
| Pushback | Explicitly allowed to disagree with the reviewer | Prevents an obedient agent from chasing every comment |
His stated payoff: PRs reviewed this way have fewer issues, get through human and bot review faster, and — the thing he actually cares about — less slop reaches his team. Opening the PR takes longer; closing it takes less.
⚖️ The model split: build with Opus, review with Sol 6:18
His division of labour is unusually specific, and it is about temperament rather than benchmarks:
| Model | Role | In his words |
|---|---|---|
| Claude Opus 5.5 | Builder, collaborator | "A much better collaborator, overall smarter, writes way better code, more pleasant to work with" |
| GPT-6.1 Sol | Reviewer | "More thorough… it really does feel like the Rottweiler. It grabs onto the problem and doesn't let go" |
The economics are worth noting too: he is on a Codex subscription he was not otherwise using much, so routing reviews through Sol uses capacity he had already paid for while his day-to-day building runs on Opus.
🔌 Two ways to get a foreign model into your harness 7:58
Sol is not available inside Claude Code natively, so he describes both routes he has used:
| Route | How it works | Caveat |
|---|---|---|
| CLI proxy | All provider auth in one place; he pipes every request/response into ClickHouse to query his own usage, with a dashboard for rate limits and traffic by model | Anthropic expects the Claude Code system prompt when you spend a Claude subscription — "they're really upset if the system prompt isn't the Claude Code system prompt". OpenAI, he says, does not police where its tokens are used. |
| T3 Code Orchestrator V2 (nightly) | Natively lets a thread call other harnesses and models, each in its own sub-thread, rather than stuffing a foreign model inside Claude Code | Nightly only at recording; stable release pending |
🧠 Multi-model review and the per-model rankings 10:00
In Orchestrator V2 he does not stop at two models. In the demo, a Claude Code thread delegates review to Muse, GPT-6.1 Sol and Gemini 4 Argon, each spinning up in its own native harness with its own sub-thread, then reports back to the main thread. His justification is the ensemble argument:
Different labs train differently, so models behave differently — like asking three people with different experience to review a PR, the chance that one finds something unique goes up. His informal ranking after using them this way:
| Model family | What he finds it good at |
|---|---|
| OpenAI | Most thorough; finds things others miss |
| Anthropic | Finds "really weird, potentially dangerous" issues |
| Muse (Meta), Gemini | Occasional hits; he says Gemini "hallucinates more than it finds" |
He offers a starting recipe for anyone who finds three reviewers excessive: delegate to N subagents, compare the answers, refine your dispatching, repeat. The dispatching prompt is the thing you are iterating on, not the models.
🚀 Full Send: the autonomy contract 14:24
The conceptual frame comes first: in T3 Code the sidebar is an inbox. Threads should be either working or gone; merged or abandoned work gets settled, and the goal is few threads waiting on him. Everything about Full Send follows from that: he wants to be interrupted once, at the start, and then not again.
The skill's structure, section by section:
| Section | Content |
|---|---|
| Trigger and scope | Only if explicitly requested; "if the user did not request this in some clear way, do not assume full autonomy" |
| Explicit permission | States that he grants permission to merge when gates pass, and to force-push the PR's own branch with --force-with-lease after a rebase — because OpenAI models "get antsy about merging" without it in context |
| The flow | Finish the change → prove it → file the PR → babysit the PR → merge → report |
| Proof | What evidence means (next section) |
| Merge gate | The checklist that must hold before merging |
| Asking Theo | How to reach him when he is deliberately not watching |
🧪 What counts as proof 17:10
His proof section is the part most worth lifting into any workflow, because it defines evidence rather than asserting quality:
- Evidence you observed yourself in this session — command output, reproduction, screenshots. Not a claim, not a plan.
- Use the most direct proof the change allows: reproduce the original failure, apply the fix, then watch the same reproduction pass.
- Run the checks the repo's CI runs — not a private subset.
- Add one focused test that fails without the fix, when the behaviour has none and the repo has a test setup.
- Enforce UI and runtime behaviour: run the app and look at the change — "green mocked tests don't prove the user experience".
- Upload the artefacts via his file-upload skill, so the proof is attached to the PR.
🚧 The merge gate 17:51
Before the agent may merge, all of these must hold:
| Condition |
|---|
| The proof covers every change in the PR |
| All required checks are green |
| Every review bot has finished, and its findings are fixed or dismissed with a written review |
| No human review is still requesting changes |
| The branch is up to date with the default branch, and GitHub reports it mergeable |
🛑 Full Stop: the same, minus the merge 21:03
His own description of this one is refreshingly unsentimental — "this skill is pretty much entirely slop", built by copying Full Send and deleting the merge.
The motivation is a good product insight: he liked the Full Send workflow so much that he missed it on the scary changes. He did not want those merging, but he wanted everything else — fix, verify, review, babysit CI, handle bot comments, handle teammates' comments — so that by the time it asks for attention, it is ready to go.
Result: Full Stop became his most-used skill. He now routinely opens a PR someone sent him and replies "figure it out, full stop", and he triaged a bug report from a DM by pasting it with "triage and takeover, full stop".
🤝 Takeover and Modernize: maintainer skills 22:25
Two supporting skills show how far this generalises to maintenance work:
| Skill | What it does | Design detail worth noting |
|---|---|---|
| Takeover | Takes over an existing PR, branch or agent thread: review it, read why it exists, decide whether the code is a good starting point or should be treated as reference only, then finish the goal — contributing to the original PR or opening a new one | Explicitly preserves the original contributor's credit. His reason: he does not want people feeling their PRs were closed and their ideas cloned |
| Modernize | Deals with a stale PR: rebase on main, check whether something else has since addressed the same thing, close it if it is no longer needed | Prevents duplicate work from quietly accumulating |
The credit-preservation rule is the one to steal. Agent-mediated maintenance scales only if contributors still get acknowledged for the idea; otherwise you optimise throughput and destroy the incentive that produced the contribution.
🕸 How the skill set grew 24:24
He traces the lineage honestly, and it is a template for how to build your own:
- Modernize — he was saying the same thing repeatedly ("make sure the PR is up to date, close it if something similar merged"), so it became a skill.
- Takeover — he kept telling threads to take over other people's branches and kept hitting the same problems.
- Sol Loop — he was manually asking a second model to review, so the procedure got encoded.
- Full Send — the review output was better than expected, so he let it run to the merge.
- Full Stop — he missed the flow on risky changes, so he made a variant that stops before the merge.
That closing frame is the actual thesis: the skills are not the product, the habit of noticing a repeated behaviour and encoding your trust boundary into it is.
⌨️ Triggers versus slash commands 26:40
He argues against the common advice to lock skills behind manual invocation (disable-model-invocation in the skill standard), for two practical reasons:
- Composition breaks. He routinely invokes several skills in one breath — "takeover and get this landed, full send" — and some harnesses, Claude Code included, will not let you manually invoke multiple skills at once.
- Manual invocation duplicates the prompt. In Claude Code, invoking a skill injects your prompt as an argument to the skill, so the whole prompt lands in context twice — "not ideal. Don't manually invoke, it sucks."
His substitute is trigger phrasing inside the description, so a spoken sentence — including via speech-to-text — is enough to fire the right combination. The one skill he does keep manual is a third-party one (Matt Pocock's "grilling" skill) because that is how it is distributed.
disable-model-invocation frontmatter field, and it documents stacking — but stacking is a prompting affordance, not the same as manually firing several slash commands in one message. If you rely on composition, test it in your harness rather than assuming.
📊 The numbers, and the safety net behind them 29:17
The claim that makes this video notable: in a window he queried from his own logs, he said "full send" 32 times, and 27 of those PRs merged without him looking at them again. Five did not — and he says none of the 27 caused problems.
| Element | Detail |
|---|---|
| Sample | 32 invocations "in the last couple of days" — a small, self-selected window |
| Outcome | 27 merged unattended; he knows which threads they were |
| Safety net | T3 Code ships a nightly every six hours, so breakage surfaces before a stable release |
| Prerequisite | Enough prior agentic work to know what models can verify and what needs a look |
✅ Claims checked
| Claim | Verdict | Evidence |
|---|---|---|
| Three skills — Sol Loop, Full Send, Full Stop — drive about half his threads | Self-reported | His own usage; plausible given the workflow he describes |
| The skills are published and MIT-licensed | Verified | t3dotgg/tstack — MIT, "the agent skills I use every day", works with Claude Code and Codex |
| T3 Code is his own app and picks up new features first | Verified | pingdotgg/t3code — MIT, ~37k stars, actively pushed |
| Skill descriptions function as invocation cues rather than documentation | Verified | Claude Code skills docs: the description determines when the skill loads |
disable-model-invocation exists in the skill standard | Verified | Documented frontmatter field in Claude Code's skills reference |
| Manually invoking a skill passes your prompt as an argument, duplicating it in context | Consistent with docs | Skills accept arguments; the injection behaviour explains his "twice in context" complaint |
| Claude Code will not let you manually invoke several skills at once | His experience | Docs describe stacking several skills in one message, which is not the same as firing multiple slash commands; verify in your harness |
| Opus 5.5 is a better collaborator; GPT-6.1 Sol is more thorough for review | Opinion, well-founded | Both models exist as described; the split is his assessment after sustained use |
| Orchestrator V2 lets a thread delegate to other harnesses, each in its own sub-thread | His product, nightly | Demonstrated on screen; stable release pending at recording |
| Gemini "hallucinates more than it finds" in review | Opinion | No measurement; consistent with other practitioners' anecdotes, not evidence |
| Using a Claude subscription outside Claude Code's system prompt is against expectations | Consistent with provider terms | He states it plainly; the OpenAI half ("doesn't care") is his reading, not a licence |
| 32 full sends, 27 merged unattended, none causing problems | Self-reported | Queried from his own logging; small window on his own project |
| A six-hourly nightly provides the safety net | Verified as a practice | T3 Code nightly cadence; it is the release process, not the agent, that makes unattended merging survivable |
| Takeover preserves the original contributor's credit | Stated in the skill | He describes both the rule and his reason for it |
| He deleted/plans to delete many of his other skills | Self-reported | Consistent with the "pile larger than the set you use" observation |
Transcript notes. Auto-captions render the skill name as "sole loop"/"soul loop" — the reviewer it wraps is GPT-6.1 Sol, so "Sol Loop" is the consistent reading. Also: "false end"/"full sent" (Full Send), "false stop" (Full Stop), "cloud code" (Claude Code), "T3 Code"/"T3Code" (T3 Code), "GPT-61 Soul" (GPT-6.1 Sol), "Hermosi"? none — but "Muse, wonderful" is likely Muse Wonder, and "antigravity" refers to Google's Antigravity harness.
🔑 Key takeaways
- Treat the sidebar as an inbox: every thread should be working or gone. Optimising for merge with confidence is what empties it.
- Write skill descriptions as triggers, not summaries — the field decides when the skill loads, and for high-autonomy skills accidental loading is the risk.
- Give review loops a budget. Three rounds, later rounds scoped to changed code and open findings, extend to five only for security or data-loss risk, stop early on nits.
- Never let the reviewer nest. One reviewer at a time; sub-reviewers multiply cost and contradictory advice.
- Build with one model, review with another — Opus 5.5 to write, GPT-6.1 Sol because it "doesn't let go". The split is temperamental, not benchmark-driven.
- Make the loop's outcome visible in the PR body. Requiring "reviewed with Sol loop, N rounds, verdict" stops the authoring agent from quietly skipping the review.
- Autonomy is a contract with explicit permissions. Stating that merging and force-with-lease pushing are authorised is what lets a cautious model actually finish.
- Define proof, don't request quality: observe it yourself, reproduce the failure and watch the fix pass, run the repo's CI, run the app — "green mocked tests don't prove the user experience".
- The merge gate needs written dismissals. Otherwise an agent can neutralise a review bot by ignoring it, and the gate is decoration.
- Withhold one irreversible step rather than all autonomy. Full Stop — everything except the merge — became his most-used skill.
- Give the agent a way to interrupt you properly: use the harness's question tool so the thread shows "waiting", include the PR link and options, and gate it with "ask only when you cannot continue alone".
- Preserve contributor credit in takeover work, or you optimise throughput while destroying the incentive that produced the contribution.
- Encode repeated behaviour, not aspirational process. Every skill in the chain exists because he caught himself saying the same thing again.
- Pair unattended merging with a fast feedback loop — 27 unseen merges are defensible only because a nightly ships every six hours and he knows the codebase.
🔗 Sources
- The source video — Theo - t3.gg, "These 3 skills changed my life", 30:37, 26 October 2026
- t3dotgg/tstack — the published skills (MIT): "The agent skills I use every day. Works with Claude Code and Codex."
- pingdotgg/t3code — T3 Code, the harness the workflow is built around (MIT)
- Claude Code: skills documentation — descriptions as load criteria, arguments,
disable-model-invocation, stacking - Claude Code: subagents — the delegation mechanics behind multi-model review