commit-pr

Use the format `<type>(<scope>): <summary>` where type is one of feat, fix, perf, refactor, docs, test, build, ci, chore, or revert. Keep the title short and imperative, put detail in the body, and aim for one logical change per commit.

Look at the project's own configuration: package.json scripts, Makefile targets, pyproject.toml, Cargo.toml, or CI workflow files under .github/workflows. Run whatever build, test, lint, type-check, and format checks exist, pinned to the versions the project declares.

Use `git push --force-with-lease` instead of a plain force push. It refuses to overwrite commits the remote gained since your last fetch, so it cannot silently clobber a teammate's work.

Never commit generated build output, dependency directories like node_modules or vendor, local caches, or secrets such as .env files, credentials, and keys. If any are tracked or unignored, fix .gitignore instead of committing them.

Fill in the repo's PR template if one exists under .github. Otherwise include a Summary of what changed and why, a Test plan listing the checks you ran and their results, and a linking keyword like `Closes #<issue>` when the PR resolves an issue.

A PR is done when its required CI checks are green and review feedback is addressed. If CI fails, read the logs, reproduce locally, fix the real cause, and push again — never merge over failing checks or disable a check to go green.