claudekit

Use after a plan exists and before any implementation begins. Activate for keywords like "review the plan", "check this plan", "is the plan ready", "plan-review", "pressure-test the plan". Orchestrates two parallel reviewers — architecture and experience — consolidates their findings into one fix gate, and applies user-selected fixes to the plan. Always run before non-trivial implementation -- a plan that survives review costs less to implement than one that doesn't.

Use when starting a non-trivial feature, change, or refactor before any plan or code is written. Activate for keywords like "spec", "shape", "what should we build", "requirements", "design this", "we need to", "let's add". Produces a written spec covering goals, non-goals, constraints, acceptance criteria, and open questions. Engineering-flavored — does not chase founder framings like demand reality, wedge focus, or 10x outcomes.

Use after a spec exists and before any implementation code is written. Activate for keywords like "plan", "break down", "decompose", "implementation plan", "task list", "what's the order". Produces a numbered task list where each task names the file, the change, the test, and what evidence proves it's done. Always cite file paths and exact commands -- never write a plan with placeholder verbs like "implement" or "set up".

Interactive setup wizard for claudekit. Scaffolds rules, hooks, and MCP server configs into the user's project. Run /claudekit:init to configure. Use when setting up a new project with claudekit or reconfiguring an existing one.

Use when investigating dependency bloat, security advisories, supply-chain risk, upgrade planning, or before adding a new third-party package. Activate for keywords like "deps", "dependencies", "package.json", "requirements.txt", "Cargo.toml", "audit", "CVE", "stale package", "do we use", "what depends on", "transitive dep". Produces a written audit with import-graph evidence — never trust scanner output without verifying call sites.

Use when opening a PR for review or when receiving review feedback. Activate for keywords like "code review", "PR review", "request review", "review feedback", "address comments", "reviewer said". Covers both ends of the loop: preparing a reviewable PR and acting on feedback rigorously. Always engage with every comment -- never dismiss feedback by silently ignoring it.

Use during active debugging when you have a hypothesis to test or need to instrument a running system. Activate for keywords like "debug", "instrument", "log", "trace", "breakpoint", "what's happening at runtime", "production behavior". Pair to investigate-root-cause for the doing-it phase. Always record what you observed -- never debug entirely "in your head" without leaving evidence behind.

Use when implementing a non-trivial feature, migration, or refactor that would otherwise be a single large change. Activate for keywords like "feature flag", "incremental", "vertical slice", "migration", "rollout", "behind a flag", "ship small". Enforces vertical slicing, feature-flagged rollout, and refactor-with- evidence (behavior-preserving changes proved by test/perf deltas). Always ship the smallest reversible change -- never bundle unrelated improvements.

Use when encountering ANY bug, error, test failure, or unexpected behavior. Activate for keywords like "bug", "error", "failing", "broken", "doesn't work", "unexpected", "crash", "exception", "TypeError", "undefined", stack traces, or any error message. Also trigger when tests fail unexpectedly, when behavior differs from expectations, when investigating production incidents, or when flaky/intermittent issues appear. Investigation produces evidence and a written hypothesis before any fix is attempted. Always investigate root cause before proposing fixes -- never guess at solutions.

Use when entering an unfamiliar codebase or area, before making non-trivial changes, when onboarding to a new system, or when planning a refactor that touches multiple modules. Activate for keywords like "explore", "map", "find where", "trace", "how does X work", "what calls Y", "scope of change". Produces an evidence-cited map of the relevant area with file:line references for every claim. Always cite the file and line you read -- never assert behavior you have not verified by reading.

Architecture-dimension reviewer for written plans. Use when running plan-review or directly when an architectural review is wanted. Activate for keywords like "architecture review", "data flow", "failure modes", "rollback", "edge cases", "test matrix". Scores 5 sub-dimensions 0-10, produces ranked fixes. Always cite file paths or task numbers from the plan -- never write generic architectural advice.

Experience-dimension reviewer for written plans (UX + DX). Use when running plan-review or directly when an experience review is wanted. Activate for keywords like "UX review", "DX review", "experience review", "error states", "API ergonomics", "developer experience", "user states". Scores 5 sub-dimensions 0-10 covering both end-user experience (information hierarchy, state coverage, accessibility) and developer experience (error copy, API/CLI ergonomics, AI-slop avoidance). Always cite plan task numbers -- never write generic UX/DX advice.

Use when cutting a release, bumping a version, or writing release notes. Activate for keywords like "release", "version bump", "changelog", "release notes", "tag", "publish", "ship a release", "v1.x", "v2.x". Enforces version hygiene: SemVer respect, changelog discipline, atomic commits, tagged release. Always reflect the actual diff in the changelog -- never write notes from memory or marketing copy.

Use when implementing any feature, bugfix, or refactor that has a testable outcome. Activate for keywords like "TDD", "test-first", "red-green", "write the test first", "implement <feature>", "fix <bug>". Enforces the red-green-refactor discipline -- write a failing test, make it pass with the smallest change, refactor with tests as a safety net. Always paste the red and green test runner output -- never claim "tests pass" without showing them pass.

Use before claiming a task, feature, or PR is complete. Activate for keywords like "done", "complete", "ready to merge", "ship it", "tests pass", "looks good", "fixed". Mandatory pre-completion gate. Refuses to mark anything done without evidence: command outputs, test runs, behavioral checks. Always paste the evidence -- never assert "it works" without showing it works.