AOS/agency-agents/skills/pr-review/SKILL.md

name, version, applies_to, risk

name	version	applies_to	risk
pr-review	1.0.0	code-reviewer frontend-dev backend-dev	low

PR Review (review_verdict)

When to use

Whenever a pull request is opened against a project's protected branch and a verdict is needed before the PR can be merged. The reviewer is read-only — it returns a verdict; it never pushes, merges, or edits the diff.

Steps

1. Read the project's RULES.md from the repo root. If it is missing, return blocked and flag to software-lead — review is against that file, not against personal taste.
2. Fetch the PR diff via github:read_pr; read the touched files in context with github:read_repo and recent history with git:log.
3. Run the project's test suite (CI status on the PR). If CI is red, the verdict is changes_requested — do not proceed to substantive review until the build is green.
4. Check the diff against the RULES.md checklist, covering at minimum:
   • Correctness against the task's definition_of_done.
   • GoBD: no deletion of accounting records (invoices, ledger entries, audit log); storno-only for reversals; gapless numbering untouched.
   • Secrets: no API keys, tokens, passwords, private keys, or connection strings in the diff or in committed env files.
   • Brand/UI: no indigo or blue palette unless explicitly requested in RULES.md; sticky footer present and functional; responsive breakpoints covered; WCAG 2.1 AA (labels, focus, contrast, alt text).
   • Input validation / authn / authz on any new endpoint or form.
   • Log content: no PII in logs; no full request bodies.
   • Dependencies: new packages reviewed for necessity and license.
5. For PRs touching auth, payments, file uploads, external APIs, or user input, run security-review. Flag injection, IDOR, SSRF, XSS, auth bypass, and supply-chain risks with severity.
6. Classify every finding as blocking or non-blocking:
   • Blocking = breaks RULES.md, security hole, build break, data loss, accessibility regression, missing tests for new behavior.
   • Non-blocking = stylistic preferences RULES.md does not codify → goes in notes, never in the verdict.
7. Produce the review_verdict per schemas/deliverable.json:
   • approved — meets RULES.md, no unresolved blocking findings, CI green.
   • changes_requested — concrete fixable blocking findings; list each with file, line, and the rule it breaks.
   • rejected — fundamentally wrong (wrong layer, wrong abstraction, security hole the author should not patch over). The PR should be closed, not iterated.

Inputs

• A PR URL or PR id on a project repo.
• The project's RULES.md in the repo root.
• The originating AOS task id and its definition_of_done.

Outputs

An AgentDeliverable (schemas/deliverable.json) with:

• status: done | blocked
• deliverables[]: review notes (inline, per-file with line refs) and security findings list where relevant.
• risks[]: unresolved high-severity findings, areas not reviewed (e.g. generated files, vendored deps), assumptions made.
• review_verdict:
  • reviewed_task_id: the PR's source AOS task
  • verdict: approved | changes_requested | rejected
  • notes: blocking findings first, then non-blocking suggestions
• cost: tokens only.

Guard rails / compliance

• Never merge the PR. github:merge_to_main is forbidden in this spec.
• Never block on style nitpicks that RULES.md does not codify.
• Never approve with an unresolved high-severity security finding.
• Never approve without reading the full diff.
• GoBD: flag any deletion of accounting/audit records as blocking.
• DSGVO: flag any PII added to logs, error messages, or commits as blocking.
• Secrets in the diff are always blocking and must be reported to software-lead immediately for rotation.
• WCAG 2.1 AA regressions on client-facing UI are blocking (BFSG).

References

• schemas/deliverable.json — review_verdict shape
• policies/compliance.md — GoBD, DSGVO, UWG, BFSG, secrets
• agents/software/code-reviewer.md — operating rules
• Project RULES.md in the reviewed repo