PR templates for assistant-heavy repos that catch real risks

Why style-first reviews fail

Formatters and linters already handle most cosmetic issues in seconds. Spacing, import order, quote style, and most naming noise do not need a human reviewer. When people spend review time on those comments anyway, they waste attention on work the repo can automate.

That waste gets worse in repos that rely heavily on assistants. AI-generated code often looks clean on the surface. It follows house style, uses tidy function names, and passes basic checks. A pull request can look polished and still break a pricing rule, skip a permission check, or delete data during a cleanup script.

That is why style-first review creates a false sense of safety. The code looks neat, so reviewers relax. The real problems slip through because nobody asks harder questions about what the code does, what it can access, and what happens after it runs.

A common example is a script for deployment or maintenance. The assistant produces readable shell commands and helpful comments. A reviewer spends five minutes asking for shorter variable names, but misses that the script runs with broad permissions, touches production data, or leaves temp files and feature flags behind.

For AI-generated pull requests, the risky parts are usually practical, not aesthetic:

• Does the change match the business rule, including odd cases the tests may miss?
• Does it run commands that can modify, expose, or delete more than intended?
• Does it leave cleanup work behind, such as debug code, extra access, test data, or dead config?

People still matter here. A formatter cannot tell whether a refund flow now skips fraud checks. A linter cannot tell whether a generated migration locks a table too long. An assistant can produce code that reads like a careful engineer wrote it even when the logic is off by one condition that matters to the business.

PR templates should push reviewers toward those risks. If the template mostly asks about style, teams end up reviewing the easiest thing to notice instead of the thing most likely to hurt them after merge.

What changes in assistant-heavy repos

In a typical repo, one commit often maps to one clear idea. In a repo with heavy assistant use, one prompt can touch ten files at once. A small request like "add a filter" might change API handlers, SQL, tests, docs, config, and a helper script in the same pass.

That wider spread changes how people review. Reviewers can no longer assume that every changed file has a good reason behind it, or that the author noticed every side effect. The assistant is fast, but it does not know which parts of your product are fragile, regulated, expensive, or easy to break.

Scope creep is another problem. Assistants often add things nobody asked for because they match a common pattern. You ask for a form update, and the pull request includes a new migration, a shell script, extra logging, and a cache tweak. Some of that is harmless. Some of it adds more access, more cost, or more cleanup work later.

Generated code also follows generic habits. It can build a neat validation layer and still miss a rule that matters to your product, like who can approve refunds, when a user may see internal data, or what must stay immutable after billing. The code can look tidy and still be wrong.

Then there are the leftovers. One quick edit leaves an unused env var. Another adds a debug command. A third keeps a test fixture nobody needs. None of these feels serious on its own, but after a month the repo gets harder to trust.

That is why review questions need to change. A useful template should ask whether the change touched files outside the request, whether it added scripts or permissions, whether it follows product rules instead of generic coding patterns, and whether the author removed debug code, temp files, and dead config before merge.

When the template asks sharper questions, reviewers spend less time on polish and more time catching the stuff that causes trouble later.

How to rewrite your PR template

Most teams already know where reviews fail. A pull request ships with a broken pricing rule, a script gets merged that can wipe local files, or someone leaves debug data and one-off prompts in the branch. Start there. Pull a handful of recent PRs that caused real pain and write down the failure, not the symptom. "Missed a business rule" is useful. "Review needed more attention" is not.

Then turn each failure into one direct question. Good questions force a clear answer. Bad questions invite a shrug. If your team keeps missing refund logic, ask "What business rule changed, and what case could break?" If shell commands keep slipping through, ask "Does this PR add commands that delete, write, or call external services?" That is far better than a vague line like "Any risks?"

Most teams can cover the real danger with three groups of questions:

• Logic: What rule changed, who does it affect, and how did the author check it?
• Safety: Does this code run commands, touch secrets, widen access, or make network calls?
• Cleanup: Did the author remove debug logs, temp scripts, fake data, extra files, and leftover comments before merge?

Keep the template short. Six to eight questions is enough for most teams. Once it gets longer, people stop reading and start pasting empty answers. A short template with sharp questions beats a long one full of generic prompts about style and "best practices."

It also helps to make authors answer in plain language. Ask for one sentence, not a report. "Changed discount logic for annual plans; tested upgrade and cancel flows" gives reviewers something concrete to inspect.

Before you lock the template in, test the draft on a few recent pull requests. Use one clean PR, one messy PR, and one AI-assisted PR if you have one. If a question never changes the review, cut it. If reviewers still miss the same problem, rewrite the question until it points at the risk you actually care about.

Ask about business rules

Most bad merges in assistant-heavy repos come from one simple gap: the code changes behavior, but nobody writes down the rule it is meant to follow. Reviewers then check naming, formatting, and test output while the real risk sits in plain sight.

A better PR question is simple: what user rule changed here? If the author cannot answer that in one or two clear sentences, the review is already weak. "Fix checkout issue" is not a rule. "Apply the discount only to the first paid month" is a rule. "Managers can approve refunds up to $200, finance must approve anything above that" is a rule too.

This belongs near the top of the template because generated code often looks tidy even when the logic is wrong. An assistant can fill gaps with a reasonable guess, and that is exactly the problem. Reasonable is not the same as approved.

Reviewers should check a few specific things:

• Which written rule does this code implement or change?
• What edge case could break billing, access, or approvals?
• Does the code match the stated rule, not just the ticket title?
• Did the assistant assume a rule the product team never defined?
• Where would a wrong decision hurt users first?

That last question matters more than teams expect. If a bad guess affects an internal admin screen, the damage may stay small. If it affects invoice totals, account access, or approval chains, users feel it fast. Reviewers should name that risk in the PR instead of leaving it implied.

A small example makes this obvious. Suppose the PR says it "fixes subscription renewal." The code now retries failed payments three times and suspends access after the third failure. That may be fine. It may also break a grace-period policy that sales promised to customers. The code can pass tests and still be wrong.

Once the rule is written down, review gets sharper. People stop arguing about style and start checking behavior.

Ask about unsafe commands and access

Assistant-generated code often slips operational steps into a pull request with very little warning. That is why templates should ask direct questions about commands, data access, and cleanup, not just whether tests pass.

A reviewer should know if the change adds a shell script, a database migration, a delete step, or a one-off command hidden in the notes. These are the parts that can do real damage. A neat diff can still wipe files, lock a table, or expose a secret.

A few prompts in the template help people slow down and look for risk:

• Does this PR add any command that writes, deletes, migrates, or resets data?
• Can someone run every command safely in a local setup?
• Does any script touch production data, secrets, env files, or system paths?
• Did the PR add broader access rights just to make the change work?
• Should the operational part ship in a separate PR?

Broad permissions deserve extra suspicion. Assistant tools often choose the easiest path, and the easiest path is sometimes "give this service full access" or "run as admin." That may get the code working fast, but it leaves a mess behind. Reviewers should ask for the smallest permission set that still does the job.

Local safety matters too. If a reviewer cannot run the change without real credentials or live data, the team has a blind spot. A safer setup might use sample records, a seeded local database, and fake secrets. If the author cannot explain how to test it safely, the change is not ready.

A simple example: a PR adds a cleanup script that deletes old uploads and a migration that backfills user records. Both might be fine. Still, they deserve separate review from the UI change in the same branch. When risky operational changes sit beside normal app code, reviewers miss them.

This part of the template should make the author name the risk in plain words. If the answer feels vague, that alone tells the reviewer where to look harder.

Ask about cleanup before merge

Assistant-generated code often solves the task and leaves a trail behind it. Reviewers should look for that trail before merge. The messy parts are usually small, but they create noise, confuse the next person, and sometimes open real risk.

Start with the obvious leftovers. Debug logs, throwaway scripts, temporary files, and test routes often stay in the branch because the assistant used them while trying different fixes. If a change adds a test endpoint, extra console output, or a one-off migration file, ask whether the team still needs it.

Unused helpers are another common clue. An assistant may create two or three helper functions, keep one, and forget to remove the rest. Those extra pieces make the diff look larger than it is, and later someone wastes time trying to understand code that does nothing.

Comments deserve the same check. If the branch removes old logic, the old explanation should go too. A stale comment is worse than no comment because it tells a false story about what the code does now.

Mismatch is where cleanup before merge matters most. A change can pass locally while leaving tests, docs, config, or environment notes out of sync. That problem shows up later, usually when another developer pulls the branch or when deployment runs with old settings. In assistant-heavy repos, this happens a lot because the code changes fast and support files lag behind.

Duplicate code slips in easily too. An assistant may copy logic into a new file instead of reusing what already exists. The feature works, but now the same rule lives in two places. That is a maintenance problem waiting for the next bug fix.

A good prompt can keep cleanup simple:

• What did this branch add for debugging or testing that should be removed now?
• Did the assistant leave dead helpers, stale comments, or duplicate logic?
• Do tests, docs, and config still match the final version of the change?

That habit saves more trouble than another round of style edits. Clean diffs are easier to trust, easier to deploy, and much easier to change next week.

A simple review example

A teammate opens a pull request that changes refund logic and adds a small admin script for support staff. The diff looks clean. Names make sense, tests pass, and the assistant wrote tidy code with the usual comments and neat formatting.

That is exactly the kind of pull request that can slip through a normal review too fast. If a reviewer spends most of the time checking style, they might miss the part that can hurt customers: who gets a refund, when they get it, and what the admin script can touch.

A better template forces the author to answer the right questions before anyone clicks approve. In this case, the template might ask which refund cases changed, what happens on partial refunds, expired subscriptions, or duplicate charges, whether the admin script can update or delete records outside the intended account, and what temporary access, debug code, or one-off helpers still need removal.

Those answers change the review. Instead of saying "looks good," the author explains that the new refund rule should allow a refund for duplicate charges within 30 days, but not for accounts with an active dispute. They also note that the script can remove old refund flags in bulk.

Now the reviewer has something real to inspect. They check edge cases first. They notice the code refunds duplicate charges correctly, but it also refunds a failed renewal that the business rule should exclude. Then they read the admin script and see a filter bug: if account_id is empty, the delete command can hit far more records than intended.

One more template question catches a quieter problem. The author admits they left a temporary support bypass in place so they could test the admin flow faster. The code style still looks fine, but that debug access should never reach production.

A review like this does more than clean up code. It catches wrong refunds, risky commands, and leftover access before merge. That is a far better use of review time than arguing over commas or line breaks.

Common mistakes when teams change templates

The first failure is simple: teams turn the PR template into a form nobody wants to fill out. It should slow people down just enough to check risk, not bury them under twenty boxes and boilerplate. If authors paste "yes" all the way down, the template is dead weight.

Vague questions cause the next problem. "Does this look fine?" or "Anything unusual?" sounds harmless, but it gives reviewers no clear target. People skim, approve, and move on. Good prompts name the risk: broken business rules, unsafe shell commands, hidden access changes, or leftover debug code.

A lot of teams also keep their old style-review habits. The template still asks about naming, formatting, and tiny wording issues while the real danger sits in generated migrations, scripts, or broad refactors the assistant wrote in seconds. Style can wait for automation. Review time should go to changes that can hurt users, data, or production.

You can usually spot a weak template quickly:

• It takes longer to read than the pull request summary.
• Reviewers can answer every question with "looks good."
• It spends more space on style than behavior.
• Nobody updates it after incidents or process changes.

That last point matters more than teams think. Processes change, tools change, and the assistant changes too. If your team now blocks direct production access, scans for risky commands, or requires rollback notes, the template should reflect that. Old questions hang around for years because nobody owns them.

One mistake shows up in almost every assistant-heavy repo: authors do not say which parts the assistant produced on its own. Reviewers then treat all changes the same, even though a hand-edited bug fix and a large assistant-generated rewrite deserve different scrutiny. A short note like "assistant drafted tests and migration" gives the reviewer context right away.

The fix is not a bigger template. It is a sharper one. Keep only the questions that catch real mistakes, remove stale checks every few weeks, and require authors to flag assistant-written sections before review starts.

Quick checks and next steps

A good template should make risk easy to see fast. If a reviewer needs ten minutes to figure out what changed, the template is still too vague.

Use a short pass-fail check before you add anything else:

• Can a reviewer spot the business rule change in under one minute?
• Can someone find risky commands, migrations, or scripts without opening every file?
• Can the author say what cleanup they finished before asking for review?
• Can the reviewer tell what still needs a human decision?

That second question matters more than teams think. In repos with heavy assistant use, a small PR can hide a command that drops test data, resets a database, widens access, disables a guardrail, or leaves a debug script behind. Reviewers should not have to hunt for that by hand. The template should ask for it in plain words.

Cleanup deserves its own line too. Ask authors to name what they removed or fixed before review: temp files, debug logs, dead code, extra prompts, test-only flags, throwaway scripts, and comments that no longer help. A simple sentence is enough. "Removed seed reset script and deleted debug endpoint" tells a reviewer much more than "cleaned things up."

If you want a low-friction start, change one prompt this week, not the whole form. Replace a style question with one direct question about business rules or unsafe commands in pull requests. Then watch five real PRs go through. If reviewers still miss problems, tighten the wording and try again.

That is the practical side of PR templates for assistant-heavy repos. They should help people catch bad outcomes early, not create longer review rituals.

If your team needs outside judgment, Oleg Sotnikov at oleg.is works as a Fractional CTO and advisor on AI-first development, infrastructure, and review processes. That kind of outside review can help when a team knows its PR habits are weak but cannot see the blind spots clearly from inside the repo.