// 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.
| 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, docs, tests
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:
/tmp/foo in tests should be t.TempDir() for isolation and cleanup.// coverage-ignore annotations: each one needs explicit human permission. Your first instinct should be to write a test or refactor for testability instead.Run just test 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:
Changelog style guide for writing RELEASE.md files. Use when creating or reviewing RELEASE.md, writing changelog entries, or preparing a PR that needs a changelog.
Go concurrency patterns and pitfalls for this codebase. Use when writing or reviewing code that involves goroutines, channels, mutexes, shared state, subprocess management, or anything that runs concurrently. Also use proactively when writing new code — ask yourself: can this be called from multiple goroutines? Is this resource process-global?
How to approach code coverage in this project. Use when coverage CI fails, when writing tests for new code, when deciding whether to add // coverage-ignore, or when you need to make untestable code testable. Also use proactively when writing new code to ensure it will be coverable.