Kata Goal Delivery

Use Kata as the required durable coordination layer for a long-running goal. This skill requires the kata CLI and a Kata project bound to the workspace; if they are unavailable, initialize Kata when the project name is obvious or ask for the missing install/project decision. Do not silently substitute GitHub Issues, markdown plans, chat history, or TODO files as the tracker.

Kata is the source of truth for issue decomposition, ownership, state changes, comments, relationships, and close evidence. It is not a git hosting or PR system. Use the repository's normal branch, commit, or review workflow when available, but record durable progress, review proof, and final status in Kata. Include a PR URL only when the repository already requires one; the Kata issue and comments remain required.

Principles

• The user's overall objective is the goal; Kata is the durable state that survives handoffs.
• One child issue should be one independently implementable unit of work.
• Issues are context delivery. A fresh agent should be able to implement a child issue without hidden chat history.
• Relationships are scheduling data: use --parent for the tracker/child hierarchy and --blocked-by or --blocks for dependency order.
• Close discipline matters. A Kata close asserts completion; do not close attempted, partial, or unreviewed work.
• Close each verified child promptly. Do not save a batch of sibling closes for the end; Kata can throttle more than three sibling closes by one actor under one parent within 60 seconds.
• Keep the tracker parent authoritative: goal, shared context, issue graph, validation strategy, current-state comments, and final status.
• Keep changes small enough for deep review. For code work, sanity-check size by reviewer burden: roughly 500+ meaningful changed lines or changes spread across many files/ownership boundaries are signals to split or widen review.
• Do not add backward compatibility unless explicitly required by the user or tracker. Avoid shims, legacy framing, and constraints for hypothetical old integrations.
• Be willing to pursue a large goal when the plan is sound. Confidence must come from repo context, validation, Kata evidence, and review.