Memory Optimization Patch Review

A rigorous 5-persona peer review system for memory optimization patches. Requires unanimous approval backed by concrete benchmark data. Duplicate Hunter persona prevents redundant work.

CRITICAL: Recording is MANDATORY

EVERY review outcome MUST be recorded in reviews.yaml.

Valuable Outcomes

Finding bugs during optimization review is SUCCESS, not failure.

Phase 0: Pre-flight

Run /preflight first. Then check for duplicate work:

cat ~/.claude/skills/review-optimization/reviews.yaml
cat ~/.claude/skills/hunt-optimization/hunts.yaml

Check for:

• •Same branch name already reviewed → REJECT as "DUPLICATE"
• •Same file + technique already approved → REJECT as "DUPLICATE"

Phase 1: Measurement

# Baseline
git checkout origin/main
go test -bench=<Name> -benchmem -count=10 ./pkg/... > /tmp/old.txt

# Optimized
git checkout -
go test -bench=<Name> -benchmem -count=10 ./pkg/... > /tmp/new.txt

# Compare
benchstat /tmp/old.txt /tmp/new.txt

Statistical Requirements

• •Minimum 10 runs (-count=10)
• •P-value < 0.05 for significance
• •B/op improvement >= 5%

NO EXCEPTIONS

If benchstat output is missing → REJECT. Period.

• •"Test dependencies don't work" → REJECT. Fix deps first.
• •"Theoretically better" → REJECT. Prove it with numbers.
• •"Obviously an improvement" → REJECT. Obvious is not measured.
• •"Will benchmark later" → REJECT. Benchmark now.

The only path to APPROVE for optimizations is benchstat showing p<0.05 and >=5% improvement.

Phase 2: Five-Persona Review

Duplicate Hunter (Checks for Redundant Work)

• • Branch not already in reviews.yaml
• • File + technique combo not already approved
• • No substantially similar optimization exists
• • If duplicate found → REJECT with "DUPLICATE: see <existing branch>"

Skeptic (Demands Proof)

• • Hot path verified (>1000 calls/sec or top 10% profile)
• • Benchmark improvement >5% with p<0.05
• • Statistical significance confirmed

Conservative (Guards Correctness)

• • All tests pass
• • No semantic changes
• • No bugs introduced (if bug found → /validate-correctness)

Go Expert (Compiler Knowledge)

• • Escape analysis checked
• • No new heap escapes

Greybeard (Simplicity)

• • Code still readable
• • Complexity justified by improvement

Phase 3: Decision

When Bug Is Found

If review discovers a bug instead of an optimization:

/validate-correctness

The validate-correctness skill will:

1. •Create a test that reproduces the bug
2. •Verify the fix works
3. •Record in validations.yaml

Then return here to record the finding as a SUCCESS (bug found).

Phase 4: MANDATORY Recording

# Append to reviews.yaml
  - branch: <name>
    date: YYYY-MM-DD
    verdict: APPROVE|REJECT|BUG_FOUND
    reason: "<summary>"
    lesson: "<pattern>"
    validated_by: "/validate-correctness"  # if bug

Usage

/review-optimization