rulebook-terse-review

name	Rulebook Terse Review
description	Ultra-compressed code review comments. One line per finding: location, problem, fix. Use when user says 'review this PR', 'code review', 'review the diff', or invokes /rulebook-terse-review. Independent of the base rulebook-terse mode.
version	1.0.0
category	core
author	Rulebook
tags	["core","review","tokens"]
dependencies	[]
conflicts	[]

Rulebook Terse Review

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

Format

L<line>: <severity> <problem>. <fix>.

For multi-file diffs:

<file>:L<line>: <severity> <problem>. <fix>.

Severity prefixes

Use when mixing severities in the same review. Optional when all findings are the same severity.

Prefix	Meaning
🔴 bug:	Broken behavior; will cause an incident.
🟡 risk:	Works but fragile (race, missing null check, swallowed error, unvalidated input).
🔵 nit:	Style, naming, micro-optim. Author can ignore without consequence.
❓ q:	Genuine question, not a suggestion.

Drop

• Throat-clearing: "I noticed that...", "It seems like...", "You might want to consider...".
• Per-comment pleasantries: "Great work!", "Looks good overall but...". Say it once at the top of the review, not per comment.
• Restating what the line does — the reviewer can read the diff.
• Hedging: "perhaps", "maybe", "I think". If unsure, use ❓ q:.
• "This is just a suggestion but..." — use 🔵 nit: instead.

Keep

• Exact line numbers.
• Exact symbol, function, and variable names in backticks.
• A concrete fix, not "consider refactoring this".
• The why if the fix isn't obvious from the problem statement.

Examples

❌ Verbose

"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."

✅ Terse

L42: 🔴 bug: user can be null after .find(). Add guard before .email.

---

❌ Verbose

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

✅ Terse

L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.

---

❌ Verbose

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

✅ Terse

L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).

Auto-Clarity

Drop terse mode and write full prose for:

• Security findings (CVE-class bugs, auth bypass, credential exposure) — need full explanation + CWE or CVE reference.
• Architectural disagreements — need rationale, not a one-liner.
• Onboarding contexts where the author is new to the codebase — they need the why, not just the what.

In those cases, write a normal paragraph, then resume terse for the remaining comments.

Boundaries

Review-only. Does NOT:

• Write the code fix.
• Approve or request changes on the PR.
• Run linters or tests.

Output is the comment(s), ready to paste into the PR review UI.

Override: /rulebook-terse-review off or "stop terse review" reverts to the model's default review style.