Z User
136379c666
- 18 agent specs across Software, Support, Marketing, Cross-cutting (orchestrator + 7 software + 5 support + 3 cross-cutting + leads-finder) - 8 reusable skills (handoff, pr-review, dokploy-deploy, campaign-structure, content-calendar, ticket-triage, license-lifecycle, invoice-draft) - 3 JSON schemas: handoff, deliverable, approval - Policies: autonomy levels, tool risk classification, compliance (DSGVO/GoBD/UWG) - routing.toml: model tiers T1/T2/T3 + provider config (PII gating) - Rust workspace (5 crates, all compile + 16 tests pass): - aos-mcp: tool registry + risk tagging - aos-policy: autonomy levels, budget enforcement, approval requests - aos-license: ed25519 license issue/verify (real crypto + CLI binary) - aos-ledger: integer-cents money math, gapless numbering, VAT, audit chain - aos-sync: frontmatter validator (18/18 specs pass), CLI binary - CLAUDE.md entry point with architecture overview + roadmap
86 lines
4.1 KiB
Markdown
86 lines
4.1 KiB
Markdown
---
|
|
name: pr-review
|
|
version: 1.0.0
|
|
applies_to: [code-reviewer, frontend-dev, backend-dev]
|
|
risk: 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
|