process-pr-review

A command for reviewing and processing automated comments on a GitHub pull request, which is a proposed code change awaiting review.

In plain words
What is it for?
Use it to inspect the project's bot rules, find comments on the current or specified pull request, and process only the findings that are actually visible.
Why use it?
It prevents review comments from being missed or from causing an endless wait when a bot has no clear completion signal.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/dsnger/dev-workflow-kit/process-pr-review
Clone the repo
git clone --depth 1 https://github.com/dsnger/dev-workflow-kit
Per session 14 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 3,002 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00014 $0.03002
Opus 5 $0.00007 $0.01501
Sonnet 5 $0.00003 $0.00600
Haiku 4.5 $0.00001 $0.00300

Measured 2d ago against content hash ad1d4218db2e, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

process-pr-review scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/dev-workflow/commands/process-pr-review.md · 212 lines

How it starts

The opening of the file, as written. The whole thing — 212 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Process the reviewer comments on PR $ARGUMENTS (no number given → the PR of the current branch, via gh pr view).

Target model: Claude via Claude Code.

Step 0 — Load this project's bot matrix

Read docs/pr-review-bots.md. Its Routing lists are the authority — the table beside them is descriptive, recording where each bot's findings have been seen and how you know it has finished. A bot sits in one of three categories: wait for it (it has a completion signal you can block on), process it opportunistically (it produces real findings but nothing proves it has finished), or ignore it. A bot's channel can vary between PRs, so a row may honestly read inconsistent; that is an observation, never a routing instruction.

Getting this wrong is expensive in both directions: waiting on a channel a bot never uses hangs the loop forever, and treating a findings source as context silently drops real findings.

If docs/pr-review-bots.md is missing: do not guess the matrix. Run gh pr view --json comments,reviews to see which bots have actually posted on this PR, process only what is visibly there, and tell the user to run /dev-workflow:workflow-init (or write the file by hand) so the next run can wait on the right bot.

Step 1 — Check CI first

gh pr checks. The required, branch-protected quality check must be green — a red required check makes the PR unmergeable regardless of review outcomes, and the failure is itself a finding to process. If it is red, fix the failing step before processing bot comments. If it is still running, note it and proceed — re-verify at the end.

Step 2 — Wait for the findings bots

Block only on the bots under Wait for, using the completion signal its row names — which may be a status check rather than a comment, since a bot that finds nothing can finish without posting at all. Waiting for a post from a zero-finding bot hangs.

Then, without blocking, read whatever each Process opportunistically bot has posted at that moment — both channels, inline comments and the PR-level summary body. If one posts after you have begun, handle it as a follow-up rather than waiting for it up front.

Read the full file on GitHub · 212 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 212 lines · 14 tokens per session scan A ad1d4218db2e

Subscribe to this mod's changes

process-pr-review is a command published in the GitHub repository dsnger/dev-workflow-kit (5 stars, last pushed 6d ago), licensed MIT. It adds 14 tokens to every session and 3,002 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.