rules-pr-review
Skill1 starsChanged 5 months agoMITView on GitHub
Binding personal rules for reviewing a pull request or diff — load before reviewing any PR (own or others'), writing review comments, or judging datasets/DTOs/API shapes/fetch effects/polls in a change.
In this repository40 other files it gives its agents.
- authoring-project-skillsSkill
- background-jobs-and-cachingSkill
- code-conventionsSkill
- containerize-and-ship-a-serviceSkill
- database-migrationsSkill
- design-an-error-modelSkill
- git-flowSkill
- handle-files-frontendSkill
- import-data-from-csvSkill
- integrate-external-servicesSkill
- integrate-identity-providersSkill
- integrate-internal-servicesSkill
- keep-service-memory-leanSkill
- operate-ecs-services-safelySkill
- prevent-secret-and-pii-leaksSkill
- release-safetySkill
- render-transactional-emailsSkill
- rules-backendSkill
- rules-code-styleSkill
- rules-debuggingSkill
- rules-gitSkill
- rules-infraSkill
- rules-shippingSkill
- rules-workflowSkill
- schedule-effective-dated-changesSkill
- secure-a-frontend-appSkill
- security-auditSkill
- send-slackSkill
- serve-realtime-with-websocketsSkill
- structure-a-backend-serviceSkill
- structure-a-frontend-appSkill
- structure-a-shared-backend-libSkill
- structure-a-shared-ui-libSkill
- tdd-http-firstSkill
- use-feature-flagsSkill
- write-cross-cutting-codeSkill
- write-frontend-codeSkill
- write-frontend-testsSkill
- write-service-codeSkill
- write-unit-testsSkill
The file
Files
rules-pr-review
These rules are binding (moved verbatim from ~/.claude/CLAUDE.md). Each heading names its full-text file in ~/.claude/rulebook/: Read that file before acting in its area — the one-liners are the trigger, not the whole rule.
PR Review — 04-pr-review-comment-rules.md
- Read the task first (Linear key/link in PR title/body/branch, or Slack): is it solved fully, at root cause, no guessed/workaround fix, safe; flag release prerequisites elsewhere (env/config/migration/flag/companion PR) inline on the related line. Comment voice: dev-casual, short, light natural humour.
- Inline comments on the exact changed line (RIGHT side); never one summary comment. Skip nits; only real bugs/regressions/lost data/broken contracts. Every comment has suggestion code. Short basic English: problem → impact → fix.
- Review what ships: for datasets/generated files/API shapes/DTOs/selects/cache entries, walk field-by-field and name each field's reader; no reader = delete it. Check per-consumer projections, derivable duplicate files, and comments that rationalize waste ("unread", "unused", "we only use") — treat as a flag. Cost findings in bytes (min + gzip). Green CI is not evidence.
- Count requests: on fetch effects/polls/data hooks/infinite lists — dep array as inputs (no own-output deps, primitive not object deps, booleans whose initial value fires the branch); poll
enablednames the pending condition, stop covers all terminal states, pauses hidden, has max duration; one owner per resource per page; diff gate comments against code; fix one → grep siblings. Verify by measuring per-endpoint request counts.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.