Skip to main content
ClaudeWave
Slash Command97 repo starsupdated 1mo ago

diff-review

The diff-review command analyzes code changes in Solana blockchain projects for security vulnerabilities, code quality issues, and anti-patterns specific to the Solana ecosystem. Use this command when reviewing pull requests or commits involving Solana smart contracts to identify critical issues like missing account validation, unchecked arithmetic operations, hardcoded addresses, and improper PDA bump handling before deployment.

Install in Claude Code
Copy
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/solanabr/solana-ai-kit/HEAD/.claude/commands/diff-review.md -o ~/.claude/commands/diff-review.md
Then start a new Claude Code session; the slash command loads automatically.

diff-review.md

You are reviewing the current branch diff for Solana-specific security issues, code quality problems, and anti-patterns. Output categorized findings with line references and fix suggestions.

## Related Skills

- [ext/solana-dev/skill/references/security.md](../skills/ext/solana-dev/skill/references/security.md) - Vulnerability categories
- [ext/trailofbits/plugins/building-secure-contracts/skills/solana-vulnerability-scanner/](../skills/ext/trailofbits/plugins/building-secure-contracts/skills/solana-vulnerability-scanner/) - Automated scanning

## Step 1: Get the Diff

```bash
# Determine base branch
BASE_BRANCH="main"
if ! git rev-parse --verify "$BASE_BRANCH" >/dev/null 2>&1; then
    BASE_BRANCH="master"
fi

echo "Reviewing diff: $BASE_BRANCH...HEAD"
echo "Branch: $(git branch --show-current)"
echo ""

# Get the full diff
git diff "$BASE_BRANCH"...HEAD

echo ""
echo "Changed files:"
git diff --name-only "$BASE_BRANCH"...HEAD

echo ""
echo "Diff stats:"
git diff --stat "$BASE_BRANCH"...HEAD
```

## Step 2: Check for Critical Issues

Scan the diff for each category. Report with file path, line number, and severity.

### Account Validation

```bash
echo "=== Account Validation Check ==="

# Find Anchor account structs in changed files
CHANGED_RS=$(git diff --name-only "$BASE_BRANCH"...HEAD | grep '\.rs$')

if [ -n "$CHANGED_RS" ]; then
    echo "Checking Rust files for account validation..."

    # Missing owner checks in native programs
    for f in $CHANGED_RS; do
        [ -f "$f" ] || continue
        grep -n "AccountInfo" "$f" | head -20
    done

    # Check for accounts missing constraints in Anchor
    for f in $CHANGED_RS; do
        [ -f "$f" ] || continue
        # Accounts without any constraint attribute
        grep -n "pub.*Account<" "$f" | grep -v "#\[account" | head -20
    done
fi
```

### Arithmetic Safety

```bash
echo ""
echo "=== Arithmetic Safety Check ==="

if [ -n "$CHANGED_RS" ]; then
    for f in $CHANGED_RS; do
        [ -f "$f" ] || continue
        # Unchecked arithmetic operators on likely numeric operations
        grep -n -E '\b\w+\s*[+\-\*]\s*\w+' "$f" | grep -v "checked_" | grep -v "//" | grep -v "test" | head -20
    done
fi
```

### Hardcoded Addresses

```bash
echo ""
echo "=== Hardcoded Address Check ==="

# Look for base58 strings that look like Solana addresses (32-44 chars)
git diff "$BASE_BRANCH"...HEAD | grep -n "^+" | grep -oP '[1-9A-HJ-NP-Za-km-z]{32,44}' | head -20
```

### PDA Bump Storage

```bash
echo ""
echo "=== PDA Bump Check ==="

if [ -n "$CHANGED_RS" ]; then
    for f in $CHANGED_RS; do
        [ -f "$f" ] || continue
        # find_program_address without storing bump
        grep -n "find_program_address" "$f" | head -10

        # Check if bumps are stored in account structs
        grep -n "bump" "$f" | head -10
    done
fi
```

### Token-2022 Awareness

```bash
echo ""
echo "=== Token-2022 Check ==="

if [ -n "$CHANGED_RS" ]; then
    for f in $CHANGED_RS; do
        [ -f "$f" ] || continue
        # Token transfers without transfer hook handling
        grep -n "token::transfer\|transfer_checked" "$f" | head -10
        # Check for Token-2022 program ID awareness
        grep -n "spl_token_2022\|token_2022\|Token2022" "$f" | head -10
    done
fi
```

## Step 3: Check for AI Slop

Detect common AI-generated anti-patterns in the diff.

```bash
echo ""
echo "=== AI Slop Detection ==="

CHANGED_FILES=$(git diff --name-only "$BASE_BRANCH"...HEAD)

for f in $CHANGED_FILES; do
    [ -f "$f" ] || continue

    # Excessive comments (comment-to-code ratio)
    COMMENTS=$(grep -c "^\s*//" "$f" 2>/dev/null || echo 0)
    CODE=$(grep -c "^\s*[^/]" "$f" 2>/dev/null || echo 1)
    if [ "$CODE" -gt 0 ] && [ "$COMMENTS" -gt 0 ]; then
        RATIO=$((COMMENTS * 100 / CODE))
        if [ "$RATIO" -gt 40 ]; then
            echo "WARNING: $f has ${RATIO}% comment ratio (likely over-commented)"
        fi
    fi

    # Redundant try/catch wrapping in TypeScript
    if echo "$f" | grep -qE '\.(ts|tsx)$'; then
        grep -n "try {" "$f" 2>/dev/null | head -5
    fi

    # Verbose error messages that leak implementation details
    grep -n 'console\.error\|println!\|eprintln!\|msg!' "$f" 2>/dev/null | head -5
done
```

## Step 4: Check CU Waste Patterns

```bash
echo ""
echo "=== CU Waste Patterns ==="

if [ -n "$CHANGED_RS" ]; then
    for f in $CHANGED_RS; do
        [ -f "$f" ] || continue

        # Unnecessary msg! calls (CU cost)
        MSG_COUNT=$(grep -c "msg!" "$f" 2>/dev/null || echo 0)
        if [ "$MSG_COUNT" -gt 5 ]; then
            echo "WARNING: $f has $MSG_COUNT msg! calls (each costs ~100 CU)"
        fi

        # find_program_address in instruction handlers (should use stored bumps)
        grep -n "find_program_address" "$f" | grep -v "test\|#\[cfg(test" | head -5

        # Unnecessary clones
        grep -n "\.clone()" "$f" | head -5
    done
fi
```

## Step 5: Generate Report

Compile all findings into a categorized report:

```
=== DIFF REVIEW REPORT ===
Branch: <branch> vs <base>
Files changed: <count>
Lines added/removed: +<added> -<removed>

--- CRITICAL ---
Issues that must be fixed before merge:
- Missing account validations
- Unchecked arithmetic in financial operations
- Missing signer checks

--- WARNING ---
Issues that should be addressed:
- Hardcoded addresses (use constants or config)
- Missing PDA bump storage (CU waste)
- Token-2022 transfer hooks not handled
- High comment-to-code ratio (AI slop)

--- INFO ---
Suggestions for improvement:
- CU optimization opportunities
- Code style improvements
- Test coverage gaps

--- FIX SUGGESTIONS ---
For each finding, provide:
1. File and line number
2. Current code
3. Suggested fix
4. Rationale
```

## Review Checklist

The review should systematically check:

- [ ] **Account validation** - All accounts have owner/signer/constraint checks
- [ ] **Arithmetic safety** - All math uses checked operations
- [ ] **PDA handling** - Bumps stored, canonical bumps used
- [
anchor-engineerSubagent

Anchor framework specialist for rapid Solana program development. Use for building programs with Anchor macros, IDL generation, account validation, and standardized patterns. Prioritizes developer experience while maintaining security.\\n\\nUse when: Building new programs quickly, team projects needing standardization, projects requiring IDL for client generation, or when developer experience is prioritized over maximum CU optimization.

defi-engineerSubagent

DeFi integration specialist for composing with Solana protocols including Jupiter, Drift, Kamino, Raydium, Orca, Meteora, Marginfi, and Sanctum. Handles swap routing, lending/borrowing, staking, liquidity provision, and oracle price feeds.\n\nUse when: Integrating DeFi protocols, building swap interfaces, implementing lending/borrowing, setting up yield strategies, working with Pyth/Switchboard oracles, or composing multi-protocol transactions.

devops-engineerSubagent

CI/CD, infrastructure, and deployment specialist for Solana projects. Handles GitHub Actions, Docker, monitoring, RPC management, and Cloudflare Workers edge deployment.\n\nUse when: Setting up CI/CD pipelines, containerizing Solana validators or programs, configuring monitoring and alerting, managing RPC infrastructure, deploying edge workers, or automating build and deploy workflows.

game-architectSubagent

Senior Solana game architect for game system design, Unity/C# architecture, on-chain game state, player progression, NFT integration, and PlaySolana ecosystem. Use for high-level game design decisions, architecture reviews, and planning complex game systems.\n\nUse when: Designing new Solana games from scratch, planning game state on-chain, Unity project architecture, integrating with PlaySolana/PSG1, or deciding between implementation approaches.

mobile-engineerSubagent

React Native and Expo specialist for building Solana mobile dApps. Handles mobile wallet adapter integration, transaction signing UX, deep linking, and mobile-specific performance optimization.\n\nUse when: Building React Native or Expo mobile apps with Solana integration, implementing mobile wallet adapter flows, setting up deep links for transaction signing, or optimizing mobile dApp performance.

pinocchio-engineerSubagent

CU optimization specialist using Pinocchio framework. Use for performance-critical programs requiring 80-95% CU reduction vs Anchor. Specializes in zero-copy access, manual validation, and minimal binary size.\\n\\nUse when: CU limits are being hit, transaction costs are significant at scale, binary size must be minimized, or maximum throughput is required.

rust-backend-engineerSubagent

Rust backend specialist for building async services that interact with Solana blockchain. Builds APIs, indexing services, and off-chain processing using Axum, Tokio, and modern async patterns.\n\nUse when: Building REST/WebSocket APIs for Solana dApps, implementing transaction indexers, creating webhook services, or any Rust backend that interacts with Solana.

solana-architectSubagent

Senior Solana program architect for system design, account structures, PDA schemes, token economics, and cross-program composability. Use for high-level design decisions, architecture reviews, and planning complex multi-program systems.\n\nUse when: Designing new programs from scratch, planning account structures, optimizing PDA schemes, reviewing architecture for security, or deciding between implementation approaches.