Prototype WIP - Add prefetch support for reverse scan

[jaykorean]

Summary

Enable RocksDB block prefetching for reverse iteration (Prev / SeekForPrev / SeekToLast) to achieve parity with existing forward scan prefetch. Currently BlockPrefetcher and FilePrefetchBuffer assume monotonic increasing file offsets, so reverse scans get zero prefetch benefit even with explicit readahead_size or implicit auto-readahead enabled.

This PR adds direction-aware prefetch through the full iterator stack, fixes useful-bytes accounting for backward direction, and adds unit test coverage for reverse path. Bench harness updated locally for T3 evaluation.

Motivation

Forward scan today has three prefetch modes — explicit user readahead_size, implicit auto-readahead after 2 sequential reads with exponential growth, and compaction readahead — all gated by forward sequential detection prev_offset+prev_len == offset. Reverse workloads doing SeekToLast + Prev or SeekForPrev see none of this today.

Typical secondary index reverse lookup pattern targeted: 10KB average value size, 5–20 keys per scan, with and without prefetch comparison needed to quantify uplift on T3 NVMe hosts.

Design

No public API change. Internal direction enum added with default forward preserving existing behavior.

New types – file/file_prefetch_buffer.h

• enum class PrefetchDirection { kForward, kBackward }
• ReadaheadParams.direction defaults to forward for backward compat
• BufferInfo extended with IsBufferOutdatedBackward(offset,len) and IsBufferOutdatedBackwardWithAsyncProgress for symmetry with existing forward outdated checks

FilePrefetchBuffer – file/file_prefetch_buffer.h/.cc

• Add direction_ member initialized from ReadaheadParams, plumbed through constructor.
• ClearOutdatedData(offset,length) now branches on direction: forward frees front buffer when offset >= buf_end; backward frees front buffer when offset+length <= buf_start. With single buffer case this correctly slides window backward; with double-buffer async case overlapping logic updated to check backward alignment next_buf.offset + next_buf.size == buf.offset and abort when request extends before current buffer start.
• AbortOutdatedIO(offset,length) similarly direction-aware using new backward outdated check.
• ReadAheadSizeTuning() fixed to compute correct prefetch range for backward direction:
  • forward: [offset , offset+len+readahead) — unchanged
  • backward: [ max(0, offset-readahead) , offset+len ) — new, mirrors BlockPrefetcher FS prefetch fix
  • prev-buffer-end optimization guarded to forward only; backward skips to avoid incorrect early-return since we lack prev_buf_start tracking in prototype. ClearOutdatedData handles eviction instead.
• UpdateStats() unchanged — now correctly records PREFETCH_BYTES_USEFUL and PREFETCH_HITS on backward cache hits because TryReadFromCache no longer returns false spuriously due to wrong range calculation. Previously useful was always 0 on reverse path; after fix useful >0 on hits.

BlockPrefetcher – table/block_based/block_prefetcher.h/.cc

• PrefetchIfNeeded(..., PrefetchDirection direction = kForward) new signature default preserves backward compat for existing callers.
• IsBlockSequential(offset,len,direction) overload added checking both forward prev_offset+prev_len==offset and backward offset+len==prev_offset.
• Track prefetch_start_ lower bound alongside existing readahead_limit_ upper bound for FS prefetch range checks.
• FS prefetch path computes backward range same as FilePrefetchBuffer fix above, calls rep->file->Prefetch(start, len) then updates prefetch_start_ and readahead_limit_.
• Explicit readahead_size path and implicit auto path both pass direction through to FilePrefetchBuffer via ReadaheadParams.

BlockBasedTableIterator – table/block_based/block_based_table_iterator.h/.cc

• InitDataBlock(PrefetchDirection) and AsyncInitDataBlock(..., direction) updated with default forward.
• Prev path, SeekForPrev, SeekToLast, FindKeyBackward now pass kBackward; Next path, Seek, SeekToFirst, FindKeyForward use default forward.
• readahead_cache_lookup callback disabled for backward direction in prototype — forward continues to use BlockCacheLookupForReadAheadSize walking index forward for trimming; backward trimming left as follow-up to keep prototype focused. Means useful ratio on reverse may still lag forward until backward trim walk via Prev() is implemented.

Compaction path unchanged — compaction iterator always forward, no behavior change.

Files Changed

• file/file_prefetch_buffer.h – PrefetchDirection enum, ReadaheadParams.direction, BufferInfo backward outdated methods, FilePrefetchBuffer direction member, UpdateStats unchanged but now triggered correctly for backward
• file/file_prefetch_buffer.cc – direction-aware ClearOutdatedData, AbortOutdatedIO, ReadAheadSizeTuning backward range calculation, prev_buf logic guarded to forward only
• table/block_based/block_prefetcher.h – PrefetchIfNeeded signature, IsBlockSequential overload, prefetch_start_ member, ResetValues updated
• table/block_based/block_prefetcher.cc – backward sequential detection, backward FS prefetch range, direction plumbing to ReadaheadParams
• table/block_based/block_based_table_iterator.h – InitDataBlock signature update
• table/block_based/block_based_table_iterator.cc – plumb direction from Prev/SeekForPrev/SeekToLast, disable cache lookup callback for backward, pass direction to prefetcher
• table/table_test.cc – new TEST_P ReversePrefetchTest covering explicit readahead and implicit auto on reverse path

Test Plan

• Unit tests passing locally on devvm:

  • make table_test && ./table_test --gtest_filter="*Prefetch*" — 146 passed (74 existing forward PrefetchTest + 72 new ReversePrefetchTest across format versions)
  • make table_test && ./table_test --gtest_filter="*ReversePrefetch*" — 72 passed
  • make prefetch_test && ./prefetch_test — 110 passed unchanged
  • New test asserts for reverse path:
    • SeekToLast with explicit readahead_size creates FilePrefetchBuffer immediately (no sequential gate needed)
    • Buffer size >0 and at least one block
    • PREFETCH_BYTES ticker >0 after SeekToLast (was 0 before prototype)
    • After walking 5 Prev steps, PREFETCH_BYTES_USEFUL >0 (was 0 before useful-counter fix, now passes)
    • Implicit auto test after 3 sequential Prev calls verifies prefetch buffer eventually created via backward sequential detection

• Bench harness local devvm run with prototype binary (devvm33065, not T3 yet, for functionality verification):

  • DB: 1M keys, 10KB values ~10GB, 1GB block cache, 16KB blocks, 64MB sst, 6 levels
  • Command used for quick verification:

    ./db_bench --benchmarks=fillseq --db=/tmp/rdb_test --num=50000 --value_size=10240 ...
    ./db_bench --benchmarks=readreverse,stats --db=/tmp/rdb_test --use_existing_db=true --readonly --statistics --readahead_size=65536 ...
    

  • Before useful-counter fix: reverse readreverse showed prefetch.bytes 63GB useful 0 hits 0 — prefetch firing but wasted.
  • After useful-counter fix: reverse readreverse shows prefetch.bytes 442KB useful 375KB hits 66 on small 50k key test — ~85% useful ratio, on par with forward path mechanism now working correctly at table layer. Forward readseq comparison on same DB shows 304k ops/sec vs reverse 192k ops/sec with same readahead — reverse still slower overall due to inherent reverse iteration overhead, but useful ratio now healthy.

Follow-ups before Ready for Review -> Ready

• Add DB-level reverse test to file/prefetch_test.cc similar to existing PrefetchTest.Basic but using SeekToLast Prev loop asserting fs prefetch called and prefetch bytes >0 — table_test covers table layer already, DB test would add end-to-end coverage through DB iterator merging logic.
• Consider new ticker or tag to separate reverse prefetch bytes from forward for observability, or keep reuse of existing tickers for simplicity — open for reviewer feedback.

Testing Done Checklist

• Unit test added: table/table_test.cc ReversePrefetchTest 72 parameterized sub-tests passing
• Existing prefetch tests passing: table_test prefetch 74 passed, prefetch_test 110 passed
• Useful counter fix verified locally via db_bench readreverse showing prefetch.bytes useful >0 and prefetch.hits >0 where previously 0

[github-actions]

⚠️ clang-tidy: 2 warning(s) on changed lines

Completed in 386.6s.

Summary by check

Check	Count
clang-analyzer-deadcode.DeadStores	1
modernize-make-shared	1
Total	2

Details

table/block_based/block_prefetcher.cc (1 warning(s))

table/block_based/block_prefetcher.cc:119:5: warning: Value stored to 'in_prefetch_range' is never read [clang-analyzer-deadcode.DeadStores]

table/table_test.cc (1 warning(s))

table/table_test.cc:3397:25: warning: use std::make_shared instead [modernize-make-shared]

[github-actions]

Codex Code Review - OBSOLETE

Superseded by a newer AI review. Expand to see the original review.

🟡 Codex Code Review

Auto-triggered after CI passed — reviewing commit 4b45dca

---

❌ Codex review failed before producing findings.

WARNING: proceeding, even though we could not create PATH aliases: Refusing to create helper binaries under temporary dir "/tmp" (codex_home: AbsolutePathBuf("/tmp/codex-home"))
error: the argument '--base <BRANCH>' cannot be used with '[PROMPT]'

Usage: codex exec review --commit <SHA> --base <BRANCH> --title <TITLE> --model <MODEL> --config <key=value> --dangerously-bypass-approvals-and-sandbox --output-last-message <FILE> [PROMPT]

For more information, try '--help'.

---

ℹ️ About this response

Generated by Codex CLI.
Review methodology: claude_md/code_review.md

Limitations:

• Codex may miss context from files not in the diff
• Large PRs may be truncated
• Always apply human judgment to AI suggestions

Commands:

• /codex-review [context] — Request a code review
• /codex-query <question> — Ask about the PR or codebase

[github-actions]

Claude Code Review - OBSOLETE

Superseded by a newer AI review. Expand to see the original review.

✅ Claude Code Review

Auto-triggered after CI passed — reviewing commit 4b45dca

---

Summary

This WIP prototype plumbs a PrefetchDirection through BlockBasedTableIterator, BlockPrefetcher, and FilePrefetchBuffer to enable backward prefetching for reverse scans. The direction signal is correctly propagated at the iterator level, but the core prefetch engine (FilePrefetchBuffer) remains entirely forward-oriented, making backward prefetching non-functional end-to-end. There are also several logic bugs in the BlockPrefetcher backward path.

High-severity findings (3):

• [block_prefetcher.cc:117-129] in_prefetch_range backward logic triple-overwrites itself; final value ignores upper-bound check, causing missed prefetches or spurious cache hits.
• [file_prefetch_buffer.cc:836] TryReadFromCacheUntracked rejects any offset < buf->offset_, making backward reads from the prefetch buffer impossible.
• [file_prefetch_buffer.cc:620-784] PrefetchInternal always prefetches forward (offset + length + readahead), so even when the direction is kBackward, data ahead of the read position is fetched instead of data behind it.

Full review (click to expand)

Findings

🔴 HIGH

H1. in_prefetch_range backward logic is broken -- block_prefetcher.cc:117-129

• Issue: The backward branch computes in_prefetch_range three times, each overwriting the previous value:

  // First computation (lines 121-122):
  in_prefetch_range = (prefetch_start_ != 0 && offset >= prefetch_start_ &&
                       offset + len <= readahead_limit_);
  // Second computation (lines 125-126) -- overwrites first:
  if (prefetch_start_ != 0) {
    in_prefetch_range = (offset >= prefetch_start_);
  } else {
    in_prefetch_range = false;
  }

  The final value is just offset >= prefetch_start_ when prefetch_start_ != 0, which drops the upper-bound check (offset + len <= readahead_limit_). This means a block well beyond readahead_limit_ could be falsely considered "in prefetch range," causing the function to return early without issuing a needed prefetch.
• Root cause: Appears to be debug/iteration code left in place -- the comment says "Alternative simple check" suggesting experimentation.
• Suggested fix: Remove the redundant re-computation. Use a single expression:

  in_prefetch_range = (prefetch_start_ != 0 && offset >= prefetch_start_ &&
                       offset + len <= readahead_limit_);

H2. TryReadFromCacheUntracked blocks backward reads -- file_prefetch_buffer.cc:836

• Issue: Line 836 has a hard check:

  if (!explicit_prefetch_submitted_ && offset < buf->offset_) {
    return false;
  }

  For backward iteration, the requested offset will frequently be LESS than the buffer's offset (we're reading blocks at lower file offsets). This check causes TryReadFromCache to always return false for backward reads, meaning data will never be served from the prefetch buffer even if it were correctly populated.
• Root cause: The entire TryReadFromCacheUntracked function was designed for forward-only access.
• Suggested fix: Gate this check on direction:

  if (!explicit_prefetch_submitted_ && direction_ == PrefetchDirection::kForward && offset < buf->offset_) {
    return false;
  }

  Additionally, for backward direction, the buffer lookup logic needs to find the buffer containing the requested offset rather than assuming the front buffer.

H3. PrefetchInternal always prefetches forward -- file_prefetch_buffer.cc:620-784

• Issue: The entire PrefetchInternal function calculates prefetch ranges as offset + length + readahead_size (forward). For backward iteration, it should prefetch data BEFORE the current offset. Key forward assumptions:
  • ReadAheadSizeTuning computes end_offset = Roundup(start_offset + length + readahead_size, alignment) (line 420) -- always extends forward
  • PrefetchRemBuffers chains buffers forward using initial_end_offset_ (line 1086)
  • HandleOverlappingAsyncData assumes forward overlap (line 554: offset + length > next_buf->offset_)
  • Buffer ordering in bufs_ deque is implicitly front=oldest/lowest offset
• Root cause: FilePrefetchBuffer was architecturally designed for forward sequential access. Adding a direction_ member and modifying only AbortOutdatedIO/ClearOutdatedData is insufficient -- the core read/prefetch pipeline needs fundamental changes.
• Suggested fix: This requires significant additional work. The PrefetchInternal function needs a backward code path that:
  1. Calculates prefetch range as [offset - readahead_size, offset + length]
  2. Orders buffers in decreasing offset order (or reverses the deque semantics)
  3. Handles overlap in the backward direction

🟡 MEDIUM

M1. IsBufferOutdatedBackward semantics are correct but confusing -- file_prefetch_buffer.h:134-137

• Issue: The backward outdated check offset + length <= offset_ is mathematically correct (a buffer whose start is beyond the current read range is "outdated" in the backward sense), but the naming and semantics are inverted from the forward case in a way that makes the code hard to reason about.

M2. IsBufferOutdatedBackwardWithAsyncProgress drops async_req_len check -- file_prefetch_buffer.h:140-144

• Issue: The forward version checks against offset_ + async_req_len_ (the full range of the in-progress read), but the backward version only checks against offset_. The async read could extend the buffer's effective range, and this isn't accounted for.
• Suggested fix: Determine whether the async read extends the range in a direction-relevant way.

M3. ClearOutdatedData backward alignment check is simplistic -- file_prefetch_buffer.cc:352-366

• Issue: The backward two-buffer alignment check next_buf->offset_ + next_buf->CurrentSize() != buf->offset_ assumes buffers should be contiguous in reverse order, but the overall deque ordering hasn't been changed to support this.

M4. MaterializeCurrentBlock missing direction -- block_based_table_iterator.cc:586

• Issue: MaterializeCurrentBlock() calls InitDataBlock() without direction, defaulting to kForward. This is called from PrepareValue() which can be invoked during backward iteration.
• Suggested fix: Store iteration direction as member state or pass through.

M5. DecreaseReadAheadIfEligible uses forward-only IsBlockSequential -- file_prefetch_buffer.h:387-389

• Issue: Always returns false for backward reads, preventing readahead tuning. Not harmful but indicates incomplete backward support.

M6. Backward FS prefetch length may be very large near file start -- block_prefetcher.cc:172-177

• Issue: When start = 0 due to underflow guard, prefetch_len = curr_offset + BlockSizeWithTrailer(handle) which could be large. Low risk since OS handles it.

🟢 LOW / NIT

L1. Old IsBlockSequential(const uint64_t&) retained alongside new overload -- block_prefetcher.h:34-36

• Issue: Two overloads with subtly different semantics is error-prone. Consider unifying.

L2. WIP implementation comments in production code -- block_prefetcher.cc:119-121

• Issue: Comments like "Alternative simple check" are iteration notes, not documentation.

L3. FilePrefetchBufferUsage enum moved without functional reason -- file_prefetch_buffer.h

• Issue: Unnecessary diff noise.

L4. No tests for backward prefetching

• Issue: No unit or integration tests for any of the new backward paths.

Cross-Component Analysis

Context	Does code execute?	Assumptions hold?	Action needed?
Compaction	NO	YES	Always forward; correctly commented
PartitionedIndexIterator	YES	NO	Not updated for direction
Async IO	YES	NO	Direction passed but not used for actual prefetch
ReadaheadCacheLookup	YES	YES	Correctly disabled for backward
WritePreparedTxnDB	NO	N/A	Not affected
ReadOnly DB	NO	N/A	Not affected

Positive Observations

• The approach of threading PrefetchDirection through the call chain is architecturally sound.
• Correctly disabling readaheadsize_cb for backward direction is a good catch.
• The IsBlockSequential backward overload (offset + len == prev_offset_) is correct.
• The PR correctly identifies that compaction is always forward.

---

ℹ️ About this response

Generated by Claude Code.
Review methodology: claude_md/code_review.md

Limitations:

• Claude may miss context from files not in the diff
• Large PRs may be truncated
• Always apply human judgment to AI suggestions

Commands:

• /claude-review [context] — Request a code review
• /claude-query <question> — Ask about the PR or codebase

[github-actions]

🟡 Codex Code Review

Auto-triggered after CI passed — reviewing commit db12909

---

❌ Codex review failed before producing findings.

WARNING: proceeding, even though we could not create PATH aliases: Refusing to create helper binaries under temporary dir "/tmp" (codex_home: AbsolutePathBuf("/tmp/codex-home"))
error: the argument '--base <BRANCH>' cannot be used with '[PROMPT]'

Usage: codex exec review --commit <SHA> --base <BRANCH> --title <TITLE> --model <MODEL> --config <key=value> --dangerously-bypass-approvals-and-sandbox --output-last-message <FILE> [PROMPT]

For more information, try '--help'.

---

ℹ️ About this response

Generated by Codex CLI.
Review methodology: claude_md/code_review.md

Limitations:

• Codex may miss context from files not in the diff
• Large PRs may be truncated
• Always apply human judgment to AI suggestions

Commands:

• /codex-review [context] — Request a code review
• /codex-query <question> — Ask about the PR or codebase

[jaykorean]

/claude-review

[github-actions]

✅ Claude Code Review

Auto-triggered after CI passed — reviewing commit db12909

---

Summary

Prototype adds direction-aware prefetching for reverse scans through BlockBasedTableIterator -> BlockPrefetcher -> FilePrefetchBuffer. The design approach is sound, but there are several correctness bugs and dead code issues that need addressing before this can land.

High-severity findings (3):

• [block_prefetcher.cc:120-133] in_prefetch_range backward logic is self-contradictory: computes a value then immediately overwrites it, and uses prefetch_start_ != 0 which fails when prefetch starts at file offset 0.
• [file_prefetch_buffer.h:453-455] FilePrefetchBuffer::IsBlockSequential (private) is NOT updated for backward direction, causing implicit auto-readahead to always reset on backward scans.
• [file_prefetch_buffer.cc:836] TryReadFromCacheUntracked returns false when offset < buf->offset_, but backward prefetch may hit stale forward buffer state that isn't properly cleared by backward-aware ClearOutdatedData.

Full review (click to expand)

Findings

🔴 HIGH

H1. Self-contradictory in_prefetch_range logic — block_prefetcher.cc:120-133

• Issue: The backward in_prefetch_range check computes a value with a compound condition, then immediately overwrites it with a simpler check, discarding the first computation. Additionally, prefetch_start_ != 0 is used as sentinel for "not set", but offset 0 is a valid file offset.
• Root cause: Two competing implementations left from incomplete refactoring. Classic "zero means uninitialized" anti-pattern.
• Suggested fix: Remove redundant first computation. Use std::optional<uint64_t> or a bool prefetch_start_set_ flag instead of 0 as sentinel.

H2. FilePrefetchBuffer::IsBlockSequential not direction-aware — file_prefetch_buffer.h:453-455

• Issue: The private IsBlockSequential only checks forward adjacency. Called by IsEligibleForPrefetch() and DecreaseReadAheadIfEligible(), it will always fail for backward scans, resetting readahead every time. This makes implicit auto-readahead non-functional for backward scans.
• Root cause: BlockPrefetcher::IsBlockSequential was updated but FilePrefetchBuffer::IsBlockSequential was not.
• Suggested fix: Add direction-awareness to FilePrefetchBuffer::IsBlockSequential.

H3. Stale forward buffer may reject backward requests — file_prefetch_buffer.cc:836

• Issue: TryReadFromCacheUntracked returns false when offset < buf->offset_. Backward ClearOutdatedData frees buffers where offset + length <= buf_start, but a stale forward buffer with high offset won't be detected as "outdated" if offset + length > buf_start.
• Suggested fix: Clear all buffers on direction change.

🟡 MEDIUM

M1. ~100 lines of dead code in backward cache lookup — block_based_table_iterator.cc:800-990

• Issue: Backward-direction handling in InitializeStartAndEndOffsets and BlockCacheLookupForReadAheadSize is unreachable since readahead_cache_lookup_ is only true for forward.
• Suggested fix: Remove until backward cache lookup is enabled.

M2. HandleOverlappingAsyncData not direction-aware — file_prefetch_buffer.cc:620-784

• Issue: Forward-only overlap detection with num_buffers_ > 1. Currently safe because backward uses num_buffers_ == 1, but no assertion guards this.
• Suggested fix: Add assert(direction_ == PrefetchDirection::kForward || num_buffers_ == 1).

M3. Two separate direction enums — file_prefetch_buffer.h / block_based_table_iterator.h

• Issue: PrefetchDirection and IterDirection serve the same purpose with no compile-time sync guarantee.
• Suggested fix: Unify or add conversion function.

M4. DecreaseReadAheadIfEligible forward-only — file_prefetch_buffer.h:386-394

• Issue: Same root cause as H2 — calls forward-only IsBlockSequential.

M5. Test assertions are tautologies — table_test.cc (diff)

• Issue: ASSERT_GE(prefetch_bytes_useful, 0) always passes for uint64_t. ASSERT_GE(prefetch_bytes, 0) in implicit test also always passes.
• Suggested fix: Use ASSERT_GT where behavior is expected to produce >0 values.

🟢 LOW / NIT

L1. WIP comments left in code — block_prefetcher.cc:113-133

L2. prefetch_start_ sentinel reset needs revisiting with H1 fix — block_prefetcher.h:59

L3. New BufferInfo methods missing const — file_prefetch_buffer.h:134

L4. PartitionedIndexIterator uses default forward direction — correct but worth noting

Cross-Component Analysis

Context	Executes?	Safe?	Action?
WritePreparedTxnDB	YES	YES	None
ReadOnly DB	YES	YES	None
Compaction	NO	N/A	Correctly excluded
Async IO (num_buffers>1)	PARTIALLY	NO	M2
Direct IO	YES	UNCERTAIN	Untested
FS prefetch	YES	PARTIAL	H1

Positive Observations

• Clean design threading direction through ReadaheadParams
• Backward IsBlockSequential overload in BlockPrefetcher is correct
• Backward range calculation in ReadAheadSizeTuning handles underflow properly
• Compaction path correctly unchanged
• IsPrevBlockOutOfReadaheadBound correctly mirrors forward version

---

ℹ️ About this response

Generated by Claude Code.
Review methodology: claude_md/code_review.md

Limitations:

• Claude may miss context from files not in the diff
• Large PRs may be truncated
• Always apply human judgment to AI suggestions

Commands:

• /claude-review [context] — Request a code review
• /claude-query <question> — Ask about the PR or codebase

[github-actions]

✅ Claude Code Review

Requested by @jaykorean

---

Summary

Prototype WIP adding backward prefetch for reverse iteration. The approach is sound -- plumbing PrefetchDirection through the iterator/prefetcher/buffer stack -- but the implementation has a critical logic error in BlockPrefetcher backward range checking, async IO incompatibility, and several correctness concerns in the multi-buffer path.

High-severity findings (2):

• [block_prefetcher.cc:120-133] Backward in_prefetch_range logic is self-contradictory: second block overwrites first, dropping the offset + len <= readahead_limit_ upper bound check, so blocks beyond the prefetched window are incorrectly treated as hits and skipped without prefetch.
• [file_prefetch_buffer.cc + block_prefetcher.cc] Async IO (num_buffers_ > 1) with backward direction uses forward-only buffer ordering assumptions in PrefetchRemBuffers, HandleOverlappingAsyncData, and related code, likely causing incorrect prefetch ranges or crashes.

The full review with 4 MEDIUM and 5 LOW findings is written to review-findings.md.

---

ℹ️ About this response

Generated by Claude Code.
Review methodology: claude_md/code_review.md

Limitations:

• Claude may miss context from files not in the diff
• Large PRs may be truncated
• Always apply human judgment to AI suggestions

Commands:

• /claude-review [context] — Request a code review
• /claude-query <question> — Ask about the PR or codebase