clutcher/laminar

Checks a change, such as a pull request, a branch or the working tree, against the rules a writer can miss, which are the project's conventions under .claude/rules/conventions/, the common pitfalls, every rule of the laminar code-style skill marked narrower than the book, and its conventions files for the languages of the change. Use when the user asks for a convention check, asks to check a change against the team or project conventions, or asks for a convention check before a merge. Every finding names the rule it rests on, and a finding is input to a discussion, not a gate on the merge. It checks the patterns of the book among the common pitfalls and the few design directions of the book that the review skill of the laminar plugin does not judge yet, and leaves every other design direction of the book Laminar Software Design to that review skill, which judges them.

Gives the design directions of the book Laminar Software Design, each with its reason, for any code that is written or changed, whatever the reason for the change, such as a new feature, a bug fix, a pull request comment, the fix of a review finding, or a refactor. It covers names, method bodies, classes, modules, types that hold state, entry boundaries, tests, I/O and comments, and gives for each design direction the cognitive failure it prevents or its correctness or performance reason. Use it whenever code is written or changed, in any language. It is not a review. It reports no findings and judges no existing code on its own, and it shapes the code while it is written.

Reviews code for design quality against the 3 qualities of high-quality code in Laminar Software Design, which are simple to understand and change, correct in behavior, and fast enough for its purpose. Simplicity is judged by the cognitive failure a reader meets, correctness by the decisions that prevent errors and the tests that verify behavior, and performance by waste a known alternative avoids. Use when the user asks to review code, a pull request, a branch, a commit, files, a folder, or a module; asks whether code is simple, well named, well structured, well bounded, or well tested, whether its types allow invalid states, or whether it runs I/O in a loop; asks for a design review or an abstraction review of existing code; or names Laminar Code Review or asks to check code against the book. Prefer it over a general review when the question is about design rather than one specific bug. Not for a bug hunt or a quick look, because it does not find logic errors, judges waste and not speed, and takes minutes.