essentials

Use this agent when you need to refactor code to improve readability, reduce complexity, or enhance maintainability without altering functionality. This includes simplifying complex logic, removing redundancy, improving naming, extracting methods, reducing nesting, and applying clean code principles. The agent preserves all public APIs and external behavior unless explicitly authorized to change them.

Use PROACTIVELY when creating git commits. Performs git commit with semantic messages and pre-commit validation

Use this agent when the user explicitly requests a security audit, penetration test, or vulnerability assessment of their codebase. Specializes in finding critical vulnerabilities (auth bypass, IDOR, injection, etc.) through invariant-binding analysis across trust boundaries. Do not auto-invoke for general code review — only for dedicated security analysis requests. <example> Context: User has pushed changes to a payment processing endpoint and wants confidence before merge. user: "Can you do a security audit on the branch changes to the billing API?" assistant: "I'll use the security-auditor agent to perform a deep invariant-binding analysis of the billing API changes." <commentary> Explicit request for a security audit on specific code — exactly the trigger condition. The agent runs the multi-phase methodology in an isolated context. </commentary> </example> <example> Context: User is preparing a release and wants to check for access control issues. user: "Before we ship, can you check this for IDOR or auth bypass vulns?" assistant: "Launching the security-auditor agent to hunt for IDOR and access control flaws across the release scope." <commentary> Vulnerability-class-specific request. The agent scopes its threat model to access control and applies the detection heuristics for IDOR and auth bypass. </commentary> </example> <example> Context: User asks for general code review. user: "Can you review this PR for code quality?" assistant: "I'll handle the code quality review directly. The security-auditor is reserved for explicit security audits." <commentary> NOT a trigger. The description explicitly says "Do not auto-invoke for general code review." Generic review requests use a different path. </commentary> </example>

Use this agent for an unusually strict maintainability audit of branch changes — abstraction quality, the 1k-line rule, spaghetti-condition growth, and "code judo" simplification. The harsh, high-conviction sibling to general code review; reserve it for when the user explicitly asks for a thermo-nuclear / thermonuclear review or a deep, demanding code-quality audit. Do not auto-invoke for ordinary review requests. <example> Context: User wants a brutal structural pass on a feature branch before merge. user: "Give this branch a thermo-nuclear code quality review." assistant: "I'll dispatch the thermo-nuclear-code-quality-review agent to audit the branch diff against the full maintainability rubric." <commentary> Explicit thermo-nuclear request — exactly the trigger. The agent loads the rubric skill and applies it to the diff in an isolated context. </commentary> </example> <example> Context: User is worried a PR is bloating files and adding ad-hoc branches. user: "This PR feels like it's turning into spaghetti and one file is getting huge. Tear it apart." assistant: "Launching the thermo-nuclear-code-quality-review agent — it specifically hunts file-size explosions, spaghetti branching, and code-judo simplifications." <commentary> Maintainability/structure concern with an explicitly demanding tone. Matches the agent's purpose. </commentary> </example> <example> Context: User asks for a normal, balanced PR review. user: "Can you review this PR?" assistant: "I'll run a standard review. The thermo-nuclear-code-quality-review agent is reserved for when you explicitly want the harsh maintainability audit." <commentary> NOT a trigger. Ordinary review requests should not invoke this agent — it is deliberately strict and high-conviction. </commentary> </example>

Use when the user is weighing or pressure-testing an idea rather than committing to build it — 'should I do X', 'which of these approaches', 'is this worth doing', 'what am I missing', 'am I overthinking or over-engineering this'. A lightweight thinking partner that surfaces hidden assumptions and argues for the simplest version, in conversation — no files, no spec. Once the idea is settled and the user wants it turned into an actual plan or spec, that's planning work — hand off to the ideation skill if it's available. Not for writing code to a known spec, bug fixes, or refactors.

Phased maintainability migration that transforms messy, overgrown, or slop-prone repos into product-shaped codebases while preserving behavior. Covers file splitting, typed boundaries, test hardening, feature folders, API consolidation, and a final migration audit microsite. Use when the user asks to "rehab this codebase", "run a maintainability migration", "modernize structure", "clean up this messy repo and make it maintainable", or "productionize this prototype". Unlike codebase-sweep (parallel quick audit), this is a deep, staged refactor with migration planning and checkpoint commits. Do not use for security audits, observability, compliance, or SRE work.

Comprehensive, codebase-wide quality sweep that dispatches parallel subagents to find and fix structural issues. Covers deduplication, type consolidation, dead code removal, circular dependencies, weak types, defensive try/catch, deprecated paths, and AI slop. Primary support for JS/TS projects (knip, madge, TypeScript types); other languages get grep-based analysis. Use when the user asks to "deep clean the whole repo", "run a full codebase audit", "nuclear cleanup", "deslop everything", or "sweep the entire codebase for quality issues". Do NOT use for single-file fixes, branch-scoped diffs (use de-slopify instead), or targeted refactors.

Remove code slop from the current branch

Produce a rich, self-contained HTML explainer for a code change — deep background, core intuition with diagrams, a guided code walkthrough, and an interactive quiz. Use whenever the user asks to explain or deeply understand a diff, PR, branch, or commit — "explain this PR", "walk me through this change", "what does this diff actually do", "make an explainer for this branch" — or wants a shareable document that teaches someone else what changed and why. Output is an HTML file opened in the browser, not a chat reply.