signal-review

# ⚡ signal-review — Templated Code Review One line per issue. Severity required. Summary at the end. No prose. --- ## Invocation Triggers Activate when user says any of: - `/signal-review` - `"review this"`, `"review my code"`, `"review this file"` - `"check this PR"`, `"code review"`, `"look at this diff"` - `"what's wrong with this"`, `"any issues with this code"` Target can be: a file, a diff, a PR URL, a code block, or the current working directory. ## Slash command behavior If the user's message is **only** `/signal-review`, treat that as **review now**. - Do **not** stop after acknowledging the skill. - Do **not** ask for confirmation unless the user explicitly asked for draft / dry behavior. - Immediately inspect the provided target (or current working context) and output the review in the format below in the same turn. --- ## Output Format **One line per issue:** ``` {file}:{line}|{issue}|{severity:1-5}|{fix} ``` **Full example:** ``` auth.js:47|nullref on empty arr|4|add guard clause before map api.js:103|missing await on async call|5|add await utils.js:12|unused import lodash|1|remove import ∑ 3 issues [1×sev5, 1×sev4, 1×sev1] critical→api.js:103 ``` **Rules:** - Severity is **required** on every line. No exceptions. - Issue description: max ~60 chars, imperative noun phrase ("nullref on empty arr", not "there is a null reference error") - Fix: max ~50 chars, imperative ("add guard clause before map", not "you should add a guard clause") - Order by severity descending (sev5 first) - One summary line at the end, always --- ## Summary Line Format ``` ∑ {N} issues [{breakdown}] critical→{highest-sev-location} ``` Examples: ``` ∑ 5 issues [2×sev5, 1×sev3, 2×sev1] critical→auth.js:47 ∑ 1 issue [1×sev2] ∑ 0 issues ✓ ``` If zero issues: output only `∑ 0 issues ✓`. No explanation, no praise. --- ## Severity Scale Full definitions in [`references/severity.md`](../references/severity.md). Quick reference: | Level | Meaning | |---|---| | `5` | Breaks in production, security vulnerability, data loss | | `4` | Likely runtime error, will crash under normal use | | `3` | Wrong behavior under specific conditions, logic error | | `2` | Code smell, maintainability issue, confusing pattern | | `1` | Style, minor cleanup, nitpick | **Severity assignment rule:** Assign based on *impact when triggered*, not *probability of triggering*. A SQL injection that only fires on a specific input is still sev5. --- ## What to Review In order of priority: 1. **Security** — injection, auth bypass, exposed secrets, insecure defaults 2. **Correctness** — logic errors, missing error handling, race conditions, off-by-one 3. **Runtime safety** — null dereferences, unhandled promises, type mismatches 4. **Performance** — N+1 queries, unnecessary re-renders, missing indexes, sync-in-loop 5. **Maintainability** — dead code, magic numbers, unclear naming, deep nesting 6. **Style** — only if it affects readability, never as a primary finding --- ## Scope Inference If the user doesn't specify what to review: - **File open in editor** → review that file - **Recent diff** → review the diff (`git diff HEAD`) - **PR URL provided** → fetch with `gh pr diff {url}` and review - **Code block in message** → review exactly what was shared --- ## Flags | Flag | Behavior | |---|---| | `--quick` | Sev3+ only. Skip style and nitpicks. | | `--security` | Security-focused pass only. | | `--sev {N}` | Only report issues at severity N or above. | | `--fix` | After listing issues, output the corrected code block. | **`--fix` output:** List all issues first, then output the corrected file or function in a single code block. Do not mix issue lines with code. --- ## Multi-File Reviews When reviewing multiple files, group by file: ``` auth.js: auth.js:47|nullref on empty arr|4|add guard clause before map auth.js:89|hardcoded secret|5|move to env var api.js: api.js:103|missing await|5|add await ∑ 3 issues [2×sev5, 1×sev4] critical→api.js:103 ``` The summary line covers all files combined. --- ## BOOT Integration If `BOOT:review` is active (see [`references/boot-presets.md`](../references/boot-presets.md)): - Output format is already set to `TMPL:rev` - Severity is already required by `severity_required` - No preamble, no summary prose — just the lines and the `∑` line - If the active template cannot be satisfied, emit `SIGNAL_DRIFT: <one-line reason>` instead of falling back to prose If SIGNAL is not active, still use this format. The template is the default for this skill regardless of SIGNAL mode. --- ## Eat Your Own Cooking This skill's own output must comply with SIGNAL compression rules if SIGNAL is active: - No "Here are the issues I found:" preamble - No "Overall, the code looks pretty good except..." summary - First line is an issue line or `∑ 0 issues ✓` - Last line is always the `∑` summary