--- description: High-signal PR review for gh-aw workflows using safe outputs --- Provide a code review for the given pull request. **Agent assumptions (applies to all agents and subagents):** - All tools are functional and will work without error. Do not test tools or make exploratory calls. Make sure this is clear to every subagent that is launched. - Only call a tool if it is required to complete the task. Every tool call should have a clear purpose. - Use GitHub MCP tools for repository reads. Do not use `gh` CLI commands for repository inspection or for posting review output. - Use the workflow PR number as the authoritative target. - Review output must be terse and issue-focused. Do not praise the PR, narrate checks that passed, explain why code is correct, or offer "good change" commentary. - Use only gh-aw safe outputs for review side effects: - `create-pull-request-review-comment` for actionable inline findings on changed lines - `resolve-pull-request-review-thread` for unresolved bot-authored review threads that are now fixed or clearly acknowledged - `submit-pull-request-review` for the final review decision - `noop` when no action should be taken - Use cache-memory only for short-lived continuity and deduplication hints. Treat live PR state and current review threads as the source of truth. - Never post free-form issue comments or use any side channel for review output. - Respect the workflow safe-output limits. Prioritize the highest-signal unique findings and keep the inline review set within the configured maximum. - Consult `.gitattributes` when relevant and treat files matched there as generated by default. Ignore findings that exist only in generated outputs such as `.lock.yml` files unless the corresponding source-of-truth files show a real behavioral problem. To do this, follow these steps precisely: 1. Create a short todo list for yourself before starting. 2. Launch a fast subagent to check if any of the following are true: - The pull request is closed - The pull request is a draft - The pull request does not need code review (e.g. automated PR, trivial change that is obviously correct) - Required PR context cannot be read from the workflow tools If any condition is true, call `noop` with a brief reason and stop. Note: Do not skip solely because prior automated review comments exist. Use prior comments for deduplication and stale-thread cleanup instead. 3. Read any prior review memory for this PR from cache-memory before you start detailed analysis. Use a PR-specific file such as: - `/tmp/gh-aw/cache-memory/pr-${PR_NUMBER}.json` If a prior memory file exists, use it only as a hint for: - Previously reported issues - Dedupe patterns - Prior review timestamps - Risk areas worth re-checking Do not trust cache-memory over current GitHub state. If memory conflicts with the live PR, changed files, or review threads, trust the live PR and ignore stale memory. 4. Launch a fast subagent to return a list of file paths (not their contents) for all relevant `CLAUDE.md` files including: - The root CLAUDE.md file, if it exists - Any CLAUDE.md files in directories containing files modified by the pull request 5. Launch a subagent to summarize: - The PR title and description - The changed files - The main behavioral changes in the diff - Any obvious risk areas worth checking carefully 6. Fetch existing review comments and review threads on the PR before preparing any new findings. Use them to identify: - Similar issues already flagged - Threads where a human already acknowledged the feedback - Comments on code that has changed since the earlier review and may now be stale - Unresolved bot-authored review threads that may now be fixed or obsolete 7. Launch 4 review subagents in parallel. Each agent should return a list of candidate issues, where each issue includes: - A concise description - The reason it was flagged (for example `CLAUDE.md adherence` or `bug`) - The changed file path - The changed line or closest changed hunk - Why the issue is likely real Agents 1 + 2: CLAUDE.md compliance sonnet agents Audit changes for `CLAUDE.md` compliance in parallel. When evaluating a file, only consider `CLAUDE.md` files that share a path scope with that file or its parents. Agent 3: bug-focused review agent Scan for obvious bugs. Focus only on the diff itself without reading extra context. Flag only significant bugs; ignore nitpicks and likely false positives. Do not flag issues that you cannot validate without looking at context outside of the git diff. Agent 4: behavior-focused review agent Look for problems introduced by the new code, including security issues, incorrect logic, regressions, and missing error handling. Only look for issues that fall within changed code. **CRITICAL: We only want HIGH SIGNAL issues.** Flag issues where: - The code will fail to compile or parse (syntax errors, type errors, missing imports, unresolved references) - The code will definitely produce wrong results regardless of inputs (clear logic errors) - The code introduces a clear security or regression bug in changed lines - Clear, unambiguous `CLAUDE.md` violations where you can quote the exact rule being broken Do NOT flag: - Code style or quality concerns - Potential issues that depend on specific inputs or state - Subjective suggestions or improvements If you are not certain an issue is real, do not flag it. False positives erode trust and waste reviewer time. Each review subagent should receive the PR title and description so it can evaluate intent. 8. For each candidate issue, launch validation subagents in parallel. Each validator should receive the PR title, description, issue description, affected file, and affected hunk. The validator must confirm that the issue is real with high confidence. For bug and logic issues, verify the changed code actually causes the stated problem. For `CLAUDE.md` issues, verify both: - The cited rule exists - The rule applies to that file path and is actually violated 9. Filter out any issue that fails validation. 10. Deduplicate and prune the validated issue list. Remove: - Issues already covered by an existing review comment - Issues in threads where a human has already acknowledged the feedback - Issues that were present in an earlier revision but are fixed in the latest code - Duplicate findings reported by multiple subagents - Findings that are not on changed lines or cannot be tied to a changed hunk - Findings that only came from cache-memory and are not confirmed by the current PR state Also create a separate internal list of review threads to resolve. A thread is eligible for resolution only when all of the following are true: - The thread is currently unresolved - The thread was started by this automation or another bot, not by a human reviewer - The underlying issue is fixed in the latest diff, outdated, or explicitly acknowledged by a human as intentionally left as-is - You have high confidence that resolving it will not hide an outstanding real issue Never resolve human-authored review threads. When uncertain, leave the thread unresolved. 11. Classify the remaining issues: - `Blocking`: correctness, security, regression, data loss, or clear required-rule violations - `Non-blocking`: actionable but not merge-blocking concerns that are still worth interrupting the author for now Drop any candidate that is merely: - praise - reassurance - a follow-up idea - a readability suggestion with no concrete risk - an observation that does not require author action 12. Produce a short internal summary of findings for yourself: - If issues remain, list the highest-signal ones first - If no issues remain, summarize that no actionable high-signal issues were found 13. If no actionable issues remain, submit exactly one final review with `submit-pull-request-review`: - Use `APPROVE` - Use one short sentence only, such as `No actionable issues found.` - Do not create inline comments - Do not include praise, summaries of what was checked, or correctness narration - Before stopping, write a compact review memory file for this PR containing: - review timestamp - PR number - files reviewed - summary of what was checked - `issues_reported: []` - Stop after the final review is submitted and memory is updated 14. If actionable issues remain, choose the highest-signal unique issues up to the safe-output comment limit. Create a list of planned inline comments for yourself before posting anything. Prefer zero comments over low-signal comments. Non-blocking comments should be rare. 15. Post one inline comment per chosen issue using `create-pull-request-review-comment`. For each comment: - Provide a brief description of the issue - Explain why it matters - Reference the exact changed line - Cite the relevant `CLAUDE.md` rule when applicable - Keep the comment concise and actionable - Do not post comments that merely suggest optional follow-up cleanup or extra documentation - Do not post comments whose conclusion is that the code is acceptable as-is - Do not post duplicate comments for the same issue 16. Resolve eligible stale review threads using `resolve-pull-request-review-thread` before submitting the final review. - Resolve only threads from your internal resolution list - Resolve only bot-authored threads - Do not add explanatory comments when resolving - If no threads qualify, do nothing 17. Submit exactly one final review using `submit-pull-request-review`: - Use `REQUEST_CHANGES` when at least one blocking issue remains - Use `APPROVE` otherwise, including when only non-blocking inline comments were left - Do not use `COMMENT` as the final review state - Keep the summary to one or two short sentences - Do not restate inline comments in the final review; point readers to the inline comments instead - Do not include praise, correctness checklists, or "overall LGTM" framing unless there are zero inline comments and you are using the exact terse approval style above 18. After the final review is submitted, update the PR-specific cache-memory file with a compact record of this review. Store only short-lived operational state such as: - review timestamp - PR number - files reviewed - issue fingerprints or short summaries - whether the final review was `APPROVE` or `REQUEST_CHANGES` Do not store secrets, tokens, personal data, or large blobs. Keep the file concise so future runs can use it for continuity and dedupe. Use this list when evaluating issues in Steps 4 and 5 (these are false positives, do NOT flag): - Pre-existing issues - Something that appears to be a bug but is actually correct - Pedantic nitpicks that a senior engineer would not flag - Issues that a linter will catch (do not run the linter to verify) - General code quality concerns (e.g., lack of test coverage, general security issues) unless explicitly required in CLAUDE.md - Issues mentioned in CLAUDE.md but explicitly silenced in the code (e.g., via a lint ignore comment) - Differences that exist only in files classified as generated by `.gitattributes`, unless they expose a real issue in the source workflow, prompt, or other source-of-truth file - Explanations that a change is good, correct, well-structured, or acceptable as-is - Non-blocking observations that do not require the author to change anything now - Requests for extra comments or documentation unless their absence creates a concrete correctness risk Notes: - Use GitHub tools for all repository reads. Do not use web fetch. - Always operate on the workflow PR target rather than guessing from local git state. - Inline comments should only be created for actionable issues on changed lines. - If you leave inline comments, the final review should not repeat them. - Cache-memory is best-effort and may be missing or stale. Use it to improve continuity, never to override current repository state. - When linking to code in an inline comment, use a full GitHub blob URL with a full SHA and a line range, for example: https://github.com/anthropics/claude-code/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15 - Requires full git sha - Do not use shell substitution in the URL - Repo name must match the repo you're code reviewing - Use `#L[start]-L[end]` - Provide at least one line of context before and after when possible - If context checks fail or the PR is not reviewable, call `noop` with a brief explanation instead of exiting silently.