[FEATURE] Codebase audit mode for /ultrareview (not just diffs)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's review tooling (/review, /ultrareview, the Code Review GitHub App, and the /code-review plugin) all operate on diffs: PRs, branch state, or staged changes against a base. This assumes a clean, previously-audited baseline that the diff is being layered onto.

For codebases built primarily through AI-assisted development without a formal review process, that assumption doesn't hold. Reviewing only new changes against an unaudited baseline produces false confidence: incoming PRs pass review while real issues sit untouched in the existing code. The larger surface area (everything written before review tooling was adopted) is invisible to the tools designed to catch problems.

Proposed Solution

Add a baseline audit mode to /ultrareview that runs the same multi-agent, verified-finding review against a scoped portion of existing code rather than a diff.

Suggested shape:

• /ultrareview --path src/auth to scope by directory, package, or module
• /ultrareview --focus security (or performance, architecture, maintainability) to scope by concern
• Findings ranked by blast radius and severity rather than "what changed"
• Same verified-finding output (file, line, explanation) so results are actionable in the same way as PR reviews
• Same independent verification step that filters false positives, which is the whole reason /ultrareview is worth running over a generic prompt

Alternative Solutions

Workarounds exist: interactive Claude Code sessions with structured audit prompts, custom code-reviewer subagents, /ultraplan to scope an audit. All of them lose the critical advantage of /ultrareview, which is independent verification of findings before they are reported. Without that step, the user is back to manually triaging a list of plausible-sounding issues, most of which may be noise.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

A solo founder builds a SaaS product over six months using Claude Code, Lovable, and other AI coding tools. The codebase reaches roughly 30K LOC across a pnpm monorepo before a fractional CTO is brought on for QA and code review going forward.

From that point on, new PRs can flow through /ultrareview and the GitHub App. But the existing code, including the auth flows, the payment integration, the WAF allowlist logic, and the request hooks handling redirect attribution, has never been systematically reviewed. The team has no way to produce a verified backlog of issues in that existing code without burning hours on manual audits or running interactive Claude Code sessions that lack the verification step.

Running /ultrareview --path src/auth --focus security would produce the same quality of verified findings against the existing auth module, allowing the team to triage and fix real issues before stacking more changes on top.

Additional Context

The PR-only model implicitly assumes teams that already have review hygiene and are using Claude Code to scale an existing process. That serves enterprise well. It does not serve the rapidly growing population of solo founders, small teams, and "vibe coded" projects whose codebases reached production without ever being reviewed, which is arguably the cohort with the most to gain from automated review.

Pricing and availability could mirror the existing /ultrareview model (three free runs on Pro/Max, then standard token rates), or be metered separately given the larger scope per run.

The broader point: existing-code audit is a different shape of work than PR review, but the underlying multi-agent + verification architecture is the same. Exposing it for both shapes would meaningfully expand who the product serves.