skill-code-review

# Code Review Skill

## MANDATORY COMPLIANCE — DO NOT SKIP

**When this skill is invoked, you MUST execute the multi-LLM review pipeline. You are PROHIBITED from:**
- Doing a direct single-model code review without multi-provider synthesis
- Deciding the scope is "too broad" and narrowing it without asking the user
- Skipping the provider check or structured review phases
- Substituting two background Sonnet agents for the full multi-provider pipeline
- Rationalizing "a focused audit would be more effective" — the user wants multi-LLM perspectives

---

**Your first output line MUST be:** `🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-LLM Code Review`

Invokes the code-reviewer persona for thorough code analysis during the `ink` (deliver) phase.

## Quick Mode

For fast sanity checks (staged changes, small PRs), skip the full review pipeline and run just two phases:

```bash
# Quick: grasp (consensus on scope) → tangle (parallel review)
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh grasp "[review request]"
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh tangle "[synthesized scope]"
```

Use quick mode when user says "check this PR", "quick review", "sanity check my changes", or for pre-commit checks. Use the full review for PRs with security/architecture impact.

## Usage

```bash
# Via orchestrate.sh
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh spawn code-reviewer "Review this pull request for security issues"

# Via auto-routing (detects review intent)
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh auto "review the authentication implementation"
```

## Capabilities

- AI-powered code quality analysis
- Security vulnerability detection
- Performance optimization suggestions
- Architecture and design pattern review
- TDD compliance and test-first evidence review
- Autonomous code generation risk detection
- Best practices enforcement

## Persona Reference

This skill wraps the `code-reviewer` persona defined in:
- `agents/personas/code-reviewer.md`
- CLI: `codex-review`
- Model: `gpt-5.2-codex`
- Phases: `ink`

## Example Prompts

```
"Review this PR for OWASP Top 10 vulnerabilities"
"Analyze the error handling in src/api/"
"Check for memory leaks in the connection pool"
"Review the test coverage for the auth module"
```

---

## Autonomous Implementation Review

When the review context indicates `AI-assisted`, `Autonomous / Dark Factory`, or unclear provenance, raise the rigor bar. Do not treat generated code as trustworthy just because it is polished.

### TDD Evidence

Check for concrete signs that the change followed red-green-refactor rather than test-after implementation:

- Compare the diff and recent history when available to see whether tests were added before or alongside production changes.
- Prefer behavior-defining tests over snapshot-only or mock-heavy tests that merely restate the implementation.
- Verify the production code looks like the minimum needed to satisfy the tests, rather than a speculative abstraction with unused options.
- If evidence is missing, mark TDD compliance as unknown and do not assume TDD happened.

### Autonomous Codegen Risk Patterns

Elevate or add findings when you see patterns common in high-autonomy output:

- Option-heavy APIs or abstractions not justified by tests or current requirements
- Placeholder logic, TODO/FIXME-driven control flow, or dead branches that appear "future ready"
- Mock, fake, or dummy behavior leaking into production paths
- Unwired components, unused helpers, or code that exists without an execution path
- Silent failure handling, broad catch blocks, missing logs, or weak operational visibility
- Missing rollback notes, migration guards, or release-safety checks for risky changes

### Review Output Addendum

Add a short section to the review synthesis when autonomy or TDD is in scope:

```markdown
## TDD / Autonomy Assessment

- Provenance: Human-authored | AI-assisted | Autonomous / Dark Factory | Unknown
- TDD evidence: Confirmed | Partial | Unknown
- Autonomous risk signals: None | Minor | Significant
- Recommendation: Ship | Fix before merge | Re-run with /octo:tdd or tighter supervision
```

---

## Implementation Completeness Verification

After the code-reviewer persona completes, run stub detection to verify implementation completeness.

### Stub Detection Process

**Step 1: Get changed files**

```bash
# Get files changed in the commit/PR
if [ -n "$COMMIT_RANGE" ]; then
    changed_files=$(git diff --name-only "$COMMIT_RANGE")
else
    changed_files=$(git diff --name-only HEAD~1..HEAD)
fi

# Filter for source code files
source_files=$(echo "$changed_files" | grep -E "\.(ts|tsx|js|jsx|py|go)$")
```

**Step 2: Check for stub patterns**

For each changed file, check for common stub indicators:

```bash
for file in $source_files; do
    echo "Checking $file for stubs..."

    # Check 1: Comment-based stubs
    stub_count=$(grep -E "(TODO|FIXME|PLACEHOLDER|XXX)" "$file" 2>/dev/null | wc -l | tr -d ' ')

    if [ "$stub_count" -gt 0 ]; then
        echo "⚠️  WARNING: Found $stub_count stub indicators in $file"
        grep -n -E "(TODO|FIXME|PLACEHOLDER)" "$file" | head -3
    fi

    # Check 2: Empty function bodies
    empty_functions=$(grep -E "function.*\{\s*\}|const.*=>.*\{\s*\}" "$file" 2>/dev/null | wc -l | tr -d ' ')

    if [ "$empty_functions" -gt 0 ]; then
        echo "❌ ERROR: Found $empty_functions empty functions in $file"
        echo "   Empty functions must be implemented before merge"
    fi

    # Check 3: Return null/undefined
    null_returns=$(grep -E "return (null|undefined);" "$file" 2>/dev/null | wc -l | tr -d ' ')

    if [ "$null_returns" -gt 0 ]; then
        echo "⚠️  WARNING: Found $null_returns null/undefined returns in $file"
        echo "   Verify these are intentional, not stubs"
    fi

    # Check 4: Substantive content check
    substantive_lines=$(grep -vE "^\s*(//|/\*|\*|import|export|$)" "$file" 2>/dev/null | wc -l | tr -d ' ')

    if [[ "$file" == *