kata

Add phase to end of current milestone in roadmap

Capture idea or task as todo from current conversation context

Audit milestone completion against original intent before archiving

Check project progress, show context, and route to next action (execute or plan)

List pending todos and select one to work on

Archive completed milestone and prepare for next version

Configure Kata workflow toggles and model profile

Systematic debugging with persistent state across context resets

Gather phase context through adaptive questioning before planning

Execute all plans in a phase with wave-based parallelization

Show available Kata commands and usage guide

Insert urgent work as decimal phase (e.g., 72.1) between existing phases

Surface Claude's assumptions about a phase approach before planning

Arguments: "$ARGUMENTS"

Start a new milestone cycle — update PROJECT.md and route to requirements

Initialize a new project with deep context gathering and PROJECT.md

Create context handoff when pausing work mid-phase

Create phases to close all gaps identified by milestone audit

Arguments: "$ARGUMENTS"

Execute a quick task with Kata guarantees (atomic commits, state tracking) but skip optional agents

Remove a future phase from roadmap and renumber subsequent phases

Research how to implement a phase (standalone - usually use /kata:phase-plan instead)

Resume work from previous session with full context restoration

Run a comprehensive pull request review using multiple specialized agents

Switch model profile for Kata agents (quality/balanced/budget)

Validate built features through conversational UAT

See what's new in Kata since your installed version

Use this agent when you need to review code for adherence to project guidelines, style guides, and best practices. This agent should be used proactively after writing or modifying code, especially before committing changes or creating pull requests. It will check for style violations, potential issues, and ensure code follows the established patterns in CLAUDE.md. Also the agent needs to know which files to focus on for the review. In most cases this will recently completed work which is unstaged in git (can be retrieved by doing a git diff). However there can be cases where this is different, make sure to specify this as the agent input when calling the agent. Examples: <example> Context: The user has just implemented a new feature with several TypeScript files. user: "I've added the new authentication feature. Can you check if everything looks good?" assistant: "I'll use the Task tool to launch the code-reviewer agent to review your recent changes." <commentary> Since the user has completed a feature and wants validation, use the code-reviewer agent to ensure the code meets project standards. </commentary> </example> <example> Context: The assistant has just written a new utility function. user: "Please create a function to validate email addresses" assistant: "Here's the email validation function:" <function call omitted for brevity> assistant: "Now I'll use the Task tool to launch the code-reviewer agent to review this implementation." <commentary> Proactively use the code-reviewer agent after writing new code to catch issues early. </commentary> </example> <example> Context: The user is about to create a PR. user: "I think I'm ready to create a PR for this feature" assistant: "Before creating the PR, I'll use the Task tool to launch the code-reviewer agent to ensure all code meets our standards." <commentary> Proactively review code before PR creation to avoid review comments and iterations. </commentary> </example>

You are an expert code simplification specialist focused on enhancing code clarity, consistency, and maintainability while preserving exact functionality. Your expertise lies in applying project-specific best practices to simplify and improve code without altering its behavior. You prioritize readable, explicit code over overly compact solutions. This is a balance that you have mastered as a result your years as an expert software engineer.

Explores codebase and writes structured analysis documents. Spawned by project-analyze with a focus area (tech, arch, quality, concerns). Writes documents directly to reduce orchestrator context load.

Use this agent when you need to analyze code comments for accuracy, completeness, and long-term maintainability. This includes: (1) After generating large documentation comments or docstrings, (2) Before finalizing a pull request that adds or modifies comments, (3) When reviewing existing comments for potential technical debt or comment rot, (4) When you need to verify that comments accurately reflect the code they describe. <example> Context: The user is working on a pull request that adds several documentation comments to functions. user: "I've added documentation to these functions. Can you check if the comments are accurate?" assistant: "I'll use the comment-analyzer agent to thoroughly review all the comments in this pull request for accuracy and completeness." <commentary> Since the user has added documentation comments and wants them checked, use the comment-analyzer agent to verify their accuracy against the actual code. </commentary> </example> <example> Context: The user just asked to generate comprehensive documentation for a complex function. user: "Add detailed documentation for this authentication handler function" assistant: "I've added the documentation. Now let me use the comment-analyzer agent to verify that the comments are accurate and helpful for long-term maintenance." <commentary> After generating large documentation comments, proactively use the comment-analyzer to ensure quality. </commentary> </example> <example> Context: The user is preparing to create a pull request with multiple code changes and comments. user: "I think we're ready to create the PR now" assistant: "Before creating the pull request, let me use the comment-analyzer agent to review all the comments we've added or modified to ensure they're accurate and won't create technical debt." <commentary> Before finalizing a PR, use the comment-analyzer to review all comment changes. </commentary> </example>

Investigates bugs using scientific method, manages debug sessions, handles checkpoints. Spawned by /kata:debug-issue orchestrator.

Generates semantic entity documentation for codebase files. Spawned by analyze-codebase with file list. Writes entities directly to disk.

Executes Kata plans with atomic commits, deviation handling, checkpoint protocols, and state management. Spawned by phase-execute orchestrator or execute-plan command.

Use this agent when reviewing code changes in a pull request to identify silent failures, inadequate error handling, and inappropriate fallback behavior. This agent should be invoked proactively after completing a logical chunk of work that involves error handling, catch blocks, fallback logic, or any code that could potentially suppress errors. Examples: <example> Context: Daisy has just finished implementing a new feature that fetches data from an API with fallback behavior. Daisy: "I've added error handling to the API client. Can you review it?" Assistant: "Let me use the failure-finder agent to thoroughly examine the error handling in your changes." <Task tool invocation to launch failure-finder agent> </example> <example> Context: Daisy has created a PR with changes that include try-catch blocks. Daisy: "Please review PR #1234" Assistant: "I'll use the failure-finder agent to check for any silent failures or inadequate error handling in this PR." <Task tool invocation to launch failure-finder agent> </example> <example> Context: Daisy has just refactored error handling code. Daisy: "I've updated the error handling in the authentication module" Assistant: "Let me proactively use the failure-finder agent to ensure the error handling changes don't introduce silent failures." <Task tool invocation to launch failure-finder agent> </example>

Verifies cross-phase integration and E2E flows. Checks that phases connect properly and user workflows complete end-to-end.

Researches how to implement a phase before planning. Produces RESEARCH.md consumed by kata-planner. Spawned by /kata:plan-phase orchestrator.

Verifies plans will achieve phase goal before execution. Goal-backward analysis of plan quality. Spawned by /kata:plan-phase orchestrator.

Creates executable phase plans with task breakdown, dependency analysis, and goal-backward verification. Spawned by /kata:plan-phase orchestrator.

Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Examples: <example> Context: Daisy has just created a pull request with new functionality. user: "I've created the PR. Can you check if the tests are thorough?" assistant: "I'll use the pr-test-analyzer agent to review the test coverage and identify any critical gaps." <commentary> Since Daisy is asking about test thoroughness in a PR, use the Task tool to launch the pr-test-analyzer agent. </commentary> </example> <example> Context: A pull request has been updated with new code changes. user: "The PR is ready for review - I added the new validation logic we discussed" assistant: "Let me analyze the PR to ensure the tests adequately cover the new validation logic and edge cases." <commentary> The PR has new functionality that needs test coverage analysis, so use the pr-test-analyzer agent. </commentary> </example> <example> Context: Reviewing PR feedback before marking as ready. user: "Before I mark this PR as ready, can you double-check the test coverage?" assistant: "I'll use the pr-test-analyzer agent to thoroughly review the test coverage and identify any critical gaps before you mark it ready." <commentary> Daisy wants a final test coverage check before marking PR ready, use the pr-test-analyzer agent. </commentary> </example>

Researches domain ecosystem before roadmap creation. Produces files in .planning/research/ consumed during roadmap creation. Spawned by /kata:new-project or /kata:new-milestone orchestrators.

Synthesizes research outputs from parallel researcher agents into SUMMARY.md. Spawned by /kata:new-project after 4 researcher agents complete.

Creates project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation. Spawned by /kata:new-project orchestrator.

Use this agent when reviewing code changes in a pull request to identify silent failures, inadequate error handling, and inappropriate fallback behavior. This agent should be invoked proactively after completing a logical chunk of work that involves error handling, catch blocks, fallback logic, or any code that could potentially suppress errors. Examples: <example> Context: Daisy has just finished implementing a new feature that fetches data from an API with fallback behavior. Daisy: "I've added error handling to the API client. Can you review it?" Assistant: "Let me use the silent-failure-hunter agent to thoroughly examine the error handling in your changes." <Task tool invocation to launch silent-failure-hunter agent> </example> <example> Context: Daisy has created a PR with changes that include try-catch blocks. Daisy: "Please review PR #1234" Assistant: "I'll use the silent-failure-hunter agent to check for any silent failures or inadequate error handling in this PR." <Task tool invocation to launch silent-failure-hunter agent> </example> <example> Context: Daisy has just refactored error handling code. Daisy: "I've updated the error handling in the authentication module" Assistant: "Let me proactively use the silent-failure-hunter agent to ensure the error handling changes don't introduce silent failures." <Task tool invocation to launch silent-failure-hunter agent> </example>

Use this agent when you need expert analysis of type design in your codebase. Specifically use it: (1) when introducing a new type to ensure it follows best practices for encapsulation and invariant expression, (2) during pull request creation to review all types being added, (3) when refactoring existing types to improve their design quality. The agent will provide both qualitative feedback and quantitative ratings on encapsulation, invariant expression, usefulness, and enforcement. <example> Context: Daisy is writing code that introduces a new UserAccount type and wants to ensure it has well-designed invariants. user: "I've just created a new UserAccount type that handles user authentication and permissions" assistant: "I'll use the type-design-analyzer agent to review the UserAccount type design" <commentary> Since a new type is being introduced, use the type-design-analyzer to ensure it has strong invariants and proper encapsulation. </commentary> </example> <example> Context: Daisy is creating a pull request and wants to review all newly added types. user: "I'm about to create a PR with several new data model types" assistant: "Let me use the type-design-analyzer agent to review all the types being added in this PR" <commentary> During PR creation with new types, use the type-design-analyzer to review their design quality. </commentary> </example>

Verifies phase goal achievement through goal-backward analysis. Checks codebase delivers what phase promised, not just that tasks completed. Creates VERIFICATION.md report.

Use this skill when adding a milestone to an existing project, starting a new milestone cycle, creating the first milestone after project init, or defining what's next after completing work. Triggers include "add milestone", "new milestone", "start milestone", "create milestone", "first milestone", "next milestone", and "milestone cycle".

Use this skill to add planned work discovered during execution to the end of the current milestone in the roadmap. This skill appends sequential phases to the current milestone's phase list, automatically calculating the next phase number. Triggers include "add phase", "append phase", "new phase", and "create phase". This skill updates ROADMAP.md and STATE.md accordingly.

Use this skill to capture an idea, task, or issue that surfaces during a Kata session as a structured todo for later work. This skill creates markdown todo files in the .planning/todos/pending directory with relevant metadata and content extracted from the conversation. Triggers include "add todo", "capture todo", "new todo", and "create todo".

Use this skill to verify milestone achievement against its definition of done, checking requirements coverage, cross-phase integration, and end-to-end flows. Triggers include "audit milestone", "verify milestone", "check milestone", and "milestone audit". This skill reads existing phase verification files, aggregates technical debt and gaps, and spawns an integration checker for cross-phase wiring.

Use this skill when reviewing pending todos, selecting a todo to work on, filtering todos by area, or deciding what to work on next. Triggers include "check todos", "list todos", "what todos", "pending todos", "show todos", "view todos", and "select todo to work on".

Use this skill when archiving a completed milestone, preparing for the next version, marking a milestone complete, shipping a version, or wrapping up milestone work. Triggers include "complete milestone", "finish milestone", "archive milestone", "ship version", "mark milestone done", "milestone complete", "release version", "create release", and "ship milestone".

Use this skill when configure kata workflow toggles and model profile. Triggers include "settings".

Use this skill when systematically debugging issues, investigating bugs, troubleshooting problems, or tracking down errors with persistent state across context resets. Triggers include "debug", "investigate bug", "troubleshoot", "find the problem", "why isn't this working", and "debug session".

Use this skill when gathering phase context through adaptive questioning before planning, clarifying implementation decisions, or exploring gray areas for a phase. Triggers include "discuss phase", "clarify phase", "gather context", "what are the gray areas", and "phase discussion".

Use this skill when executing all plans in a phase with wave-based parallelization, running phase execution, or completing phase work. Triggers include "execute phase", "run phase", "execute plans", "run the phase", and "phase execution".

Use this skill when executing small ad-hoc tasks with Kata guarantees, running quick tasks without full planning, or handling one-off work outside the roadmap. Triggers include "quick task", "quick mode", "quick fix", "ad-hoc task", "small task", and "one-off task".

Use this skill when inserting urgent work as a decimal phase between existing phases, adding mid-milestone work, or creating intermediate phases. Triggers include "insert phase", "add urgent phase", "create decimal phase", "insert between phases", and "urgent work".

Use this skill when surfacing Claude's assumptions about a phase approach before planning, checking what Claude thinks, or validating understanding before planning. Triggers include "list assumptions", "what are you thinking", "show assumptions", "phase assumptions", and "what's the plan".

Use this skill when analyzing an existing codebase with parallel mapper agents, creating codebase documentation, understanding brownfield projects, or mapping code structure. Triggers include "map codebase", "analyze codebase", "document codebase", "understand code", and "codebase map".

Use this skill when creating a context handoff file, pausing work mid-phase, stopping work temporarily, or creating a checkpoint for session resumption. Triggers include "pause work", "stop work", "create handoff", "save progress", and "pause session".

Use this skill when create phases to close all gaps identified by milestone audit. Triggers include "plan milestone gaps", "plan gaps".

Use this skill to plan detailed roadmap phases. Triggers include "plan phase n", "create phase plan", "create a plan" "roadmap planning", and "roadmap phase creation".

Use this skill when showing available Kata commands, displaying the usage guide, explaining command reference, or when the user asks for help with Kata. Triggers include "help", "show commands", "list commands", "what commands", "kata commands", and "usage guide".

Use this skill when remove a future phase from roadmap and renumber subsequent phases. Triggers include "remove phase", "remove phase".

Use this skill when researching how to implement a phase standalone, investigating implementation approaches before planning, or re-researching after planning is complete. Triggers include "research phase", "investigate phase", "how to implement", "research implementation", and "phase research".

Use this skill when resuming work from a previous session, restoring context after a break, continuing work after /clear, or picking up where you left off. Triggers include "resume work", "continue work", "pick up where I left off", "restore context", and "resume session".

Use this skill to run a comprehensive pull request review using multiple specialized agents. Each agent focuses on a different aspect of code quality, such as comments, tests, error handling, type design, and general code review. The skill aggregates results and provides a clear action plan for improvements. Triggers include "review PR", "analyze pull request", "code review", and "PR quality check".

Use this skill when switch model profile for kata agents (quality/balanced/budget). Triggers include "set profile", "set profile".

Use this skill when showing what's new in Kata since the installed version, displaying changelog entries, checking for Kata updates, or reviewing recent changes. Triggers include "what's new", "whats new", "show changes", "changelog", "recent changes", and "what changed".

Use this skill when initialize a new project with deep context gathering and project.md. Triggers include "new project", "start project", "initialize project", "create project", "begin project", "setup project".

Use this skill when check project progress, show context, and route to next action (execute or plan). Triggers include "progress".

Use this skill when validating built features through conversational testing, running UAT, user acceptance testing, checking if features work, or verifying implementation. Triggers include "verify work", "test features", "UAT", "user testing", "check if it works", and "validate features".

1 hook across 1 event