codeflash-admin/codeflash-internal
1
0
Fork 0
mirror of https://github.com/codeflash-ai/codeflash-internal.git synced 2026-05-04 18:25:18 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
codeflash-internal/CLAUDE.md
Kevin Turcios 3ac7eb5982
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 01:03:12 -05:00

879 B
Raw Blame History

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