Mistake-proofing for software. Shigeo Shingo's poka-yoke method as a Claude Code plugin: audit code for footguns, design APIs that resist misuse, install guardrails, turn incidents into devices.
Reviewing code that already exists for structural problems: responsibilities that have drifted together, names that no longer describe what they name, dependencies pointing the wrong way, and duplication that has hardened into divergence.
Permission and access-control code. Structure, clarity and testability of authorisation logic: where the decision lives, how it is named, and keeping it separable from the code that acts on it.
Software quality review and design guidance for any code: naming, cohesion, coupling, duplication, function size, dependency direction, and testability. Use when someone asks to improve, review, refactor, or design code, or asks what good structure looks like here. Routes to the sub-skill matching the kind of work.
Designing a new interface, module, schema or type. Naming, cohesion, parameter shape, dependency direction and testability, decided before the thing has callers.
Something broke. Deciding what to change in the code so the class of problem is less likely, and writing it up so the next person understands the reasoning rather than just the outcome.
Forms, flows and screens. Structure, naming and clarity of user-facing interaction code: component boundaries, state ownership, and keeping presentation separable from the rules behind it.
Defensive programming for any code: validating inputs at every boundary, checking for null and absent values, supplying safe fallbacks, catching and logging exceptions, and degrading gracefully rather than failing. Use when someone asks to make code robust, resilient, safer, or harder to crash. Routes to the sub-skill…
★not rated 22▲
+1 3d agoA70 tokens
originalMIT
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: