---
model: sonnet
---

# /tas-review $ARGUMENTS

Review recently changed code or a specific file/PR.
Includes hygiene scan, test run, and parallel multi-agent review.

> The main session is an **orchestrator + synthesizer** — it sizes the diff, runs cheap pre-checks, fans out specialist agents, and merges findings. Heavy language/security analysis lives in those agents (each on its own model). That is why this command runs on `sonnet`, not `opus`.

## Stack Detection
Read `.tas/rules/common/stack-detection.md`.

## Actions

### Step 1 — Determine review scope
`$ARGUMENTS` can be: file path, Feature ID, or empty (review git diff).
- If empty: get `git diff HEAD` (staged + unstaged) or last commit
- If Feature ID: find corresponding Feature file (`docs/features/{CODE}-Feature-{ID}-*/`) to get changed files list (cross-ref with Technical file's File Changes table)
- If file path: review that file directly

### Step 2 — Pre-checks (MUST pass before continuing)

**Hygiene scan** — quick scan of files in scope:
- Debug code leftovers: `console.log`, `print(`, `Debug.WriteLine`, `debugger`
- Hardcoded secrets: password/key/token/secret assigned as string literal
- Large commented-out code blocks (>5 lines) without reason comment

→ If blockers found: list immediately, require fix before continuing.

**Run tests** — detect from project structure:
- `package.json` → `yarn test --ci` or `npm test`
- `*.csproj` / `*.sln` → `dotnet test`
- `pytest.ini` / `pyproject.toml` → `python -m pytest`

→ If **FAIL**: add finding **"Unit Test Failure"** severity **Critical**, stop, DO NOT continue review.
→ If **PASS**: note "Unit Tests: ✓ PASS" in Review Summary.
→ If cannot detect: note "No test runner detected" and continue.

### Step 2.5 — Scale review to diff size (avoid over-fanning)

Size the diff once (`git diff --stat`), then pick a tier. Launching 3–4 agents on a 5-line change is the main waste this command used to incur.

| Tier | Diff size | What runs |
|------|-----------|-----------|
| **Small** | ≤ 25 changed lines across ≤ 2 files, none security/schema/infra-sensitive | Inline review only — skip the agent fan-out. |
| **Medium** | up to ~10 files, single stack | Inline + `security-reviewer` + language reviewer |
| **Large** | bigger, or spans multiple stacks | Inline + all applicable agents |

**Security override (never skipped by size):** if the diff touches auth / secrets / user input / DB queries / migrations / IaC / payment code → run `security-reviewer` (and `database-reviewer` when schema/queries) regardless of tier. Size can drop the *language* fan-out, never a security-relevant agent.

### Step 3 — Review (non-overlapping lanes)

Each reviewer owns a distinct lane so synthesis dedupe is trivial — no two reviewers check the same criteria, so files aren't re-analyzed against the same rules.

**Inline review — Architecture & Correctness lane** (main session, always run):
Uses the Feature context (CLAUDE.md, SAD, ADRs) **already loaded in this session — don't re-read it.** Read `.tas/rules/common/code-review.md` for the output format only.
Covers: SAD / ADR / layer-boundary conformance, logic correctness, edge cases, null handling, error handling, dead code or debug leftovers the hygiene scan missed.
**Does NOT cover** language style, idioms, naming conventions, async patterns, or design tokens — that is Agent 2's lane. Don't duplicate it.

**Specialized agents** — launch SIMULTANEOUSLY per the Step 2.5 tier (don't wait for each other):

**Agent 1 — `security-reviewer`** (always run):
> Security audit [scope]. Read `.tas/rules/common/security.md`.
> If stack identified, also read `.tas/rules/[stack]/security.md`.
> Focus: OWASP Top 10, injection, hardcoded secrets, auth/authz, data exposure.
> Format: findings grouped by Critical / High / Medium / Low, each with file:line and remediation.

**Agent 2 — Language reviewer** (per `lang_agent` from stack detection):
> Language-specific review [scope].
> Read `.tas/rules/[stack]/coding-style.md`, `.tas/rules/[stack]/patterns.md`, `.tas/rules/[stack]/testing.md`.
> If stack has React: also read `.tas/rules/web/testing.md`, `.tas/rules/web/performance.md`.
> **If UI/frontend changed:** read the `docs/design-spec.md` token system (Colors/Typography/Layout/Shapes) + relevant `## Components` (grep headings, read only those). Add a **design-compliance** check — flag: any raw hex / px / font literal that bypasses a `{token.ref}` (should be a CSS var / theme constant), colors/sizes outside the token set, and components that don't match their `{component.*}` spec or omit defined states. Severity High when it deviates from an approved Design-Spec token.
> Focus: language idioms & naming conventions, async/await patterns, type safety, stack-specific anti-patterns, design-token compliance (UI). Correctness/null/edge-cases are the inline lane — skip them.
> Format: findings by Critical / High / Medium / Low with file:line.

**Agent 3 — `database-reviewer`** (only when `db_agent = database-reviewer`, and scope touches schema/migrations/queries):
> Database review [scope]. Focus: schema correctness, migration safety, missing indexes, N+1 patterns, data integrity. (Injection/string-concat safety is the security-reviewer lane — skip.)
> Format: findings by Critical / High / Medium / Low with file:line.

**Agent 4 — `aws-reviewer`** (only when `infra_agent = aws-reviewer`):
> AWS infrastructure review [scope].
> Focus: IAM policies, secrets in env/config, S3 permissions, Lambda security.
> Format: findings by Critical / High / Medium / Low.

Wait for ALL agents to complete, then synthesize.

### Step 4 — Synthesize results

Combine inline review findings + agent findings, sort by severity. Lanes are non-overlapping by design (Step 3), so dedupe is light — only merge the rare case where a security and a language finding land on the same file:line:

```
## Review Summary

### Critical (must fix before merge)
- [file:line] Issue — Fix: ...

### High (should fix before merge)
- [file:line] Issue — Fix: ...

### Medium (consider fixing)
- [file:line] Issue — Fix: ...

### Low / Info (optional)
- [file:line] Issue — Fix: ...
```

## After review

**If Critical/High present:**
→ List clearly, require human fix. DO NOT continue flow.

**If only Medium/Low:**
→ List suggestions, ask if human wants to fix, then continue.

**When human confirms fixed:**
1. Tick `- [x] Code review passed` in Feature's `## Definition of Done` section
2. Ask: "Tested locally? If OK, mark Feature `Done` and prepare release?"
3. If Yes:
   a. Update Feature frontmatter `status: Done`, set `done_date`
   b. Add Changelog line in Feature: date, "Code review passed, marked Done"
   c. Update `project-status.yaml`: `features.{FEATURE_ID}.status: Done`
   d. Suggest: run `/ado-update feature <ado-id> --status "Done"` if using ADO

## Principles
- Objective review — point to specific file:line and reason
- Propose specific fix, don't just say "code is bad"
- Check if code violates any ADR (cross-ref Feature-Technical's "Need new ADR" section)
- DO NOT auto-change status without human confirmation

## Final Step — Token Log

Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to Feature file being reviewed (if any).