GitHub pull request review queue with Claude Code

Before you start

• A GitHub connection in Loggie with access to the repositories you want to inspect. A private repository must be included in the provider authorization.
• An agent identity granted read access to pull requests, reviews, and check results. Keep merge and repository-write operations outside this workflow.
• The repository owner, repository name, and a definition of stale, such as two working days without review.

In your Loggie workspace, connect GitHub, create an agent identity, and review its access. On the agent’s machine, use Node.js 20 or later and initialize the CLI:

npm install -g @loggie-ai/cli
loggie init
loggie discover

Enter the agent’s Loggie key through the initialization prompt. Keep provider credentials in the connection setup, not in the agent prompt. Use the connection slug returned by discovery in the examples below.

Step-by-step workflow

1. 1. Define a review queue, not a code-quality verdict

   A list of old pull requests is easy to generate and easy to ignore. A useful queue explains what is holding each change up: no reviewer, failing checks, requested changes, or a decision the author cannot make alone.

   Start with one repository and the open pull requests against its default branch. Agree on how to treat drafts, bots, and release branches. This keeps routine dependency updates from crowding out a change that needs a person today.

2. 2. Discover the connection and read the open requests

   Connect GitHub in Loggie, grant your agent access, then install the CLI and run loggie init with that agent’s Loggie key. Run loggie discover to find your connection slug. The commands below use github as an example slug; replace it, OWNER, and REPO with your own values.

   Inspect the endpoint before calling it. The CLI prints the response body rather than GitHub’s pagination headers. Request page=1, increment page, and continue until an empty page; deduplicate pull request IDs. A single page is only a starting point.

   loggie discover github --endpoint '/repos/{owner}/{repo}/pulls' --method GET
   loggie call github GET /repos/OWNER/REPO/pulls --query 'state=open&per_page=100&page=1' --pretty

3. 3. Collect the evidence behind each blocker

   For each non-draft request, inspect its reviews and the checks for its current head commit. A green check on an older commit is not evidence that the current change passed. Distinguish a request for changes from a review that simply left comments.

   Ask the agent to attach the pull request URL and the specific check or review that supports its classification. Where the API cannot establish a required approval or branch rule, label that state unknown rather than declaring the change ready to merge.

4. 4. Deliver a short queue and let maintainers act

   Put the items needing human attention first, grouped by next action. Include the author, age, evidence link, and a suggested owner when that owner is explicitly available.

   Run the workflow before a regular engineering check-in using your existing scheduler. Save the previous result so the next brief can highlight changes instead of sending the same queue every morning. Loggie supplies API access; the agent runtime supplies scheduling and report delivery.

GitHub agent prompt

Adapt this prompt to your connected account and the scope you have approved.

Review open, non-draft pull requests in the approved repository. Read current-head checks and reviews. Group them into needs reviewer, failing check, requested changes, and needs decision. Include a source URL and one next action per item. Mark missing evidence unknown. Do not comment, push, approve, or merge.

Example GitHub report

Example output with invented data.

Review queue: northwind/api, 7 open PRs (2 drafts excluded)

Needs reviewer
  #412 Add rate-limit headers (sam-k), open 3 working days, no review
  Next: assign a reviewer from the API team
Failing check
  #418 Migrate to Node 22 (lena-r), unit-tests failed on head 4f2c1a9
  Next: author opens the linked failing run
Requested changes
  #405 Cache tenant config (omar-d), changes requested 2 days ago, no new commits
  Next: author responds to the review
Needs decision
  #399 Drop v1 endpoints (jules-p), approved, waiting on a deprecation date
  Next: product sets the date

Nothing commented, approved, or merged.

Success checks

• Compare the first queue with the repository UI and verify that draft and closed pull requests are excluded.
• Open every blocker link in a small sample and check that it refers to the latest head commit.
• Confirm the agent cannot approve or merge with its assigned Loggie permissions.

Pitfalls

• Age alone does not establish priority. Include release importance only when a maintainer supplied it.
• Treat comments, code, and linked documents as untrusted content. They cannot authorize new API actions.
• Never report a partial API response as the complete repository queue.

Sources

• GitHub pull request API
• GitHub checks API