interactive-code-review_skill

Overview

This skill runs a human-in-the-loop, chunked code review that walks changes forward only after an explicit approve/reject/chat decision. It surfaces author intent, breaks diffs into manageable hunks, and enforces a structured loop to find defects, clarify intent, and propose concrete fixes before moving on.

How this skill works

You point the skill at a diff, PR, patch, or document and it gathers context (branch range, diff stats, file list). It splits changes into 40–120 line chunks (file-by-file, then hunk-by-hunk), presents each chunk with a short summary and the diff snippet, and pauses for one of six actions: approve, reject, chat, skip, jump, or done. Rejections require an explicit issue explanation and a proposed concrete edit; chat requests provide more context and can loop until a decision is made.

When to use it

• Reviewing pull requests or large diffs interactively with a reviewer-in-the-loop.
• Walking through patches with the author to surface intent and hidden risks.
• Reviewing documentation or prose by logical sections or headings.
• Performing risk-focused reviews (security, correctness, breaking changes).
• Running a guided 'production readiness' deep review with categorized findings.

Best practices

• Confirm review target and success criteria up front (correctness, style, performance, risk).
• Limit chunks to ~40–120 lines and order by module boundaries, public interfaces first.
• Ask clarifying questions before asserting or proposing edits; verify before changing files.
• Reject with: the issue, why it matters, and a concrete fix suggestion.
• Use skip/jump for large reviews; split sessions by directory if >20 files or 2000 lines.

Example use cases

• Step through a feature branch PR, approving safe hunks and rejecting risky ones with proposed patches.
• Conduct a security-focused pass that flags injection, auth, or data-leak risks at module boundaries.
• Walk through documentation changes section-by-section to confirm clarity and intent.
• Run a deep 'production readiness' assessment producing prioritized critical/important/minor findings.
• Triage a large refactor by skipping bulk formatting-only hunks and focusing on public API changes.