[Feature Request] Allow deferring a code review fix to a new issue #266
Description
When a code review surfaces a problem, the current workflow assumes the fix belongs in the same PR. But sometimes the finding deserves its own worktree and PR rather than being stuffed into the current one.
Common reasons to defer:
- Out of scope for the current PR
- Needs a design decision or discussion before fixing
- Fix has risk and needs its own test cycle
- Systemic - needs a broader codebase scan
Proposed behavior
During code review, allow the user to defer a specific finding by creating a GitHub issue instead of fixing. The issue should capture:
- The review finding (what's wrong and why)
- Affected locations (files/patterns identified during review)
- Why it was deferred (out of scope, needs discussion, needs testing, needs broader codebase scan, etc)
- Suggested fix approach
Why this matters
- Keeps PRs focused, a review fix that touches 15 files across 4 modules shouldn't bloat an unrelated PR
- Prevents scope creep during review cycles
- Creates a trackable record so deferred fixes don't get lost
- Aligns with worktree-based workflows where each concern gets its own isolated branch
Nice-To-Haves
- Auto-link the issue back to the source PR and leave a deferral comment on the PR
- Auto-label deferred issues (e.g.
code-review,deferred) for filtering - Severity hints ("fix before next release" vs "tech debt backlog")