Produce PRs that are safe to merge, minimal in scope, and verified by local checks. Prioritize correctness, stability, and maintainability. Avoid "garbage diffs."
- No cosmetic refactors unless explicitly requested:
- formatting-only changes
- mass rename / reorder imports across unrelated files
- unrelated cleanup, dead code removal, file moves
- One PR = one intent:
- If scope grows, split into separate PRs (or revert unrelated changes).
- Do not change public/shared APIs without:
- tests
- explicit migration notes (in PR description)
- Do not assume CI will catch issues:
- run required checks locally (or in the sandbox) before PR.
- ESLint must follow Airbnb-style conventions.
- Prefer consistent patterns already present in the codebase.
- No opinionated rewrites (hooks refactors, component splitting, etc.) unless necessary for the request.
- Prefer explicit, readable code.
- Do not introduce heavy refactors unless required for correctness.
- Keep changes localized; avoid broad restructuring.
Before opening or updating a PR:
A) Sync with base branch
- Ensure the working branch is up-to-date with the target base branch (merge or rebase, per repo policy).
B) Run verification in strict order (stop on first failure)
- static analysis (lint/format checks)
- type/compile checks
- tests
- build
C) If build fails
- Fix minimally
- Re-run build
- Repeat until build succeeds
D) Only after successful build
- Prepare PR with a clear description + verification evidence.
If any step is not executed, clearly state: NOT VERIFIED.
Use the repo’s existing scripts/config first. Typical conventions:
- Install:
bun installORpnpm installORnpm ci - Lint:
bun run lint(orpnpm lint/npm run lint) - Typecheck:
bun run typecheck(ortsc -p ...) - Test:
bun run test - Build:
bun run build
- Install (preferred):
uv syncORpoetry installORpip install -r requirements.txt - Lint/Format:
ruff check ./ruff format --check .(or repo-standard) - Typecheck:
mypy .(if configured) - Test:
pytest - Build/Package (if applicable):
python -m build(if configured)
When multiple exist, prefer what the repo already uses.
When asked to implement or prepare a PR, produce:
- Change summary (what/why)
- Scope statement (what changed vs not changed)
- Verification results (commands + pass/fail)
- Risk assessment (low/medium/high) + rollback note if needed
- PR-ready text (title + description)