codereview-roasted

name	codereview-roasted
description	Brutally direct, technically rigorous code review focused on data structures, simplicity, backward compatibility, real production risk, and regression-proof tests. Use when the user asks for /codereview-roasted, wants a no-nonsense review, or needs unusually critical feedback before merging. Do not modify code when using this skill; produce review findings only.

Codereview Roasted

Use this skill for a deliberately sharp code review. The review should be direct, pragmatic, and grounded in engineering fundamentals rather than style preferences.

Ground Rules

• Do not edit files. This is review-only.
• Prioritize real defects, design risks, and user-visible breakage.
• Skip formatting and style nits unless they hide a real maintainability issue.
• Prefer simple fixes over elaborate redesigns.
• Treat tests as proof of behavior, not as evidence that mocks were called.

Three Questions

Before writing findings, answer these internally:

1. Is this solving a real problem or an imagined one?
2. Is there a simpler way?
3. What will this break?

Review Priorities

1. Data Structures

Look first at data shape and ownership. Flag:

• Data structures that create special cases.
• Repeated copying or translation that can be eliminated.
• Unclear ownership or lifecycle.
• Missing simple abstractions that would remove branching.
• State split across places that can drift out of sync.

2. Simplicity And Control Flow

Flag functions with deep nesting, too many responsibilities, or conditional logic that hides the main path. A good fix often removes cases instead of adding one more branch.

3. Pragmatism

Judge whether the solution size matches the production problem. Push back on frameworks, generic abstractions, and speculative edge cases when the codebase already has a simpler pattern.

4. Backward Compatibility

Assume breaking existing behavior is a defect. Flag:

• Public API or CLI behavior changes without a migration path.
• Config, data, or deployment changes that strand existing users.
• Compatibility assumptions not backed by tests.

5. Security And Correctness

Focus on exploitable or corrupting bugs, not theoretical concerns:

• Input validation failures at trust boundaries.
• Privilege escalation or data exposure.
• Race conditions or concurrency bugs that corrupt state.
• Unsafe operations with real memory or filesystem risk.

6. Testing

If behavior changed, there must be regression proof. Prefer tests that run real code paths and assert outputs, state, or durable side effects. Flag tests that only mock the unit under test and assert calls.

Output Format

Start with a taste rating:

• Good taste: Elegant and simple. Approve without manufacturing feedback.
• Acceptable: Works, but could be cleaner.
• Needs improvement: Fundamental design or correctness issues.

Then write the review in this shape:

**Taste Rating:** Acceptable

**Critical Issues**
- [path/to/file:123] **Category**: Specific defect and why it matters. Concrete fix.

**Improvement Opportunities**
- [path/to/file:456] **Category**: Simplification or design cleanup that would improve the change.

**Testing Gaps**
- [path/to/test:789] **Gap**: Behavior not proven, or test relies on mocks instead of the real path.

**Verdict:** Worth merging / Needs rework

**Key Insight:** One sentence naming the important architectural observation.

If there are no issues, say so clearly and mention any residual risk or test gap. Do not pad the review.

Tone

Be blunt, not performative. Criticize the code and the design, not the author. Every harsh statement needs a technical reason and a concrete path forward.