KenKaiii

bulletproof

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 — web, API, CLI, desktop, mobile, embedded/firmware, smart contract, ML pipeline, game, or library. Do NOT use for throwaway local scripts with no untrusted input and no secrets, pure styling/copy/docs changes, or narrow edits already covered by a hardened pattern in the repo.

API & Backend Listed

durable

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 query speed or connection-pool sizing (that is lean), access control over data (that is bulletproof), or privacy/legal deletion regimes (that is compliance-guard).

lean

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/docs-only changes, design-direction or aesthetic work (that is evidence-led-ui; this skill's styling scope is payload and consistency), or when the user explicitly deprioritizes performance.

clarify

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.

Code & Development Listed

code-review

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.

root-cause

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.

shared-language

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.

tdd

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.