Three Skills Let AI Agents Self-Submit and Merge PRs: Soul Loop, Full Send, and Full Stop in Practice

AI coding assistants can already write code, but the real bottleneck often isn't writing code itself—it's how to let an Agent autonomously complete the loop from modification to merge. Bilibili UP host t3.gg shared three Skills he uses frequently in his daily work—Soul Loop, Full Send, and Full Stop. They aren't carefully designed theoretical frameworks, but workflows solidified from recurring repetitive labor. These three Markdown files are changing the way he writes code and enabling Agents to submit PRs and complete merges on their own.

Skills That Grew Out of Repetitive Labor

In the video, t3.gg admitted that these Skills weren't conceived as brilliant ideas first and then forced into his workflow. On the contrary—he found himself doing certain things over and over, so he turned those behaviors into skills. While working on the T3 code project, about half of the PRs ended up using one of these three skills, and nearly all PRs that ultimately got merged used at least one of them.

He keeps all Skills in a repository called Fli, organized into folders by type: some are only used in Claude Code, some only on specific machines, and some he wants synced to almost all machines. This centralized management makes it feasible to keep authentication, MCP configuration, and skills in sync across multiple machines.

One easily overlooked detail is a Skill's description field. t3.gg emphasized that the description doesn't describe what the skill is, but serves as a trigger hint for the model—telling it when to use the skill. For example, Soul Loop's description says "use when the user says Soul Loop," and it won't be pulled in unless explicitly named or mentioned by another skill.

Skill Mechanisms in Claude Code and Codex

Skills referred to in this article are workflow instruction sets defined through Markdown files in AI coding assistant environments such as Claude Code and OpenAI Codex, which can be recognized and invoked by the model. Each Skill contains a name, a description (trigger hint), and specific step constraints. When user input matches the description, the model automatically loads the skill and follows its rules to execute the task. This mechanism allows developers to solidify repetitive operational processes (such as review, merge, and takeover) into reusable modules, thereby expanding the boundaries of the Agent's autonomous capabilities. Skill files are usually stored in specific directories (such as .claude/skills or the project root) and can be synced to multiple machines through version control.

Soul Loop: Letting GPT-5.1 Codex Do Code Review

The core logic of Soul Loop is simple: you write the code, search for review, fix what's right, push back on what's wrong; stop when you two agree or the budget runs out. The goal is to get the minimal change that satisfies the intent—review is meant to make it correct, not make it bigger.

t3.gg added explicit budget control in the skill: three rounds in total, with the first round covering everything and subsequent rounds only looking at changed code and unresolved issues; only extend to five rounds when there are potential risks involving security, permissions, data loss, etc. If a round has only minor issues left, stop early; unimportant content like pure commentary and documentation gets rejected outright. It also specifies that there can only be one reviewer at a time—Soul shouldn't spawn sub-agents itself, nor find reviewers itself, otherwise nesting would balloon rapidly.

"Watch out for scope creep, don't be afraid to push back" is something t3.gg considers a particularly important addition. Multiple Agents with differing opinions arguing with each other easily leads to scope explosion, with PRs far larger than needed—this small constraint blocks a lot of these cases.

In terms of model pairing, he found Opus 5.5 to be a better collaborator—generally smarter and much better at writing code; but GPT-5.1 Codex is more thorough, like a Rottweiler that sinks its teeth into a problem and won't let go, so he especially likes using it for review. This workflow saves a large number of PRs from falling into infinite review loops after landing on GitHub—by the time AI code review tools like Macroscope, Graphite, and CodeRabbit see the code, it's usually already solid.

Full Send: From Current State All the Way to PR Merge

Full Send's trigger condition is very clear: it triggers when the user requests Full Send, indicating the user isn't watching this thread and wants the Agent to autonomously complete the work from start to finish. If the user hasn't explicitly requested it, the Agent must not assume full autonomy on its own.

t3.gg wrote the authorization content explicitly in the skill, because certain models (especially OpenAI's models) are particularly nervous about merging unless the context explicitly states the user has given clear permission. He added a dedicated paragraph: authorizing you to merge this PR after the merge gate passes, and to force-push your own branch with Force with Lease after rebasing.

The merge gate is the most core part of this skill. It requires proof covering every change, all required checks green, all review bots finished with issues either fixed or rejected with reasons, no human reviewer still requesting changes, the branch in sync with the default branch, and GitHub reporting it can be merged. The proof section requires the model to find some way to verify the changes actually work: first reproduce the original failure, apply the fix, then watch the same reproduction process pass; run the checks the repository CI would run; if the behavior originally had no tests and the repository has a test environment, add a targeted test that must fail without the fix; for UI and runtime behavior, run the app and look at it yourself.

Another key design is the question gate. The model learns that when the user is ignoring this thread, it must use the Harness's question tool rather than asking in a normal message—because normal messages simply aren't seen, and the thread still looks finished. In Claude Code, use Ask User Question; in Codex, use Request User Input. The question should include the PR link, what's blocking it, and recommended options. t3.gg set up the gate with "don't ask unless otherwise," because without this passage the model asks about everything.

He used Full Send 32 times within a limited time window, and 27 of those merged on their own without him looking again. That sounds a bit crazy, but the logic behind it is: you need to build a good verification system so the Agent can confirm things work itself, and you need good safety nets so that if something really breaks, it can be caught and fixed before affecting most users. T3 code ships a Nightly every 6 hours, so feedback comes immediately once something breaks.

Merge Gate and Proof Mechanism

The Merge Gate is the core quality checkpoint in the Full Send skill. It requires the Agent to satisfy a series of verifiable conditions before merging a PR: proof covering every change, all required checks green, all review bot issues fixed or rejected, no human reviewer requesting changes, the branch in sync with the default branch, and GitHub reporting it can be merged. The proof mechanism forces the Agent to show evidence, such as reproducing the original failure, applying the fix, and re-running the reproduction process to confirm it passes; running repository CI checks; writing targeted tests for fixes that had no tests; or running the app for UI and runtime behavior verification. This design transforms "trust" into a verifiable chain of evidence, ensuring the Agent's autonomous operations are auditable and reliable.

Full Stop: Work Until It Can Merge, But Never Merge

Full Stop is a remake of Full Send with one big change: it's responsible all the way until the PR is ready for the user to merge—keeps fixing, keeps verifying, keeps reviewing, but never merges. t3.gg jokingly calls this skill basically a pile of garbage that should probably be called Full Slop, but the reason it exists is that he loves the Full Send process so much and misses it when dealing with scarier changes—he doesn't want them merged, but wants everything else done, so when it comes time to bother him, the thing is already shippable.

This skill quickly became a high-frequency skill. t3.gg said that when people send PRs for him to look at during streams, almost every one he opens gets the first response "handle it yourself, Full Stop." Someone reported a bug on Twitter DMs with two fix PRs attached, and he couldn't be bothered to read from scratch—he just copy-pasted the message saying "take over, land it, Full Stop."

The companion Takeover skill handles another type of scenario: taking over existing work. It's used when the user asks to take over a PR, branch, or Agent thread, and is responsible for finishing the original goal while preserving the original contributor's attribution. t3.gg cares a lot about this—he doesn't want people to think he just closes their PR and copies the idea, but wants the person who submitted the original PR to get the credit they deserve, just with a trusted person on the team pushing it to the finish line.

Multi-Agent Orchestration and Subscription Reuse

t3.gg also demonstrated T3 Code Nightly's Orchestrator VR feature: letting Agents and threads in T3 Code call other Agents, other Harnesses, other threads. He has Claude Code run Opus while pulling in GPT-5.1 Codex and Gemini models in their respective native Harnesses for parallel review. Different models are trained differently—like finding three people with different backgrounds to review the same PR, the probability of discovering unique issues is higher. He believes OpenAI's models are the most thorough and can find more than others; Gemini sometimes digs up weird pitfalls, but fabricates more than it actually finds.

Regarding subscription reuse, he recommends building a CLI proxy to centralize all authentication in one place, so that all models accessible within it can be used in any tool. But be aware: when using Claude's models elsewhere, if the system prompt isn't the Claude Code one, Anthropic gets very unhappy; OpenAI doesn't care where tokens are spent. He himself uses the Codex subscription on Codex and the Claude subscription on Claude.

Native Harness and CLI Proxy

Harness refers to the native tool environment in which AI models run—for example, Claude Code for running Anthropic models and Codex for running OpenAI models. Different models perform best in their respective native Harnesses and support environment-specific features (such as question tools, file operations, etc.). CLI Proxy is an intermediate layer service that centralizes authentication information (such as API Keys and OAuth Tokens) from different services, enabling any tool to invoke authorized models through the proxy. This solves the problem of fragmented authentication across multiple tools, but note the terms of service: for example, using Claude models outside the Claude Code environment may violate Anthropic's usage policies, while OpenAI is relatively lenient about this. Developers should configure proxies reasonably to avoid account risks.

Workflow Thinking Is the Real Takeaway

t3.gg emphasized at the end that he hopes viewers learn not to copy his Markdown files, but to see how he finds solutions to the problems he encounters. He's building increasingly abstract workflows, and the layer he participates at is different from before—in a sense, he's become his own manager. To get the most out of Agents, you have to analyze your own processes, figure out which things you dare trust them with and which you don't, and then encode that into skills.

He even mentioned an upcoming new project called T-Stack, hinting that these skills might go into some repository in the future. For developers who want to try, the starting point doesn't have to be the complete three Skills—start with the sentence you repeatedly say to the model, turn it into a skill file with triggers and boundary constraints, and you've already taken the first step.

One-line Summary

Bilibili UP host t3.gg shares three AI programming Skills that let Agents autonomously complete the loop from modification to PR merge.

Paragraph Summary

t3.gg distilled Soul Loop, Full Send, and Full Stop from repetitive labor to solve bottlenecks AI coding assistants face in code review, autonomous merging, and PR takeover. Soul Loop uses a three-round review budget and scope constraints to prevent creep, and uses GPT-5.1 Codex for thorough review; Full Send designs a merge gate and proof mechanism to ensure the Agent merges autonomously after verification passes, with 27 out of 32 uses incident-free; Full Stop is the safe version, working until mergeable but never merging, paired with Takeover to preserve original contributor attribution. Additionally, multi-Agent orchestration and subscription reuse improve review diversity, and the core takeaway is workflow thinking rather than copying skill files.