SKILL.md
---
name: sb-review
description: Reviews a set of code changes end-to-end — code quality, security, conventional-commit compliance, missing tests, and alignment with the project's ADRs and CONTEXT.md. Grounds itself in surrounding context, runs tests and the linter, and produces a structured review with a verdict. Works on any changeset (working tree, a branch diff, or a checked-out PR). Use when the user asks to review code, review a diff, review the current changes, or audit a branch before merging. For reviewing a GitHub pull request and posting comments back, use sb-review-pr (which builds on this skill).
---
# Sunbytes Review
Thorough review of a set of code changes. Combines code review, security review, and convention checks, grounded in the project's own context. Produces a structured review with a clear verdict — it does **not** post anywhere. The [`sb-review-pr`](../sb-review-pr/SKILL.md) skill wraps this one to fetch a GitHub PR and post the findings back.
## What this reviews
A **changeset** — any of:
- Uncommitted working-tree changes (`git diff`, `git diff --staged`)
- A branch compared against its base (`git diff <base>...<head>`)
- A PR that has already been checked out locally (driven by [`sb-review-pr`](../sb-review-pr/SKILL.md))
Establish the diff and the list of changed files before reviewing. If the scope is ambiguous (which base? staged only?), ask.
## Workflow
### 1. Ground yourself in the project
Surrounding code is required to spot cross-file regressions — never review the diff in isolation.
- [ ] Read `CONTEXT.md` if present — domain glossary, terminology
- [ ] Read ADRs (typically `docs/adr/`) that touch the changed areas
- [ ] Open changed files at full size, not just the hunks — read the code around each change
### 2. Validate commit shape
- [ ] **Conventional commits** — every commit subject must match `<type>(<scope>)?: <subject>`. Allowed types: `feat`, `fix`, `chore`, `docs`, `refactor`, `test`, `perf`, `ci`, `build`, `style`, `revert`. Flag offenders by short SHA.
### 3. Code review
For every changed hunk:
- Correctness and edge cases
- Conformance to ADRs and CONTEXT.md terminology
- SOLID / KISS / DRY only when violations actually hurt
- Dead code, unused imports, leftover debug, stray TODOs
- **Test coverage** — every behavioural change needs a test; call out missing ones explicitly with the file path where the test belongs
### 4. Security review
- Input validation at trust boundaries
- Authn/authz on new endpoints
- Secrets in code, configs, or logs
- Injection (SQL, command, XSS, SSRF, path traversal)
- Insecure deserialization, unsafe `eval`, prototype pollution
- New dependencies — flag unfamiliar packages and version-pin status
If a real secret appears in the diff, **stop immediately**, do not echo it, and alert the user out-of-band.
### 5. Run tests + linter
Detect tooling from `package.json`, `Makefile`, `pyproject.toml`, etc. Run against the changes, in this order:
1. Linter / formatter check
2. Type check (if applicable)
3. Tests
Capture pass/fail. Never auto-fix. If tooling is ambiguous or a job will be slow, confirm before running.
### 6. Produce the review
Fill in the template below. Be specific: tie each finding to a file and line, and separate blocking issues from suggestions.
## Review template
```markdown
## Summary
<2–3 sentences on what these changes do and the recommendation>
## Blocking
- ...
## Non-blocking suggestions
- ...
## Tests
- <missing coverage, if any>
## Security
- <findings, or "no concerns">
## Conventions & CI
- Conventional commits: ✅ / ❌ (list offenders)
- Lint: <pass/fail>
- Type check: <pass/fail/n/a>
- Tests: <pass/fail>
```
## When to stop and ask
- More than ~10 blocking issues — present a summary first; don't dump a wall of findings
- Scope mismatches what the change claims to do — flag and stop
- A secret appears in the diff — stop immediately