claude-kit

The default vehicle for implementing a coherent batch of code changes — a feature, refactor, bug fixes, or remediation from an audit/review — via a background TDD workflow with an independent spec+quality review gate and staged fix-loop (pausing only when blocked). Use it the moment you are about to edit source files for such a batch, whether the plan came from kit:writing-plans, a docs/plans/*.md file, an audit/analysis you just ran, or asks like "execute the plan", "implement this", "do the refactor", or "remediate the findings" — even for small batches. In ultracode mode, implement via build-flow rather than hand-editing or a one-off workflow. DO NOT TRIGGER for a new feature with no design yet (use kit:brainstorming first), for pure analysis/research/review that changes no code (author a plain workflow), or for a single trivial edit.

Coordinates collaborative design sessions that explore requirements, analyze codebase context, and produce an approved design document with trade-offs. Use when building a new feature, adding functionality, creating components, modifying behavior, starting a project, or planning any creative work. DO NOT TRIGGER when the user already has a concrete design and just wants implementation.

Orchestrates plan-alignment and quality review via a bundled review workflow that fans out review dimensions (correctness, quality, tests, security, architecture) and adversarially verifies each finding. Use when verifying implementation matches requirements or design/architectural alignment, before merging to main, after completing a major feature, before refactoring, after fixing a complex bug, or when a fresh perspective is needed. Consolidates findings into one report.

Finalizes a development branch by verifying tests pass, then presenting four completion options (merge locally, draft PR, keep as-is, or discard). Use when implementation is done, a feature branch is ready to ship, work needs to be merged or a PR created, or the user says "finish", "wrap up", "ship it", or "done with this branch". DO NOT TRIGGER when tests are still being written or implementation is incomplete.

Creates an isolated git worktree workspace with smart directory selection, gitignore safety verification, dependency installation, and baseline test validation. Use when starting feature work, beginning a new branch, needing workspace isolation, setting up before plan execution, or the user says "new feature", "set up a worktree", or "isolate this work". DO NOT TRIGGER for worktree cleanup or removal — use kit:worktree-cleanup instead.

Enforces skill discovery and invocation governance for every task. Use at the start of any conversation, before responding to any user message, when deciding whether a skill applies, when building or modifying features (triggers the brainstorming chain), or when operating within a team context. Defines the default workflow chain (brainstorming -> writing-plans -> build-flow -> finish-branch) and prevents rationalizing away skill usage.

Creates detailed, bite-sized implementation plans with TDD structure, exact file paths, complete code, and test commands. Use when you have a spec, requirements, design doc, or feature request and need to plan before coding — especially for multi-step tasks, large features, or when handing off to another session. DO NOT TRIGGER when asked to write code directly or fix a simple bug.

Enforces project-specific coding conventions by loading language standards before writing code. Use when about to write, edit, modify, or generate Go, Rust, Python, Tailwind CSS, or HCL (Terraform/OpenTofu) files. Loads once per language per session and overrides default style with project conventions. DO NOT TRIGGER for languages other than Go, Rust, Python, Tailwind CSS, or HCL (Terraform/OpenTofu).

Consults OpenAI Codex CLI for an independent perspective on any question. Shells out to the codex CLI in read-only sandbox mode and relays the response. Use when you want a second opinion from Codex, or when asked to "consult codex", "ask codex", or "codex oracle".

Creates a GitHub pull request for the current branch using the gh CLI. Use when asked to create a PR, open a pull request, submit changes for review, or push and create a PR. Defaults to draft, detects and fills repo PR templates, auto-detects the base branch, and supports 'ready for review' override. DO NOT TRIGGER for reviewing existing PRs or commenting on PRs.

Enforces systematic root-cause investigation before any fix attempt, using a four-phase process (investigate, analyze patterns, hypothesize, implement). Use when encountering bugs, test failures, build errors, unexpected behavior, performance problems, or integration issues — especially when under pressure, when a "quick fix" seems obvious, or when previous fix attempts have failed. DO NOT TRIGGER for new feature development or refactoring without a known defect.

Generates a categorized work summary from GitHub activity (PRs authored, issues created, code committed) for a given time period and organization, using parallel subagents for fast detail fetching. Use when the user asks "what did I work on", "what did I do last week", wants a work log, weekly update, standup notes, sprint recap, accomplishments list, performance review input, or any summary of their contributions. DO NOT TRIGGER for repository changelogs, release notes, or team-wide activity reports.

Coordinates parallel subagent dispatch to solve multiple independent problems concurrently, with structured prompts and conflict-free integration. Use when there are 2+ independent failures, bugs, tasks, or investigations that do not share state -- e.g. multiple test files failing for different reasons, unrelated subsystems broken, or batch tasks that can run simultaneously. DO NOT TRIGGER when failures are related, require shared context, or agents would edit the same files.

Enforces rigorous technical evaluation of code review feedback before implementation -- verifying suggestions against the codebase, pushing back when wrong, clarifying ambiguity, and avoiding performative agreement. Use when processing PR review comments, inline suggestions, change requests, reviewer feedback, or any list of code fixes to address. Applies to feedback from human partners and external reviewers alike. DO NOT TRIGGER when writing a review of someone else's code.

Enforces strict test-driven development -- write a failing test first, implement minimal code to pass, then refactor. Use when implementing a feature, fixing a bug, adding behavior, refactoring, or any time production code will be written or changed. Also use when the user says "write tests", "add tests", "TDD", or "test first". DO NOT TRIGGER for throwaway prototypes, generated code, or config-only changes unless the user explicitly requests TDD.

Enforces fresh verification evidence before any completion or success claims. Use when about to say "done", "fixed", "tests pass", "build succeeds", or any synonym; before committing, creating PRs, or moving to the next task; before expressing satisfaction or positive statements about work state; and after agent delegation to independently verify results. Prevents unverified claims by requiring command execution, output inspection, and exit code confirmation.

Removes git worktrees safely, cleans up associated branches, and pulls latest mainline after removal. Use when finished with a worktree, done with a branch, cleaning up after a merge or PR, abandoning work in a worktree, or when "git worktree list" shows stale entries. Checks for uncommitted changes, verifies no open PRs before branch deletion, and handles force-removal of locked worktrees.

Creates, edits, and tests Claude skill files (SKILL.md) using TDD methodology with baseline pressure testing and rationalization defense. Use when writing a new skill, modifying an existing skill, optimizing a skill description for discovery (CSO), testing whether a skill triggers correctly, or structuring skill documentation. Enforces RED-GREEN-REFACTOR for process documentation.