Claude Skills by KenKaiii

Use when code will meet an attacker — auth, sessions, tokens, crypto; any untrusted input (user, network, file, uploaded archive, repo content, model or tool output); secrets and credential storage; multi-tenant or per-user data access; dependency, install-script, CI/CD, release-signing or update work; deserialization, shelling out, or dynamic code loading; LLM/agent/MCP tool surfaces; and pre-ship "can this be hacked" reviews, hardening passes, or suspected compromise. Applies to any target ...

Use when requirements or a design are genuinely unsettled — the user asks to interrogate, sharpen, or stress-test a plan before building, or mid-build discovery surfaces a decision that materially changes the result. Do NOT use for routine changes, clear bug reports, or work whose requirements are already settled — bias to action there.

Use when the user asks to review written work — a diff, PR, branch, or "review this before commit/merge" — checking both what was asked for and how well it is built. Do NOT use while still mid-build, when the user only wants a diff summary, or for security review — that is the bulletproof skill's lane.

Use when shipping something real users reach and the work carries legal exposure — pre-launch or "is this safe to ship" reviews; personal data, tracking pixels, cookies and consent; payments, subscriptions, auto-renewal; user uploads or UGC; email/SMS; AI or chatbot features; minors' data; biometrics; scraping; accessibility of public pages; or drafting privacy policies, terms, and disclosures. Also use when a feature may be licensed or illegal: health, finance, legal advice, money movement, ...

Use when user data must not be lost or corrupted — creating the first database/table/schema, writing migrations, backfilling or importing data, any destructive operation (delete, drop, truncate, overwrite), setting up backups or recovery, or moving data between systems; and for "is my data safe", "will I lose my data", "back up my app" checks on existing projects. Any store — SQL (Postgres, MySQL, SQLite), document (Mongo, Firestore), serverless (Supabase, Neon, Turso), files, queues. Do NOT ...

Use for broad or design-sensitive web/mobile UI work: net-new pages/screens, redesigns, design-system work, visual polish, responsive or accessibility overhauls, and UI quality review/critique. Do NOT use for small UI edits that follow existing patterns (bug fixes, minor styling tweaks, wiring, copy changes, small component additions matching neighbors); just match the surrounding code for those. Also exclude database/API schemas, CLI output, standalone image/SVG generation, and description-o...

Use when speed or resource efficiency matters — slow loading or startup, janky interaction, high CPU, memory leaks or RAM that grows over time, zombie/orphan processes, bundle bloat, dead code and dead styles, Core Web Vitals; while building anything that should stay fast and light, running a performance pass over an existing project, or pre-ship "will this run smoothly" checks. Any stack — web, backend/API/CLI, desktop (Electron, Tauri), mobile, native, game, ML pipeline. Do NOT use for copy...

Use when a bug resists the obvious fix, behavior makes no sense, the same symptom keeps coming back, or the user asks why something happens and the answer is not on the surface. Do NOT use for bugs with a clear repro and an obvious cause — reproduce, fix, and re-run directly.

Use when a project's domain vocabulary is fuzzy or drifting, naming decisions keep recurring, or a hard-to-reverse architectural decision needs recording so it is not re-litigated or re-suggested later. Do NOT use for throwaway scripts or projects too small to have recurring vocabulary.

Use when the user asks for test-driven development, red-green-refactor, or "write the test first", or wants a feature built test-first. Do NOT use when tests are a verification step after the build, the project has no suite and the user has not asked for one, or the change is throwaway probe code.