// Review your own changes before creating a pull request. Use this before running create-pr, or whenever you want to check that your changes are clean, correct, and well-tested. Trigger when: about to create a PR, finished a chunk of work, or asked to review changes.
Changelog style guide for writing RELEASE.md files. Use when creating or reviewing RELEASE.md, writing changelog entries, or preparing a PR that needs release notes.
How to approach code coverage in this project. Use when coverage CI fails, when writing tests for new code, or when you need to make untestable code testable. Also use proactively when writing new code to ensure it will be coverable.
| name | self-review |
| description | Review your own changes before creating a pull request. Use this before running create-pr, or whenever you want to check that your changes are clean, correct, and well-tested. Trigger when: about to create a PR, finished a chunk of work, or asked to review changes. |
Run through these checks before creating a PR or declaring work complete. The goal is to catch the things a human reviewer would flag, before they have to.
Run all of these — they're fast and catch the most common issues:
just check # formatting, lint, tests, docs
Fix any failures before proceeding. Don't skip checks because they passed locally last time — the code may have changed.
Run git diff origin/main...HEAD and read through it. Look for:
file:// URLs or local fixtures instead? Keep at most one integration test that verifies the real network path works./tmp/foo in tests should be a generated temp directory for isolation and cleanup.Run just check-tests and review the output. If new code is uncovered, address it before the PR — don't rely on CI to catch it. See the coverage skill for how to approach coverage gaps.
Ask yourself: if someone else wrote this diff, what would I flag in code review? Common things to catch: