claude-kit

using-kit

Use when starting any conversation to establish skill discovery and usage patterns

team-orchestration

Use when setting up team-based workflows - required foundation before spawning teammates or creating shared task lists

receiving-review

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

code-standards

Load language-specific coding standards before editing Go, Rust, Python, or Tailwind CSS files

worktree-cleanup

Use when done with a git worktree and ready to clean it up — removes worktree, updates mainline branch, handles uncommitted changes gracefully

team-dev

Use when executing implementation plans with independent tasks in the current session

debugging

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

tdd

Use when implementing any feature or bugfix, before writing implementation code

git-worktrees

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

github-work-summary

Use when the user asks for a summary of their GitHub activity, work log, contributions, or accomplishments over a time period. Triggers include phrases like "what did I work on", "work summary", "weekly update", "standup notes", or requests for activity across an organization.

executing-plans

Use when you have a written implementation plan to execute in a separate session with review checkpoints

code-review

Use when verifying implementation work meets requirements, at review checkpoints or before integration

writing-plans

Use when you have a spec or requirements for a multi-step task, before touching code

writing-skills

Use when creating new skills, editing existing skills, or verifying skills work before deployment

parallel-agents

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

finish-branch

Use when implementation is complete, all tests pass, and the work needs to be integrated or finalized

verify

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

create-pr

Use when creating a pull request — defaults to draft PRs, uses repo PR template if available, supports "ready for review" override

brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.