Claude Skills by rainmanjam

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 matching the kind of work.

Stop an AI agent damaging your repo: PreToolUse hooks, permission deny rules, protected paths, verification gates. Use when "claude keeps force pushing", "CLAUDE.md says X but it still does Y", "stop the agent touching prod or .env", or making a repo safe for unattended agent work. For AI features you ship to users use llm.

Pipelines, warehouses, dbt models and metrics, where failure is silently wrong numbers rather than a crash. Use when "the dashboard is wrong", "the numbers do not match", "add data quality checks", "safe backfill", or an upstream schema change broke a join. Covers freshness, row-count and null-rate assertions, data contracts, reconciliation. For a crash rather than wrong numbers use audit.

Pre-commit hooks, CI gates, lint rules, database constraints and branch protection. Use when a rule needs enforcing rather than documenting: "set up enforcement", "unformatted or untyped code must not get merged", "gate this in CI", "we agreed to X and people still do not", "stop secrets getting committed". Covers baselining and ratcheting so existing violations do not block anyone. For constraining an AI agent use agent-guardrails.

AI features you ship to users: structured output, tool schemas, prompt injection, evals. Use when "the model returns bad JSON", "it hallucinates", "stop it calling the wrong tool", "add evals", or an LLM feature can trigger refunds, emails or writes. Covers schema-constrained output, idempotent tool calls, confirmation gates. For agents editing your repo use agent-guardrails.

Deploys, schema migrations, rollback and infrastructure. Use when "can I ship this on Friday", "this migration is scary", "what is the blast radius", "prevent accidental deletion of the database", or a change drops a column. Covers expand/contract, canary rollout, kill switches, prevent_destroy, tested backups. For an incident that already happened use retro.

Mistake-proofing for anything: code, config, a schema, a process, a runbook, a form. Use when someone says "poka-yoke this", "mistake-proof it", "make this harder to get wrong", or runs /poka-yoke with no mode named. Applies Shigeo Shingo's method directly to any subject, and hands off to a specialist mode when one clearly fits. Start here when no other poka-yoke mode obviously applies.

Reviewing existing code for unchecked inputs, unguarded dereferences, unhandled failure paths, swallowed exceptions, missing timeouts and absent limits: the places where an unexpected value becomes an unhandled failure.

Designing a new interface, module, schema or type together with its validation and failure behaviour: what each input accepts, what happens when it does not, and what the caller gets back when something goes wrong.

Find footguns in code that already exists: swappable arguments, silent fallbacks, unguarded deletes, signatures that are easy to misuse. Use when someone asks "what could bite us here", "what is easy to misuse", "poka-yoke this repo", or wants a diff or PR reviewed for ways to get it wrong. Ranks by blast radius. For code not yet written use design; for something that already broke use retro.

Multi-tenant isolation, IDOR and row-level security. Use to find every path where one tenant could read or write another tenant data: "we forgot to filter by org_id", "can users see each other data", "audit these endpoints for cross-tenant leaks", "make an unscoped query impossible". Covers scoped repositories, RLS, default-deny routing and the two-tenant test. For what the UI shows use ux.

Design APIs, schemas, types and state machines so misuse cannot be expressed. Use when writing a new interface and someone asks "what should the types look like", "make invalid states unrepresentable", "so callers cannot screw it up", or wants illegal state transitions rejected. Covers branded types, discriminated unions, typestate, parse-don't-validate. For code that already exists use audit.

Turn a bug, outage or repeated mistake into a device that makes the whole class impossible. Use when something already broke: "make sure this never happens again", "this is the third time", "postmortem", "how did this get through". Root-causes to the missing constraint, then sweeps every other site where the mistake is still available. For a pipeline use data, a deploy use ops, cross-tenant use authz, an AI feature use llm.

Forms, destructive actions and flows users get wrong. Use when "users keep deleting the wrong thing", "add a confirmation dialog", "this flow is error-prone", or building a delete, bulk action, checkout or settings page. Covers undo over confirmation, type-to-confirm, safe defaults, input constraints, double-submit. For the server-side rules behind the screen use authz.