datashaman/skills/review

---

name: review

description: Produce an approve or block decision with reviewer-grade checks—maintainability, team policy, and OWASP-style web review—captured in review_decision.json.

Review

When to use

• Reviewer Agent (or human) after verification_report.json is pass for merge-worthy work—or fail with documented risk acceptance (rare; usually fix first).

Inputs

• verification_report.json, diff, team standards (CONTRIBUTING, security doc, ADRs).

Review sequence (grounded)

1. Verifier residual risk

• Re-read findings. If any critical/high is open, default is block unless an explicit exception is documented (ticket + owner).

2. Correctness vs intent

• Thoroughly verify the change against spec.json contracts: walk every declared API endpoint (method, path, request/response shapes, success and error status codes), data assumptions, and UI states (loading, success, error, empty). Treat naming mismatches, missing paths, wrong codes, and edge cases called out in ACs as defects—do not rely on the Verifier having caught them all.

3. Maintainability (quick)

• Size: small PRs easier; if huge, note risk.
• Duplication: new helpers vs copy-paste.
• Naming & types: public API surface clear?
• Tests: meaningful assertions, not only coverage theater.

4. Web security pass (diff-aware)

Answer these from the changed code:

• AuthZ: Does every mutating or sensitive read check permission for the right resource (not only “logged in”)?
• Input: Validation on boundary; reject oversize payloads where relevant.
• Injection: Parameterized queries/ORM; no innerHTML with untrusted data; careful eval, exec, shell.
• Secrets: No tokens/keys in code or logs; use existing secret patterns.
• Headers / cookies: HttpOnly, Secure, SameSite where cookies carry auth.
• SSRF / redirects: User-supplied URLs fetching server-side?

(Aligns with common OWASP categories; depth scales with exposure—internal admin vs public internet.)

5. Policy & compliance

• License headers, PII handling, logging PII restrictions, feature flags per team rules.

Decision output

• review_decision.json: decision approve | block, verification_ref, summary, blocking_findings (each with impact, owner per workflow), non_blocking_notes, metadata.

Anti-patterns

• Blocking on taste without policy or defect link.
• Approving with silent critical/high verifier findings.