claude-kit

code-standards

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

using-kit

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 -> team-dev -> finish-branch) and prevents rationalizing away skill usage.

team-orchestration

Creates and coordinates teams of persistent AI teammates with shared task lists, messaging, and lifecycle management. Use when spawning teammates, creating a team, setting up reviewers or implementers, coordinating multi-agent work, or any skill references "kit:team-orchestration". Provides the scaffolding for TeamCreate, teammate spawning, task dependencies, SendMessage communication, and graceful shutdown.

team-dev

Executes implementation plans using a persistent team of implementer and reviewers within the current session, with batch-boundary code reviews for quality. Use when you have an implementation plan with independent tasks to execute, need to build or implement a feature from a plan, or the user says "execute the plan", "implement this", "start building", or "team dev". DO NOT TRIGGER when there is no plan yet (use brainstorming first) or when tasks require parallel separate sessions (use executing-plans instead).

receiving-review

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.

debugging

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.

worktree-cleanup

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.

git-worktrees

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.

tdd

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.

code-review

Orchestrates plan-alignment and quality reviews using persistent or ad-hoc reviewer teammates. Use when verifying implementation matches requirements, at batch review checkpoints, before merging to main, after completing a major feature, before refactoring, after fixing a complex bug, or when a fresh perspective is needed. Spawns specialist reviewers (spec, quality, security, architecture) in parallel and consolidates findings.

executing-plans

Coordinates batch execution of a written implementation plan by spawning implementer and reviewer teammates, executing tasks in batches with automated review gates, and pausing for human feedback between batches. Use when handed a plan file to execute, resuming plan work in a new session, or running a standalone plan outside the brainstorming flow. DO NOT TRIGGER for same-session execution after brainstorming — use kit:team-dev instead.

github-work-summary

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.

writing-plans

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.

writing-skills

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.

parallel-agents

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.

finish-branch

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.

verify

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.

create-pr

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.

brainstorming

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.