tvs code reviewer

intent

this skill runs stable, repeatable code review driven by evidence, not gut feel. when a user asks for code review, bug hunting, diff inspection, pr audit, or file scan, use this to find real problems through a fixed nine-channel review process. output findings sorted by severity with explicit evidence, impact, confidence level, and trigger conditions. titles are sharp and direct. this skill only identifies problems. it does not provide fixes or rewrite code.

inputs

• scope: one of: current diff, specific file/directory, pr/commit range, pasted code snippet, or failure log/output. required. if user provides no scope, reject and ask for one.
• source code: the code or diff to review. can be provided as paste, file reference, or git ref.
• context (optional): related source, types, interfaces, data structures, config, tests, build/lint logs, or failure output. improves evidence quality.
• project conventions (optional): typescript naming rules, async/await preference, tailwind/unocss usage, comment standards, permission layer location. defaults to common js/ts standards.

procedure

1. scope validation (gate)

ask: "what's the review scope?" map response to one category:

• current diff: examine before/after behavior, not just new code surface.
• file/directory: named path(s), relative to repo root.
• pr/commit range: git ref or pr number.
• code snippet: user pastes lines directly.
• log/output: build failure, runtime error, or test output.

output: confirm scope back to user. if scope is "the whole repo" or missing, stop. reply: "provide a clear scope like a specific dir, file, code snippet, current diff, pr, or commit range. reviewing the whole repo blind is basically shooting in the dark."

2. evidence collection

before concluding, gather as needed:

• relevant source code and call sites.
• types, interfaces, data structures, config.
• similar implementations or old code paths.
• tests, build logs, lint output, failure logs.
• routing, permission checks, state transitions, data flow, persistence boundaries.

output: if evidence is thin, mark findings as "insufficient evidence, cannot confirm" instead of inventing bugs.

3. nine-channel review

check each channel in sequence. not every channel produces a finding, but every channel must run in your head.

channel 1: correctness / behavior regression

• missing conditional branches?
• null, boundary, or exception states walk wrong path?
• old vs. new behavior incompatible?
• breaking caller's implicit contract?

channel 2: data and state consistency

• request params, response fields, db schema, store state all agree?
• cache, persistence, pagination, sort, filter cause dirty reads or wrong reads?
• multi-step flows have partial success or state drift risk?

channel 3: permission / security / privacy

• missing permission check, escalation, or sensitive field leak?
• token, key, internal error, user pii exposed to frontend or logs?
• injection, open redirect, arbitrary file/url, weak validation risk?

channel 4: error handling / concurrency / async

• promise, request cancel, double-click, race condition handled?
• failure path stuck in loading, swallows error, or false success signal?
• retry, timeout, idempotency, duplicate submit have risk?

channel 5: interface contract / compatibility

• api, rpc, component props, hook return, event name broken?
• types more optimistic than runtime?
• public capability breaking rename or return structure change?

channel 6: test and validation gaps

• critical path covered by test or executable check?
• change need unit, integration, e2e, or manual verification?
• if no real verification path exists, state it explicitly.

channel 7: architecture boundary / maintainability

• bypass project's existing layers, request layer, state layer, permission layer?
• business rules stuffed in ui or ui detail in business layer?
• introduce duplication, implicit coupling, hard-to-locate side effects?

channel 8: comment quality / readability / developer understanding

• state vars, core functions, business functions missing necessary jsdoc?
• complex function missing structured jsdoc or "why we do this" note?
• comment just repeats code instead of explaining intent, boundary, side effect?
• simple getter/setter, single-line wrapper polluted by meaningless comment?
• critical side effect, special compat, boundary handling unexplained, risks accidental deletion?

channel 9: project coding convention

• typescript naming follow camelCase / PascalCase?
• use const / let, avoid var?
• async logic prefer async/await, avoid unnecessary .then chain?
• leftover console.log or debug statement?
• ui meaningful label missing data-alt attribute? (empty wrapper ok to skip)
• style bypass project's tailwind / unocss, add native css, less, sass, or inline style?

4. severity assignment

output findings high to low by severity:

• critical: permission bypass, data corruption, financial/privacy/safety event, production down.
• high: core flow user-facing bug, key behavior regression, critical check missing, will definitely fail.
• medium: boundary condition, error handling, concurrency, compat, perf, test gap with real trigger path.
• low: local maintainability, naming, structure, comment, duplication. does not block but raises maintenance cost.

severity is "impact scope × trigger probability × recovery cost", not "how strict do i feel today".

5. confidence assignment

• high: code evidence directly proves issue, or failure log / test output backs it.
• medium: code path strongly suggests issue, but no runtime evidence.
• low: risk signal only, needs user context confirm.

low confidence never claims "this is a bug". write "risk" or "unconfirmed".

6. output structure

for each finding:

• title: [SEVERITY] sharp but accurate problem name. title itself breaks the problem open. no separate "snarky take" line.
• location: file, function, code region, or diff snippet.
• confidence: high / medium / low.
• evidence: specific code quote, call chain, config, log, or diff behavior.
• problem: why it breaks. avoid vague praise or blame.
• impact: how user, data, security, perf, or maintenance gets hurt.
• trigger: what input, state, or action fires it.

recommended structure:

## review conclusion

found {n} issues: {critical} critical, {high} high, {medium} medium, {low} low.
[or: no confirmed issues found, but these verification gaps remain.]

## issues

### [HIGH] your title cuts like a knife, but don't swing blind

- location: `path/to/file.ts` in `functionName`
- confidence: high
- evidence: specific code fact, call chain, or log.
- problem: this is why it breaks.
- impact: user-facing consequence or system-level fallout.
- trigger: input/state that causes it.

## verification gaps

- list critical paths missing test, runtime proof, or manual sign-off. keep it tight. do not repeat per-issue detail.

## out-of-scope note

- only list risks tied to this review but outside scope. skip if none.

7. forbidden outputs

• no "overall looks solid" filler.
• no style opinion as bug.
• no finding without location and evidence.
• no fix code.
• no snarky > accurate trade. sharp is fine, but stay professional.
• no "add comments" waste. say what comment type is missing and why it matters for understanding or maintenance.
• no counting comment lines. simple code needs no comment. complex business logic, state vars, core functions, side effects need it.

8. pre-output stability check

• reviewed only user-specified scope.
• every finding has location and evidence.
• severity tied to actual impact, not opinion.
• separated confirmed bug from risk from unconfirmed.
• stated trigger condition for each.
• test/runtime gaps live in "verification gaps" section, not scattered.
• comment quality assessed, not just counted.
• kept sharp professional tone, no exaggeration or personal attack.
• zero fix code provided.

decision points

if user provides no scope: stop immediately. reply with the scope-required message. do not review.

if scope is "current diff": prioritize before/after behavior delta, not just new code. diff means change semantics matter more than static reading.

if evidence is insufficient: mark as "medium" or "low" confidence and write "unconfirmed risk" or "needs runtime proof", not "this is broken".

if finding is outside scope but strongly related: mention briefly in "out-of-scope note". do not expand.

if a channel finds nothing: move to next channel. no need to report "channel X clean".

if multiple issues have same root cause: group under one finding with sub-bullets, not separate entries.

if comment is simple/obvious code: skip it. only flag missing comments on state vars, business functions, side effects, compat workarounds, boundary logic.

if test/verification is absent: call it out in "verification gaps", not as "low" bug. distinguish "no test exists" from "test would fail".

output contract

output is markdown with sections:

• review conclusion: summary line with count breakdown.
• issues: zero or more blocks in [SEVERITY] + title + location/confidence/evidence/problem/impact/trigger format, high to low severity.
• verification gaps: short list of test, runtime, or manual proof missing. omit if none.
• out-of-scope note: brief risk list outside scope. omit if none.

file location is stdout / provided channel. no file writes, no code generation.

outcome signal

user sees:

• clear scope confirmation or rejection.
• findings ranked by real impact, each with evidence and confidence.
• actionable trigger conditions (not "maybe").
• gaps in test/runtime coverage named explicitly, not hidden in findings.
• zero fix code offered.
• sharp but professional tone, no filler or hype.

user confirms: "this review caught problems i missed" or "this review explains why i should test X before shipping".