code-review-llm

LLM Integration Code Review Patterns

Stack-specific rules loaded by dh:code-reviewer when prompt files, model selection logic, or evaluation harness code are detected.

Prompt Hygiene

• System prompt must be separated from user content — mixing them in a single string removes the security boundary
• System prompts must not include user-controlled content unless that content is explicitly sanitized and bounded
• Prompt templates must use structured variable substitution, not string concatenation — f-strings with raw user input are a blocking finding
• Long prompts should be stored in dedicated files, not inline strings — inline multi-line strings are acceptable only below 10 lines

Model Selection

• Model tier must match task complexity — using Opus for tasks that Haiku can handle is a blocking finding (cost regression)
• Using Haiku for tasks requiring multi-step reasoning, architecture decisions, or complex judgment is a blocking finding (quality regression)
• Model selection must be documented with the rationale — model = "haiku" # retrieval only, no reasoning required
• Model names must not be hardcoded as full version strings — use the tier alias (sonnet, haiku, opus) so upgrades require one change

# WRONG: hardcoded version string
model = "claude-haiku-4-5"

# RIGHT: tier alias — version resolved by the client
model = "claude-haiku-latest"
# or better: configurable
model = config.model_tier  # "haiku" | "sonnet" | "opus"

Context Management

• Unbounded context accumulation (appending all messages without a limit) is a blocking finding — long sessions will silently hit context limits and start dropping messages
• Sliding window or summarization strategy must be implemented for conversations expected to exceed ~50 turns
• Token count must be tracked and logged — silent context truncation is harder to debug than explicit overflow handling

Token Economics

• Token count must be estimated before sending requests in batch or high-volume operations — surprise cost overruns from unexpectedly large inputs are preventable
• Fail fast on oversize inputs rather than truncating silently — silent truncation corrupts the task without surfacing an error
• Structured output requests (JSON mode) reduce token waste from freeform formatting — use when parsing responses programmatically