---
name: review
description: Holistic codebase review focusing on inputs, outputs, and user experience flow. Use when the user asks to "review the codebase", "review the project", "do a holistic review", "check the UX", "review inputs and outputs", or "review the user flow". NOT for reviewing a specific PR or diff — that is a code-review task.
version: 1.0.0
allowed-tools: [Read, Bash, Glob, Grep]
---

# Holistic Codebase Review

Conduct a structured review of the codebase from a user-experience and system-boundary perspective. The goal is not to audit code style, but to evaluate whether the system makes sense end-to-end.

## Review Dimensions

### 1. Inputs
Identify every place the system accepts external data:
- CLI arguments, flags, subcommands
- File inputs (formats accepted, validation, error messages)
- Config files, environment variables
- Network/API inputs, stdin

For each input surface:
- Is the accepted format clearly documented or communicated to users?
- Is invalid input handled gracefully with actionable error messages?
- Are edge cases (empty, malformed, oversized) handled?
- Is there a clear contract (types, ranges, encoding)?

### 2. Outputs
Identify every place the system produces output:
- stdout/stderr (what goes where, why)
- File outputs (naming, format, location, overwrite behaviour)
- Exit codes — do they correctly reflect success/failure?
- Log output — is verbosity appropriate, is it structured?
- Error messages — are they user-facing or internal?

For each output:
- Is the format consistent and predictable?
- Does success output confirm what happened without noise?
- Does failure output tell the user what to do next?
- Are binary and text outputs clearly separated?

### 3. User Experience / Flow
Map the primary user journeys through the system:
- What does a first-time user do? Is the path obvious?
- What is the happy path? Does it feel smooth?
- What are the common error paths? Are they recoverable?
- Are command names, flags, and file names intuitive?
- Is there unnecessary friction (extra steps, required config that could default)?
- Are long-running operations surfaced with progress or feedback?

### 4. Consistency
- Are similar things done the same way throughout?
- Are naming conventions uniform (snake_case vs camelCase, hyphens vs underscores in flags)?
- Is error handling consistent across modules?
- Do related commands/functions share the same interface patterns?

## Review Process

1. Read the project's README and any top-level documentation first.
2. Identify the main entry points (main.rs, main.py, index.ts, CLI definitions, etc.).
3. Trace each major user-facing flow from entry point through to final output.
4. Note findings per dimension above.
5. Summarise: what works well, what is broken or confusing, what is missing.

## Output Format

Present findings as:

**Inputs** — bullet list of issues and observations  
**Outputs** — bullet list of issues and observations  
**UX / Flow** — bullet list of issues and observations  
**Consistency** — bullet list of issues and observations  
**Summary** — 2–4 sentences: overall health, top 3 priorities to address

Keep the tone direct. Flag actual problems, not theoretical ones. Skip anything that is clearly working well unless it is worth highlighting as a strength.
