atomic-review

name	atomic-review
description	Compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. Use when user says "review this PR", "code review", "review the diff", or invokes /atomic-review. Auto-triggers when reviewing pull requests.

• "review this PR", "code review", "review the diff", "check this PR"
• "review this change", "review my changes"
• Reviewing pull requests or diffs

Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.

Pre-flight: blast radius (when a code-intel index is present)

If the diff changes a public symbol (exported function, shared utility, interface method, changed signature), run atomic code impact <symbol> before listing findings. Callers that assume the old behavior become 🟡 risk findings. One targeted query per changed public symbol — no full-graph dump. Skip silently when no index is present.

<output_format>

Format

path:line: <emoji> <severity>: <problem>. <fix>.

Single-file reviews may use L<line>: ... instead of path:L<line>: ....

Severity

Emoji	Severity	Use for
🔴	bug	Wrong output, crash, security hole, data loss
🟡	risk	Edge case, race, leak, perf cliff, missing guard
🔵	nit	Style, naming, micro-perf — emit only if user asked thorough
❓	question	Need author intent before judging

End the review with a totals line: totals: 1🔴 1🟡 1❓. Zero findings → No issues. File order, ascending line numbers within file.

Over-engineering

Flag complexity that can be deleted, not just bugs: hand-rolled logic the standard library ships (name the function), a dependency doing what the platform already does (name the feature), a duplicate of an existing helper, or a speculative abstraction with one implementation. Use 🟡 risk when it carries real cost, 🔵 nit for a pure shrink. Always name the concrete replacement, never "consider simplifying".

• src/util.ts:12-38: 🟡 risk: hand-rolled email validator. Real validation is the confirmation mail; 26 lines go.
• src/date.ts:4: 🔵 nit: moment.js for one format call. Intl.DateTimeFormat, 0 deps.
• src/repo.ts:88: 🟡 risk: AbstractRepository with one impl. Inline until a second exists.

Drop

• "I noticed that...", "It seems like...", "You might want to consider..."
• "This is just a suggestion but..." — use 🔵 nit instead
• "Great work!", "Looks good overall but..." — say it once at the top, not per comment
• Restating what the line does — reviewer can read the diff
• Hedging ("perhaps", "maybe", "I think") — if unsure use ❓ question

Keep

• Exact line numbers
• Exact symbol/function/variable names in backticks
• Concrete fix, not "consider refactoring this"
• The why when the fix isn't obvious from the problem statement

Examples

Bad: "I noticed that on line 42 you're not checking if the user object is null before accessing the email property. This could potentially cause a crash if the user is not found in the database. You might want to add a null check here."

Good: src/auth.ts:42: 🔴 bug: user can be null after .find(). Add guard before .email.

Bad: "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."

Good: src/handler.ts:88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.

Bad: "Have you considered what happens if the API returns a 429? I think we should probably handle that case."

Good: src/client.ts:23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).

Auto-Clarity

Drop terse mode for:

• Security findings — CVE-class bugs need full explanation plus references. Write the prose first, then resume terse for the rest of the review.
• Architectural disagreements — need rationale, not a one-liner.
• Onboarding contexts where the author is new and needs the "why".

</output_format>

Boundaries

Reviews only. Does not write the code fix, does not approve or request-changes, does not run linters. Output the comments ready to paste into the PR.