Loop Engineering in Practice: I Built a 105-Line Skill That Runs the Full PR Pipeline

Everyone’s defining loop engineering. This is what it looks like when you actually ship one — THE /pr-loop skill.

There’s a moment every developer will relate to : you’ve finished the implementation, tests pass locally then you push, open the PR, and then… nothing moves for a while. Review takes time. Feedback comes in waves. You fix one thing and someone notices another. CI flakes. The branch drifts. AND the PR just sits….

Agentic coding tools have gotten genuinely impressive at the first part of this story: writing the implementation. But I kept running into a wall with everything afterwards. No tool I’d tried had a principled answer for the part that happens after the first commit.

The Problem with “Agentic Coding” until now

Most agentic coding tools treat the problem as: given a description, produce code. And they’ve gotten good at that part, like genuinely good.

BUT that’s maybe 30% of what shipping actually involves. The rest is process: reading project conventions, writing clean commits, catching conflicts before they become a mess, getting real review from someone who didn’t write the code, handling CI results intelligently, knowing when to merge and when to wait for a human.

That’s not a generation problem. It’s a discipline problem. And no 105-line skill file is going to solve discipline if it isn’t built around the right principles.

So before I wrote a single line, I have tried to get the principles right in what I have built : THE /pr-loop skill.

Principle One: Learn Before You Act

The first thing /pr-loop does before touching any file is read the project's contribution rules. CONTRIBUTING.md, CLAUDE.md, AGENTS.md, README, whatever exists, in that order. It's extracting the things that shouldn't be hardcoded: commit format, branch naming, test commands, merge policy, and whether autonomous merge is even permitted.

If none of it is documented (but should be !!), it asks you directly.

This isn’t just good behavior. It’s what separates a tool that adapts to your codebase from one that slowly rewrites it in its own image. Most agentic tools apply a default style to everything they touch. After a few months, your repo starts feeling like it was taken over by someone who’d never read the README.

/pr-loop deliberately inverts that. It reads first. It doesn't guess.

Principle Two: Don’t start what you can’t finish

After reading the rules, it does something that took me a while to decide on: it checks whether the issue is actually actionable before writing any code.

If the description is ambiguous, if there’s no clear acceptance criteria, if the entire spec is “fix the thing,” it stops and asks for clarification. It won’t implement based on a guess.

I went back and forth on this. It feels a little bureaucratic. But the alternative, an agent that confidently implements the wrong thing and then runs a full review cycle on it, is a much worse use of everyone’s time.

A 3-word issue title is not enough to act on. The pre-flight check is how you catch that before it costs you anything.

Principle Three: Context Separation Is NOT Optional

This is the design decision I’m most confident about.

The pipeline has three separate agent contexts: the author (writes the code), two reviewers (run in parallel, completely isolated from each other), and an optional merger. The agent that wrote the code never reviews it. Never merges it.

When I first started building this, I didn’t have the separation. One context did everything: write, review, merge. It was faster BUT it was also wrong.

An agent reviewing code it just wrote doesn’t behave like an independent reviewer. It shares the author’s assumptions. It overlooks the same edge cases. It rationalizes the same tradeoffs. This isn’t a hypothesis; I observed it consistently. The reviews were shallow in exactly the places the implementation had problems.

Once I split the contexts, review quality jumped immediately. The reviewers found things the author missed. They disagreed with each other sometimes. That friction was valuable.

The principle it’s modeled on is the same one good engineering teams apply to humans: the person who wrote the code doesn’t merge it. We enforce this for humans because we know self-review doesn’t work. It doesn’t work for AI either.

Principle Four: Reviews have to mean something

The two reviewers aren’t doing the same job.

One does structured analysis: security, correctness, performance, maintainability. It’s looking at the code through the lens of: what could go wrong here?

The other actually runs the gates. It executes the tests, runs the linter, probes whether the change does what the PR claims it does. It’s asking: does this actually work?

Different lenses catch different problems. The reviewer that only reads code won’t catch a test that passes for the wrong reason. The reviewer that only runs gates won’t catch the subtle auth logic bug that’s syntactically correct.

And here’s the part that matters most: every finding gets addressed. Including NITS (I prefer it this way, you could argue against it). If a reviewer flags a variable name, it gets renamed. It doesn’t get marked “low priority” and quietly forgotten (my view is in this new world these things should be fixed in the same run).

There’s a three-round cap on the review loop — IMPORTANT. If findings are still surfacing after three passes, the loop pauses and asks you. Because at that point, you’re probably not looking at a code problem. You’re looking at a judgment call, and those belong to a human.

Principle Five: CI failures need a real Policy

This is the one that required the most iteration to get right, because the naive approaches are both wrong in opposite directions.

Fail once, stop immediately: too aggressive. Real codebases have flaky tests. A tool that halts on every intermittent failure isn’t useful.

Retry until it passes: dangerous. This is how you get an agent that marks a broken build green by waiting out the test suite. It optimizes for moving forward, not for correctness.

The current behavior tries to thread the needle. Fail once, retry once. On the second failure, inspect the logs before assuming anything. Fix real failures. If the second failure looks environmental, an infra error, a network timeout, a test that’s clearly unrelated to the change, surface it to the user and stop. No silent retries. No pretending.

It’s not perfect, but it’s honest. And honest beats optimistic when CI is involved.

Principle Six: The default should be Conservative

Once both reviews are clean and CI is green, the default behavior is to stop. Not merge. Stop.

It reports: “PR open, CI green, both reviews clean. Awaiting your merge.”

You have to explicitly pass autonomous-merge in the arguments to go further. And even then, it's a separate fourth context, not the author, that re-verifies everything independently before squash-merging. If anything looks off, it refuses and reports why.

I made conservative the default because trust in agentic systems has to be earned incrementally. Seeing the tool work correctly on 20 PRs in a row is a reasonable gate before you let it merge. The opt-in design makes that natural. You can tighten the leash as you gain confidence, rather than starting with full autonomy and pulling back when something breaks.

What I still haven’t Figured Out

I want to be straight about the gaps, because they’re real.

Monorepo cross-package changes don’t work cleanly yet. If your PR touches two packages with independent CI pipelines, the current logic doesn’t know how to wait on both. It’s on the list.

Merge conflicts stop the pipeline. The skill surfaces them to you and pauses rather than trying to resolve them. This is the right call; auto-resolving non-trivial conflicts is how you introduce subtle bugs. But it does mean you occasionally have to step in.

There’s also no escalation path for review findings that require a product decision rather than a code change. Right now, if a reviewer surfaces something like “this behavior is inconsistent with how we handle X elsewhere,” the loop pauses and asks you. I want to eventually route those to a separate judgment context. But I haven’t built that yet.

What Surprised Me…

I expected the hardest part to be the automation itself. It wasn’t. Claude Code handles orchestration well, and once the structure was right the individual steps weren’t complicated to implement.

The hardest part was deciding what the tool should refuse to do.

Every time I made the tool more conservative, stop on ambiguous issues, stop on conflicts, require explicit opt-in for merge, cap review rounds at three, it felt like Iwas making it less capable. Like I was building in friction.

But the friction turned out to be the point. Each of those stops is a place where the tool is saying: I don’t have enough information to make a good decision here, and pretending otherwise would cost you more than pausing. That’s not a limitation. That’s the behavior you want from something operating in your codebase.

The best agentic tools aren’t the ones that do the most. They’re the ones that know exactly when to stop.

The Skill File

The whole thing is ~100 lines of markdown. No framework. No orchestration layer. No external dependencies beyond git and the gh CLI.

It lives in your Claude Code setup and runs whenever you call /pr-loop.

https://github.com/surpradhan/claude-code-skills

If you try it, i’d genuinely like to hear what breaks. The gaps I know about are listed above. The ones I don’t know about are more interesting to me, so if you give it a try, let me know please.

Thank you for being a part of the community

Before you go:

• Be sure to clap and follow the writer ️👏️️
• Follow us: LinkedIn | Medium | GitHub 🐙
• Join our Developers Global Community on Discord 🧑🏻‍💻