Use when the user wants a focused security pass over the current change — scanning the branch diff for leaked secrets, injection and SSRF, broken access control, unsafe deserialization, and newly added or vulnerable dependencies. Narrower and deeper than the general review skill: it applies only the security lenses…
Use right before declaring an implementation done — a last-pass review of your OWN uncommitted change against a fixed checklist (reuse, stdlib, comments, dead code, tests, scope). Catches the things that make a diff read as AI-written before a human ever sees it. Reviews the current diff; it does not write new…
Use when the user explicitly wants to turn clean, human prose INTO maximal AI slop — as a joke, a demo of what AI tells look like, or to stress-test the humanize skill by feeding it the worst input imaginable. The evil twin of humanize — it adds every tell humanize strips. For laughs and demos only; never run it on a…
Use when the user wants tests written for current changes (uncommitted diff or recent feature). Matches the repo's existing test framework, fixtures, and assertion style. Covers happy path, edge cases, and error paths without over-mocking.
Runs before the agent uses a tool for Read, EnterPlanMode, Bash, Bash and Bash tool calls, executing read_injection_guard.py, plan_guidance.py, comment_guard.py, dependency_guard.py and git_commit_guard.py (5 commands). From steph-dove/klaussy-agents.
Use when a PR has review feedback and the user wants it addressed — pull the review comments, triage each one, apply the changes it warrants, and draft replies. Closes the loop between a review and the follow-up commit; it does not re-review the code from scratch.
Use when the user wants to record an architectural decision — drafting an Architecture Decision Record (ADR) or RFC, documenting a design choice and its trade-offs, or capturing why an approach was taken. Detects the repo's existing ADR location and template style (MADR or Nygard) and matches it; if none exists, sets…
Use when the user wants a commit message written for currently staged changes. Reads git diff --cached, recent log style, and CLAUDE.md, then outputs a conventional-commit-style message — type(scope) summary + why-focused body.
Use when the user reports an error, bug, or unexpected behavior in this repo and wants help diagnosing it. Five phases — reproduce, diagnose root cause (read-only), write a failing test, fix, verify against the full suite.
Use when the user wants to upgrade the project's dependencies safely — bump versions, read changelogs for breaking changes, and verify the suite still passes. Upgrades incrementally and stops on the first break; it does not add new dependencies (that's a design decision to raise separately).
Use when the user wants documentation written or updated — docstrings, API docs, a README section, or a doc comment on a tricky piece of code. Documents selectively: what a reader genuinely can't infer from the code, and nothing they can. Writes prose, not code changes.
Use when the user wants code, a concept, or the current diff explained in this repo. With no specific target, explains the current branch diff; with a target, traces call chains and data flow end-to-end and explains in plain language.
Use when the user wants lint, format, and type errors fixed in the current changes. Reads CLAUDE.md for the repo's lint/format/type-check commands, runs each, and fixes only style/format/type issues — no behavior changes.