Chapter 2 of 8 · 5 checks · 3 min

Code is ready for other eyes

These checks make sure the reviewer sees finished code that builds, passes the automated checks and contains nothing you would not want merged.

Show

The project builds and the lint, format and type checks pass locallyMust
Why it matters and how to check
GitHub's guidance asks authors to confirm that the relevant builds and tests have run before requesting review. A pull request that fails to build wastes the reviewer's time and usually means more changes are coming, so any review now may be wasted.
To verify, run the same commands CI runs, for example npm run lint, npm run typecheck and npm run build, or your project's equivalents such as ruff check and mypy. They should all exit cleanly. If you are not sure what CI runs, read the workflow files in .github/workflows.
No debug logs, commented out code or stray TODOs are left inShould
Why it matters and how to check
console.log, print, debugger statements and blocks of commented out code are easy to leave behind and noisy for reviewers. Commented out code also never gets cleaned up later: it stays in the codebase, confusing every future reader. Git already keeps the old version.
To verify, search the diff only: git diff main...HEAD | grep -nE "console\.log|print\(|debugger|TODO". Remove each hit or, for a TODO that must stay, link it to a ticket with an owner.
Example
Shell
git diff main...HEAD | grep -nE "^\+.*(console\.log|print\(|debugger|TODO)"
No secrets, credentials or personal data are in the diffMust
Why it matters and how to check
A key or password pushed to a shared branch should be treated as leaked, even if you remove it in the next commit, because it stays in the Git history and in every clone. Test data copied from production can expose real customers in the same way.
To verify, search the diff for words such as key, secret, token, password and long random looking strings, and check that .env files are not staged. Run a secret scanner such as gitleaks or rely on GitHub secret scanning if your repository has it. If a real secret was pushed, rotate it first, then clean the history.
Example
Shell
git diff main...HEAD | grep -niE "secret|token|password|api[_-]?key" git ls-files | grep -E "\.env$|\.pem$|id_rsa"
Any dependency change is intentional, explained and has its lock fileShould
Why it matters and how to check
New packages add code you did not write, and GitHub's guidance asks for extra attention on changes to dependencies. Reviewers need to know why a package was added, and the lock file must match so CI and production install exactly what you tested.
To verify, compare package.json, requirements.txt, go.mod or similar against main. For every added or upgraded package, note in the description why it is needed and that you checked it is maintained. Confirm the lock file changed in the same commit and that only the packages you meant to change moved.
New failure paths are handled and logged usefullyShould
Why it matters and how to check
New code that calls the network, the database or the filesystem adds new ways to fail. Reviewers will ask what happens when the call times out or returns an error, so answer it before they do.
To verify, list each new external call in your change and check what happens on failure: is the error caught at the right level, shown to the user in a helpful way, and logged with enough context, such as the request id, to debug it later? Make sure logs do not include passwords, tokens or full personal data.