$critique

---
name: critique
description: Strict but pragmatic critique of plans, code, implementations, diffs, or results for unnecessary complexity, over-engineering, weak architecture, misplaced logic, and missed simpler designs. Use when the user asks to critique a plan, critic your own plan, critique code, critique an implementation, review the result, check for over-engineering, find a cleaner approach, or manually invokes $critique, $critique-plan, or $critique-code.
---

# Critique

Use this skill to pressure-test a proposed plan or completed implementation for structural quality. Apply the same thinking before and after code is written: identify where the current shape is more complex than necessary, then recommend the cleaner path forward.

The goal is not to block progress. The goal is to move forward through code that is simpler, clearer, more elegant, and easier to maintain.

## Review Posture

Be direct and collaborative. Hold a high bar, but give concrete alternatives.

Treat structural complexity as a serious concern that can be overridden when pragmatically justified. Bias toward clean architecture, not small diffs. Prefer the larger refactor when it materially simplifies the system, deletes complexity, clarifies ownership, fixes a root cause, or repairs a bad boundary. Prefer a small change only when it is also the clean architectural shape. Do not recommend refactors for their own sake.

Prefer fixing root causes over adding fallback patches, defensive safety nets, compatibility layers, or "just in case" behavior. Do not preserve backward compatibility unless the user asked for it or the current situation clearly requires it.

## Claim Discipline

Make critique claims concrete. Whether reviewing a plan before implementation or code after implementation, ground each objection in the proposed shape, the actual code path, adjacent ownership boundaries, project conventions, or a concrete risk.

Take a holistic view of the change. Analyze the immediate upstream context that feeds the target area and the downstream context that consumes or depends on it, then recommend the shape that fits the wider flow instead of only optimizing the local edit.

Reject speculative edge cases, unrealistic risks, broad rewrites without a clear simplification payoff, and fixes that would make the codebase more complex without addressing the root cause.

When a finding reveals a repeated bug class or structural pattern, inspect the current task scope for sibling instances. Prefer fixing the pattern at the right ownership boundary, including through a larger architectural refactor when that leaves the system materially cleaner. Stop only where the remaining work crosses into unrelated ownership, unrelated product scope, or a follow-up that is clearer as separate work.

Raise security concerns when the plan or implementation creates a concrete, actionable risk or removes an important safety check. Avoid security-shaped speculation that does not change the implementation decision.

## Core Questions

Ask these questions for any plan, diff, or implementation:

- Is there a simpler shape that removes complexity instead of organizing it?
- Does this solve the root cause, or does it add a patch around the symptom?
- Does the plan introduce abstractions, helpers, mappers, services, files, flags, or modes that do not clearly pay for themselves now?
- Does it add special-case branching to an already busy flow?
- Is feature-specific logic leaking into shared or general code?
- What upstream callers, producers, inputs, or invariants shape this change?
- What downstream consumers, side effects, data contracts, or user flows does this change affect?
- Are types, casts, optional fields, or loose object shapes hiding an unclear invariant?
- Is this consistent with the codebase's existing patterns, conventions, and canonical helpers?
- Did a refactor reduce the number of concepts a reader must hold, or merely move complexity around?
- Would a larger refactor leave the architecture materially cleaner?
- Is a file approaching or crossing roughly 1000 lines because responsibilities are accumulating in the wrong place?

## Aggressively Challenge

Challenge these as serious design problems:

- Unnecessary abstraction, helper, mapper, service, wrapper, or generic mechanism.
- Special-case branches added inside busy existing flows.
- Feature logic leaking into shared/general layers.
- Loose types, casts, optionality, or fallbacks that obscure the real contract.
- Duplicated logic where a canonical helper or established pattern already exists.
- Temporary flags, modes, compatibility paths, or defensive branches likely to become permanent.
- Refactors that move complexity without reducing it.
- Backward compatibility kept for its own sake.
- Local fixes that leave the root cause intact.
- Files crossing roughly 1000 lines without a strong structural reason.

## Allow When Justified

Accept complexity when it is clearly justified by the current task:

- A larger refactor is the cleanest path to a simpler architecture.
- Existing project patterns favor a slightly imperfect but consistent shape.
- Migration risk would make an otherwise cleaner rewrite irresponsible.
- A stable external API or integration boundary truly requires compatibility.
- The surrounding legacy area is too risky to reshape now, and the chosen fix is contained.

Accept contained fixes in risky legacy areas, but do not use containment as an excuse to preserve bad architecture when the cleaner refactor is inside the current task's natural scope.

When accepting complexity, state the reason briefly. Do not turn exceptions into new general rules.

## Output Shape

Adapt the response to the task, but usually produce two sections:

1. **Complexity Audit**: list the important issues as `issue -> reasoning -> recommended shape`. Focus on structural concerns, missed simplifications, misplaced ownership, bad boundaries, unnecessary abstractions, and root-cause misses. Skip low-value nits when larger issues exist.
2. **Updated Path**: give the revised plan or next actions in the cleaner shape. Make it practical enough to execute.

For very small tasks, use a shorter natural answer. For code review, cite files and lines when available. For plan critique, reference the specific step or design choice being challenged.

## Decision Bias

Prefer:

- Direct code over indirection.
- Existing conventions over new local patterns.
- A clean ownership boundary over scattered checks.
- Deleting branches over centralizing branches.
- Explicit contracts over optional/cast-heavy flows.
- Root-cause fixes over fallback behavior.
- A larger clean refactor over a small patch when the larger change materially simplifies the system.
- Architectural clarity over minimizing the number of changed files or lines.

Do not approve a plan or implementation just because it works. It should also leave the codebase no messier than it found it, unless there is a clear pragmatic reason and a contained follow-up path.