Blindspot Code Critique

Blindspot

You are performing a structured critique of code, architecture, or systems. Your job is to find what the author can't see — the gaps that familiarity hides, the risks that daily use normalizes, the debt that accumulates silently.

This is not a linter. Linters catch syntax and style. You catch design decisions that will hurt later — the unwrap() that will panic in production, the O(n²) that's fine with 10 items but fatal with 10,000, the API that can't evolve without breaking clients.

When to use

• During evolution self-assessment (proactive self-critique)
• On-demand via /skill run blindspot with a target
• When reviewing unfamiliar code before modifying it
• After a feature is "done" — the last-mile audit
• When a community issue reports a class of problem (search for siblings)

When NOT to use

• For style/formatting issues (use clippy/rustfmt)
• When you need to understand code before critiquing it (use explore-codebase first)
• For single-line fixes you can see directly (just fix them)

Parameters

Target

What to analyze. One of:

• A file path: src/tools.rs
• A directory: src/format/
• A module or concept: "error handling in the REPL"
• self — yoyo's own codebase (defaults to src/)

Roast level

Controls the threshold for reporting:

• gentle — Critical and Warning only. For when you want actionable items without noise.
• standard (default) — Critical + Warning + Smell. The balanced default.
• brutal — Everything, including nitpicks. For when you want the full picture.

Analysis Dimensions

Examine the target through these lenses:

1. Error handling gaps

• unwrap() / expect() on fallible operations in non-test code
• Functions that return Ok(()) but swallow errors silently
• Missing error context (bare ? without .context() or .map_err())
• Panic paths reachable from user input
• Error types that lose information (stringly-typed errors)

2. Security blind spots

• Hardcoded secrets, tokens, or credentials
• User input passed to shell commands without sanitization
• Path traversal vulnerabilities (unchecked ../)
• Unsafe blocks without safety comments
• Dependencies with known vulnerabilities

3. Architecture debt

• God objects (structs/modules doing too many things)
• Circular dependencies between modules
• Leaky abstractions (implementation details in public interfaces)
• Dead code that's maintained but never called
• Tight coupling that prevents independent testing

4. Scalability risks

• O(n²) or worse in paths that handle user data
• Unbounded collections (Vec/HashMap that grow without limit)
• Missing pagination on queries or listings
• Blocking operations in async contexts
• Single-threaded bottlenecks in concurrent code

5. Testing gaps

• Public functions without any test coverage
• Tests that only check the happy path
• Tests that mirror implementation rather than behavior
• Missing edge cases: empty input, Unicode, very large input, concurrent access
• Brittle tests that break on unrelated changes

6. API design issues

• Inconsistent naming conventions within the same module
• Functions that accept String when &str would suffice
• Missing input validation at API boundaries
• Breaking change risks (public types that can't evolve)
• Boolean parameters that should be enums

7. Dependency risks

• Outdated dependencies with available updates
• Heavy dependencies used for trivial functionality
• Dependencies with single maintainers or low activity
• Vendored or forked code that's drifted from upstream
• Missing Cargo.lock entries or version pinning

Procedure

1. Scope the target

Determine what you're analyzing and how large it is.

# For a file
wc -l <target_file>

# For a directory
find <target_dir> -name '*.rs' | xargs wc -l | sort -rn | head -20

# For "self"
find src/ -name '*.rs' | xargs wc -l | sort -rn | head -20

2. Decide: direct analysis or sub-agent dispatch?

• ≤5KB total (roughly ≤150 lines): Read directly, analyze in main context.
• >5KB but ≤30KB: Read key files directly, focus analysis on highest-risk areas.
• >30KB: Use sub_agent dispatch. Give each sub-agent one analysis dimension and a subset of files. Synthesize their reports.

For sub-agent dispatch, store the file contents in SharedState and dispatch focused questions:

• "Analyze error handling patterns in these files. Find unwrap() calls, swallowed errors, and missing error context."
• "Find scalability risks: O(n²) algorithms, unbounded collections, missing pagination."