Engineering

Release review loop

A read-only loop that checks whether your recent PR work actually shipped, comparing merged PRs against published releases, and whether any open-PR deploy gates have cleared. Hands back a Shipping Status report; takes no write actions.

Trigger: Recurring sweep, typically each morning (default window: past 24 hours)
Goal: Confirm what shipped, whether your merged PRs landed in a release, and whether open-PR deploy gates have cleared
Artifact: A Shipping Status report: releases in the window · your shipped work · merged-PR → first-release table · open-PR gate status · follow-up questions
Handoff: You decide which follow-ups to act on. The loop only asks, never merges or relabels
Tools: Claude Code · GitHub CLI (gh) · AGENTS.md

The loop, ready to run

Check whether recent GitHub PR work has shipped and whether any open PR deploy gates are now clear.

Read AGENTS.md first. Use GitHub CLI for live state.

Configuration:
- Resolve repositories from SHIPPING_STATUS_REPOS as a comma-separated list. If the
  environment variable is missing, check whether the prompt or local project notes
  explicitly name repos for this automation. If no repos are configured, stop and report:
  Missing repo configuration; set SHIPPING_STATUS_REPOS or add explicit repos to the
  automation prompt.
- Default window: past 24 hours.
- Default merged PR lookback: 14 days.
- Default user: gh api user --jq .login
- Treat GitHub Releases as the shipping signal when releases exist. For repos without
  releases, fall back to merged-to-default-branch status.

Workflow:
1. Run gh auth status. If authentication fails, stop and report the blocker.
2. Resolve the GitHub user login.
3. For each configured repo, run gh repo view <repo> --json nameWithOwner,defaultBranchRef
   to verify access.
4. List recent releases with gh release list --repo <repo> --limit 30 --json
   name,tagName,createdAt,publishedAt,isDraft,isLatest. Ignore draft releases. Include
   releases published within the window.
5. For each in-window release, compare it with the previous published release using
   gh api repos/<repo>/compare/<prev-tag>...<this-tag>. List commits where .author.login
   matches the user, including commit subject and PR number when present in the commit
   message. If no previous release exists, say that the first-release comparison is limited.
6. Find the user's recent merged PRs with gh search prs --repo <repo> --author <user>
   --merged --limit 5 --json number,title,closedAt,url. For each PR, fetch .merge_commit_sha
   from gh api repos/<repo>/pulls/<num>. Then walk published releases oldest to newest and
   call gh api repos/<repo>/compare/<tag>...<commit> --jq .status; the first tag whose status
   is behind or identical is the first release containing that PR. Prefer commit containment
   over release timestamps.
7. Find the user's open PRs with gh search prs --repo <repo> --author <user> --state open
   --limit 20 --json number,title,url,body,isDraft,labels,updatedAt. Parse bodies for
   dependency signals: Depends on:, Blocked by:, Requires:, deploy warnings like Do not
   deploy or Do not merge until, cross-repo PR refs like owner/repo#123, same-repo refs like
   #123 when dependency context is clear, and ticket refs like PROJ-123 when the PR
   title/body uses that project key.
8. Resolve dependencies with gh pr view for PR references and gh search prs --match title for
   ticket references. A gate is clear only when every resolved dependency is merged and, for
   repos with releases, included in a published release. If a dependency is ambiguous, report
   it as unresolved rather than clearing the gate.
9. For open PRs whose gates are clear, suggest follow-ups only as questions: remove blocking
   labels such as do-not-merge, blocked, or needs-dependency; convert draft PRs to ready;
   update stale deploy/dependency warnings in the body; or merge only when not draft, not
   blocked, approved, and CI is green. Check merge readiness with gh pr view <num> --repo
   <repo> --json reviewDecision,statusCheckRollup,mergeable only when a merge question would
   otherwise be relevant.

Safety:
- Do not take write actions.
- Do not remove labels, edit PR bodies, mark PRs ready, merge PRs, push commits, send Slack
  messages, or open issues.
- Keep all follow-ups as numbered questions for the user to approve later.

Finish with this concise report:

## Shipping Status - <date>

### Releases in <window>
- <repo>: <tag1>, <tag2> or none

### Your work in these releases
- List shipped commits/PRs, or say nothing authored by the user shipped in the window.

### Recent merged work and first release
| Repo | PR | First release | Shipped on |
|---|---|---|---|

### Dependency status for open PRs
| PR | Depends on | Gate status |
|---|---|---|

### Suggested follow-ups
1. <question>

If no releases happened in the window and no open-PR gates changed, return exactly:
No releases in window; no open-PR gates changed.

Use this when

Use this when you ship through pull requests across one or more repos and you want a daily, read-only answer to two questions, without hand-checking compare views: did my work actually land in a release, and are the PRs I’m blocked on finally clear?

How to run it

Point it at your repos through SHIPPING_STATUS_REPOS (or name them in the prompt) with the GitHub CLI authenticated; it reads your AGENTS.md first for shipping context.

Over a rolling 24-hour window it lists new releases, walks each of your merged PRs to the first release that actually contains it, and parses your open PRs for deploy gates and dependency blockers.

It resolves those gates against live PR and release state, and where one is now clear it raises the follow-up as a numbered question. It never merges, relabels, or messages.

Give it a morning cadence so the Shipping Status report is waiting when you sit down.

Why it works

Checking commit containment instead of release timestamps tells you what truly shipped, not just what was tagged around the same time. And keeping every suggested action as a question makes it a safe daily heartbeat: it reconstructs scattered release and PR state without ever touching it.

Get the next loops

I add new loops as I run them on real work — with the full prompt, the trigger setup, and what breaks. Drop your email and I'll send the next ones.

No spam. The loops, plus the occasional note on building with AI. Unsubscribe anytime.