review-design

What it does

/cl-dev:review-design gives you a written review of a solution design, an implementation plan, or already-implemented code. It looks at the work across three dimensions and reports findings for each:

• Structural quality: is the design clear and simple, or is complexity leaking into places that will be hard to maintain?
• Security: where are the trust boundaries, and what could go wrong at them?
• Privacy: is the design handling data carefully and collecting only what it needs?

You get back organized, written findings you can act on, grouped by dimension. The review reports findings; it does not give a pass/fail verdict, and nothing is changed on your behalf. It is advice you decide what to do with.

When to use it

Reach for it after you have a design or plan in hand but before you commit to building. In the workflow, that's right after /cl-dev:design-solution and around /cl-dev:create-impl-plan. It is a checkpoint to catch structural, security, or privacy problems while they are still cheap to fix.

Good moments to run it:

• You've drafted a design and want a second, structured opinion before planning.
• Your change touches authentication, permissions, external inputs, or anything crossing a trust boundary.
• Your change stores, moves, or exposes customer or personal data.
• You want a threat-model-style read on a plan before implementation starts.

It pairs naturally with /cl-dev:reduce-complexity: use review-design for a broad written read across all three dimensions, and reduce-complexity when you want to focus in and pressure-test complexity specifically.

How to invoke it

Run it from your coding agent in the repo you're working in:

/cl-dev:review-design

Point it at what you want reviewed: a design, a plan, or the current code change. It works best once you actually have something concrete to review, so run it after a design or plan exists rather than on an empty repo.