codeflash-internal/CLAUDE.md

39 lines
1.3 KiB
Markdown
Raw Normal View History

improve continuous review (#2271) - Re-enable synchronize trigger for automatic re-reviews on each push - Add logic to detect and resolve fixed issues automatically - Focus reviews only on critical bugs, security, breaking changes, test failures - Limit to 5-7 high-signal comments per review - Review only changed files on re-reviews (incremental approach) - Add detailed PR review guidelines in CLAUDE.md - Increase fetch-depth to 2 for commit comparison This reduces review noise while maintaining continuous quality checks. # Pull Request Checklist ## Description - [ ] **Description of PR**: Clear and concise description of what this PR accomplishes - [ ] **Breaking Changes**: Document any breaking changes (if applicable) - [ ] **Related Issues**: Link to any related issues or tickets ## Testing - [ ] **Test cases Attached**: All relevant test cases have been added/updated - [ ] **Manual Testing**: Manual testing completed for the changes ## Monitoring & Debugging - [ ] **Logging in place**: Appropriate logging has been added for debugging user issues - [ ] **Sentry will be able to catch errors**: Error handling ensures Sentry can capture and report errors - [ ] **Avoid Dev based/Prisma logging**: No development-only or Prisma-specific logging in production code ## Configuration - [ ] **Env variables newly added**: Any new environment variables are documented in .env.example file or mentioned in description --- ## Additional Notes <!-- Add any additional context, screenshots, or notes for reviewers here -->
2026-01-23 06:03:12 +00:00
# Claude Code Instructions
@AGENTS.md
## PR Review Guidelines
When reviewing PRs, follow these priorities:
### CRITICAL - Always comment:
- Logic errors or bugs that will cause failures
- Security vulnerabilities
- Test method names with typos (won't be discovered by test runner)
- Breaking changes without migration path
### SKIP - Don't comment on:
- Code style or formatting (we have linters for this)
- Suggestions for additional features or refactoring
- "Consider" or "might want to" suggestions
- Performance optimizations without profiling data
- Duplicate concerns (one comment per issue)
### Process:
1. Check if previous comments on same lines are now fixed - resolve those first
2. Limit to 5-7 high-signal comments per review
3. Group related issues into one comment when possible
4. If many issues exist, use a summary comment instead of 20+ inline comments
## Formatting & Linting (prek)
When asked to fix formatting, linting, or pre-commit issues (e.g., "fix prek", "fix formatting", "run pre-k"):
1. Run `uv run prek run --all-files` to auto-fix formatting issues
2. If prek modifies files, stage them with `git add .`
3. Commit with message: `fix: auto-format with prek`
4. Push the changes with `git push`
5. Comment on the PR confirming what was fixed
Do NOT just review the code - actually run prek and push the fixes!