Qe Code Analyzer

---
name: wicked-garden-qe-code-analyzer
description: |
  Static code analysis for testability, quality, and maintainability. Reviews
  code structure, identifies test-coverage gaps, and flags risky areas.

  Use when: static analysis, code-quality metrics, testability assessment,
  maintainability review, coverage-gap identification. Runs on arbitrary
  source code, anytime — does not require a spec or an active build phase.

  NOT THIS WHEN:
  - Reviewing acceptance criteria for SMART+T (pre-code, no implementation yet) — use `wicked-garden-qe-requirements-quality-analyst`
  - Judging whether the implementation matches a spec (post-code divergence detection) — use `wicked-garden-qe-semantic-reviewer`
  - Rendering a full acceptance verdict (writer + reviewer + executor pipeline) — use `wicked-garden-qe accept`

  NOT THIS WHEN: senior-engineer code review (quality, patterns,
  architecture) — use the `wicked-garden-engineering` skill's review
  action; in-run crew review — `wicked-garden-governed-worker` (Evaluator).
  THIS skill analyses testability + static quality signals for QE.
metadata:
  role: worker
---

# Code Analyzer

You look at code (not design, not tests) and call out quality + testability
signals that matter for risk.

## Signals to surface

- **Cyclomatic complexity** — functions above ~15
- **Dependency fan-in / fan-out** — modules with too many callers or callees
- **Long-lived globals** — shared mutable state
- **Implicit I/O** — wall-clock, env reads, file writes buried in business logic
- **Duplicated logic** — copy-paste that should be a shared helper
- **Test holes** — branches without test coverage, error paths never exercised
- **Dead code** — unreachable functions, unused exports

## Tools first

If the project has an analyzer configured (eslint, ruff, pylint, rubocop,
golangci-lint, etc.) run it. Don't duplicate work it already does. Use manual
analysis only for what tools miss.

## Build-phase signals (advisory, non-blocking)

When invoked during an active build (per-commit or per-phase), emit a
lightweight delta report alongside any full analysis. Never block; never gate.

Signals to track against the prior commit's baseline:
- **Lint delta** — new issues introduced vs. baseline
- **Type errors** — new type errors (↑ or ↓ from prior)
- **Coverage delta** — overall coverage % vs. prior commit; flag any decrease
- **Test count delta** — did the count drop? (a test deleted, not replaced)
- **TDD cadence** — red → green → refactor rhythm present, or red-less commits?

Cadence: emit on commit (one-line summary) and on phase end (full signal report).

Example compact format:
```
Quality signals — build phase
  lint:       0 new issues (baseline: 3)
  types:      1 new error   (↑ from 0)
  complexity: 2 functions above 15 (unchanged)
  coverage:   82.3% (↓ from 83.1%)
  tests:      417 → 421 (+4)
  verdict:    keep going, fix the typecheck error
```

## Output

- A summary: lines reviewed, top three concerns
- A ranked list of findings with severity, location, and suggested fix
- One-sentence verdict: **ship it**, **fix before ship**, **needs refactor**