Skip to content

vt-c-recursive-criticism

Self-review pass on generated code before external review. Runs 1-3 focused passes on security, error handling, and edge cases — catching low-hanging fruit before the expensive multi-agent review. Based on OpenSSF research showing ~40% vulnerability reduction with RCI.

Plugin: core-standards
Category: Other
Command: /vt-c-recursive-criticism

Recursive Criticism and Improvement (RCI)

Pre-review self-criticism gate. Runs 1-3 passes on code changes, each focusing on a different concern area. Stops when no new issues are found (convergence) or after 3 passes (hard limit).

When to Use

  • After code generation and testing, before /vt-c-4-review
  • Offered automatically at /vt-c-3-build Step 7 (pre-review ritual)
  • When you want a quick security/quality pre-screen on a specific file

Invocation

/vt-c-recursive-criticism                # Run on full git diff (main..HEAD)
/vt-c-recursive-criticism path/to/file   # Run on specific file

Execution

Step 0: Load Context

  1. Determine scope:
  2. If a file path argument is provided: read that file
  3. If no argument: run git diff main..HEAD to get all changes on the branch

  4. If no diff and no argument: report "No changes to review" and exit

  5. Load critical patterns (if exists): 

    Read: docs/solutions/patterns/critical-patterns.md

  6. Load constitution (if exists): 

    Read: .specify/memory/constitution.md

  7. Display scope: 

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RCI Self-Review
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Scope: {N} files, {M} lines changed
Max passes: 3 (stops at convergence)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Pass 1: Security + Error Handling

Review the code changes with this focus:

  1. Security: SQL/command injection, XSS, hardcoded secrets, missing authentication/authorization checks, insecure defaults
  2. Error handling: Uncaught exceptions, missing null/undefined checks, swallowed errors, missing error logging
  3. Input validation: Missing type checks, unbounded inputs, format validation gaps

For each issue found, record: - Severity: CRITICAL / HIGH / MEDIUM / LOW - Category: security / error-handling / input-validation - Location: file path and line number (or line range) - Issue: one-line description - Fix: suggested code change or approach

After Pass 1: - Count findings by severity - If 0 findings: report "Pass 1: No issues found. Code looks clean." → skip to Step 4 - If findings exist: display summary and proceed to Pass 2

Pass 1 — Security + Error Handling: {N} findings
  {X} HIGH, {Y} MEDIUM, {Z} LOW

Pass 2: Edge Cases + Robustness (if Pass 1 found issues)

Only runs if Pass 1 found at least 1 issue.

Review the same code with a different lens:

  1. Edge cases: Off-by-one errors, empty collections, boundary values, timeout handling, race conditions
  2. Robustness: Missing fallbacks, brittle string parsing, hardcoded assumptions, missing default cases in switch/match
  3. Data integrity: Type coercion risks, integer overflow, encoding issues

Record findings in the same format as Pass 1.

After Pass 2: - Count NEW findings (not already reported in Pass 1) - If 0 new findings: report "Pass 2: No new issues. Convergence reached." → skip to Step 4 - If new findings exist: proceed to Pass 3

Pass 2 — Edge Cases + Robustness: {N} new findings
  Cumulative: {total} findings across 2 passes

Pass 3: Resource Management + Performance (if Pass 2 found new issues)

Only runs if Pass 2 found at least 1 new issue.

Final review pass:

  1. Resource leaks: Unclosed file handles, database connections, event listeners, subscriptions
  2. Performance: N+1 queries, unnecessary loops, redundant computations, blocking operations in async contexts
  3. Memory: Unbounded data structures, missing cleanup, large object retention

Record findings in the same format.

Pass 3 — Resources + Performance: {N} new findings
  Cumulative: {total} findings across 3 passes

Step 4: Generate Report

Compile all findings into a structured report:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RCI Self-Review Complete
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Passes run: {N} of 3
Convergence: {achieved at pass N / hard limit reached}
Total findings: {count}

| # | Severity | Category | File:Line | Issue |
|---|----------|----------|-----------|-------|
| 1 | HIGH     | security | src/api.ts:42 | Unsanitized user input in query |
| 2 | MEDIUM   | error    | src/handler.ts:78 | Uncaught promise rejection |
| ... |

Recommendation:
{If HIGH/CRITICAL: "Fix HIGH-severity issues before running /vt-c-4-review"}
{If only MEDIUM/LOW: "Proceed to /vt-c-4-review — findings are minor"}
{If 0 findings: "Code passed self-review. Proceed to /vt-c-4-review"}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
NEXT: /vt-c-4-review
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Edge Cases

Scenario Handling
No git diff and no file argument Report "no changes" and exit
Diff is very large (>2000 lines) Process first 2000 lines, note truncation
Pass 1 finds 0 issues Skip passes 2-3, report clean
All findings are LOW severity Report but recommend proceeding to review
File argument doesn't exist Report error and exit

Integration Points

Skill Relationship
/vt-c-3-build Step 7 Offered in pre-review ritual alongside /simplify
/vt-c-4-review RCI is pre-screening; review is the full multi-agent pass
/vt-c-verification-before-completion Shares "evidence before claims" philosophy
/vt-c-ralph-wiggum-loop Shares convergence-check pattern

Anti-patterns

  • Do NOT auto-fix findings without user seeing them first
  • Do NOT run on broken/failing code — fix tests first
  • Do NOT replace /vt-c-4-review — RCI is pre-screening, not a substitute
  • Do NOT run more than 3 passes — diminishing returns beyond that