Grok Bots Directory
Submit a Grok Bot

Land first, sample after: merge on proof, review later

Land first, sample after is lauren's (@poteto) routine for code review at scale. Agents merge their own PRs once verifiers and CI pass, and she reads what landed the next morning.

The playbook

The playbook moves human review from before the merge to after it. In a livestream Q&A with Matt Pocock, lauren says she now reviews pull requests after they land. Her setup makes that safe. She turns code smells she sees into refactors and lint rules, so, as she wrote on X, "landing code becomes very safe as long as CI passes." When she runs full autopilot in pstack, a swarm of verifier agents checks every PR. They run the app, click around like a real user, and look for regressions, and the PR lands only after they pass.

The review that is left is sampling. She says that at scale you cannot taste every dish that comes out of the kitchen, "So it becomes more about sampling". Each morning she reads her commit history and reverts or changes what needs it. A one-off mistake may need no fix. When several agents take the same shortcut or spread the same workaround, she fixes the environment instead of the PR: the skills, constraints, lints, and types. Matt Pocock summed up the idea as sampling instead of blocking.

How a Grok Bot runs land first, sample after

  1. Gate every merge on a clean verdict

    pstack's autopilot-full playbook gives each PR one owner agent that takes it from build to merge. Fresh verifiers re-run the gates, prove the change live on the real surface, audit the diff, and run the same scenario on trunk. Nothing merges without a clean verdict on the exact patch that merges, and CI must pass on that head first.

  2. Leave a trail on every PR

    Within about 15 minutes, each owner opens its PR and starts a decision log with /show-me-your-work: one append-only row per decision, with the reason, an evidence pointer, and the result. The PR, its checks, and the log are what you read later.

  3. Give long runs a finish condition

    For one long task overnight, hand over the goal, a checkable definition of done, the permissions, and a way out if it gets stuck. pstack's overnight guide warns that a duration is not a finish condition. Each loop makes one change, runs one check, and logs one row.

  4. Sample in the morning

    Ask /show-me-your-work to catch you up. A reviewer from a different model family reads the trail and the transcript, and the reply ends with an Attention section. Read that first, then the rows it points at, then spot-check the commit history and revert or fix what needs it.

  5. Fix the environment, not the PR

    When the same shortcut shows up across several agents, change the skills, lints, types, or architecture so the next agent cannot take it. Items you name yourself stay at merge-ready for your click, and autopilot-stack ships nothing, so you can land the stack yourself when you want your eyes on it first.

Inspired templates4

A template is listed here only when its own skills or memory let it land PRs after an automated gate, such as CI, Bugbot, or an evidence check, without waiting for a human review, and leave a record you can read afterward: a review comment, a report, or a merge note. Bots that open PRs and wait for your merge are not listed.

Engineering QA Bot

Engineering QA Bot

by

Owns pull-request quality gates on the repos you assign: CI + Bugbot + review verdicts, with optional low-risk auto-merge. Reports to your ops lead; only escal…

  • Memories4
  • Skills1
  • Routines0
Github Manager

Github Manager

by

Watches your GitHub pull requests and triages them into easy wins, bounce-to-implementer, or escalate-to-you — with merge-coded COMMENT reviews and blast-radiu…

  • Memories7
  • Skills1
  • Routines1
Marc

Pissed-off SRE who still always comes through. Owns CI, uptime, deploys, and the machines the work needs — complains, then ships the fix.

  • Memories6
  • Skills4
  • Routines0

More playbooks

All playbooks