code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# code-review

The review entry point for this repository. GitHub Copilot code review reads agent skills from
`.github/skills/` on the head branch, and is more likely to use a skill whose directory name and
description target review — this file is that entry point. Any other agent asked to review a diff
in this repository follows the same route.

This file routes; it does not review. The review work lives in sibling skills under
`.ai-badger/skills/` — open the ones the route names, in the order the change warrants.

## The route

Work top-down. Stop expanding when the verdict for the change is clear; do not stop before it is.

1. **Rank the diff by blast radius** — open `.ai-badger/skills/review-changes/SKILL.md` when the
   project has it. A 3-line change to shared auth outranks a 200-line change to one leaf
   component; rank before reading, so the deepest checks land on the riskiest units.
2. **Run the pass/fail gates** — open `.ai-badger/skills/code-review-checklist/SKILL.md` for
   every review. Sequential phases: build/tests/lint/secrets first, then layering, security,
   contracts. Report every FAIL in the finding shape the checklist defines — item, severity,
   location, evidence, impact, fix.
3. **Judge changed tests** — open `.ai-badger/skills/review-tests/SKILL.md` when the diff adds or
   changes test files. A vacuous gate or an unproven red is a finding, not a style note.
4. **Name the missing coverage** — open `.ai-badger/skills/design-tests/SKILL.md` when a
   high-risk unit has no covering test. Name the specific missing case (input, expected
   behaviour) — never "consider adding tests".
5. **Whole-project review** — open
   `.ai-badger/skills/complete-project-scope-code-review/SKILL.md` only when the request is the
   entire codebase rather than a diff; do not stretch a PR review into one.

**Baseline when a named sibling is not installed** (opt-in skills ship only when the project asked
for them): do that step inline at its cheapest — diff stat plus `git log` for ranking, the
checklist's Phase 1 gates verbatim, and every high-risk untested unit named individually with its
missing test case. Say which siblings were absent; the review is thinner for it, not silent.

## Reading Copilot's review (when Copilot ran, not you)

- Copilot always leaves a "Comment" review, never "Approve" or "Request changes" — its verdict
  does not block merge and does not count toward required approvals. Weigh its comments through
  the checklist; a green Copilot review does not substitute for Phase 1.
- Attributions at the bottom of a review comment name the agent skill or MCP server that produced
  it — follow them when a comment cites this project's skills.
- Re-review after a push is manual unless automatic reviews are configured; resolved
  conversations may repeat on re-review.
- Suggested changes can be accepted in bulk or handed to the Copilot cloud agent via
  "Fix with Copilot" — a suggested change is still a finding; check it against the diff before
  committing it.

## Review output

Findings in one shape, severity-ordered — item, severity, location, evidence, impact, fix — then
the merge recommendation: safe to merge / merge with tracked test debt / block. A review that
ends without a recommendation is incomplete; so is one whose recommendation does not follow from
its own findings.

## Stack adjustments

The sections below are scaffold-time merges: each ships only when the project's config detects
that stack, so what you read here is the adjustment for THIS project's stacks.


## python review adjustments

Apply alongside the generic route when the diff touches Python.

- Read `.ai-badger/skills/review-tests/references/stack-python.md` **when** judging changed
  pytest tests and the file exists — it is a stub in some catalogs and says so; when it is a
  stub, fall back to the generic passes rather than inventing stack rules.
- Weight fixture isolation and shared-state teardown as correctness findings: a test suite that
  passes only in file order is a non-determinism finding, not a hygiene note.
- Treat unseeded randomness, wall-clock reads, and ambient environment variables in production
  paths as testability findings when no seam exists to control them.
- Run the project's own lint and typecheck from config `commands` **before** approving Phase 1 —
  Python typing drift is invisible to a review that only reads the diff.

## ts review adjustments

Apply alongside the generic route when the diff touches TypeScript.

- The checklist's ts sections (browser security, TypeScript quality) merge into
  `.ai-badger/skills/code-review-checklist/SKILL.md` at scaffold time — zero tolerance for `any`
  in application code and unsafe `as` casts is the floor, not a preference.
- Read `.ai-badger/skills/review-tests/references/stack-ts-react-browser.md` **when** judging
  tests for browser or Node TypeScript — it carries the ecosystem-specific rule bodies the
  generic passes point at.
- Treat unawaited promises and floating `void`-discarded async calls as error-handling findings:
  an unobserved rejection in a PR is a silent failure path the type system approved.
- Verify route params and external input pass a schema parse **before** reaching business logic
  — a string that merely compiles is unvalidated input.

## Gotchas

- Skills and instructions are read from the head branch, so guidance changed in this same PR
  governs its own review — editing review rules and expecting the old rules is the mistake.
- The route is order-sensitive: ranking after reading wastes the reading; judging tests before
  ranking spends the test-quality pass on low-risk files.
- Dismissing a Copilot conversation is not an instruction to Copilot — on re-review the same
  comment can return; fix the code or refute the finding in the thread instead.

From Arasz/ai-badger, MIT.

More from Arasz/ai-badger