Checklist and Review Skills

Standards that apply themselves

One of the most valuable uses of skills is turning a team's unwritten standards into a procedure: a pull-request review skill that walks the diff against your checklist (error handling, tests, naming, security), a database-migration check (locks, backwards compatibility, rollback), an accessibility audit, a pre-release readiness report. The pattern: a read-only skill with a checklist file in references/, a report template, and a rule that every finding cites evidence (file and line) so that unverified claims are dropped. Keep the checklist short and specific to your codebase's real recurring problems; a generic 60-item list is ignored. Keep review skills read-only (no edits) so they are safe to run anywhere, and let a separate step apply fixes after a human has read the findings.

Skills worth writing

The most useful skills are checklists, templates, verification loops and team playbooks.

A review report template

Requiring a file and line for every finding keeps the report honest. Illustrative; not run here.

# PR review: <title>

## Summary
One paragraph: what the PR does and whether it matches the description.

## Findings
| Severity | File:line | Problem | Suggested fix |
|---|---|---|---|
| high | shop/cart.py:42 | discount applied before tax rounding | round after tax |

## Checklist
- [x] tests added/updated
- [ ] error paths handled
- [x] no secrets or debug code

Rule: every row cites a real file:line from the diff. Delete rows you cannot cite.

Keep review skills read-only

A skill that cannot edit is safe to run anywhere; apply fixes in a separate, approved step.

Quick check: Why must each review finding cite a file and line?

• It makes the report longer
• It forces evidence and lets unverified claims be dropped
• It is required by Git
• Findings do not need evidence