kata-linear

Linear チケットのライフサイクル

このスキルは、汎用の /linear スキルを、構造化された開始／次／終了のワークフローでラップします。 このスキルを使用する際、実際の MCP 呼び出しには必ず /linear スキルを呼び出してください。

モードの判定

ユーザーのリクエストを解析し、実行するワークフローを判定します。

ユーザーの発言	モード
"start KAT-N", "pick up KAT-N", "implement KAT-N", "work on KAT-N"	開始
"finish KAT-N", "complete KAT-N", "done with KAT-N", "close KAT-N"	完了
"what's next", "what should I work on", "next ticket", "next issue"	次のチケット

曖昧な場合は、ユーザーに確認してください。

プロジェクトの特定

1. 現在の作業ディレクトリにある AGENTS.md で、Linear プロジェクトへの参照を確認します。
2. 見つからない場合は、list_projects を呼び出し、使用するプロジェクトをユーザーに確認します。
3. セッションの残りの間はプロジェクト名をキャッシュし、今後のために AGENTS.md を更新します。

---

モード：次のチケット

次に着手可能な課題を見つけます。

1. プロジェクトの state が Todo の課題を list_issues で検索します。
2. 結果がある場合は提示します。最初の Todo 課題を、次に選ぶ課題として推奨します。
3. Todo の課題がない場合は、ブロック関係を確認します。 a. プロジェクトの state が Backlog の課題を list_issues で検索します。 b. Backlog の各課題について、includeRelations: true を指定して get_issue を呼び出します。 c. blockedBy のすべての項目が Done である（またはブロッカーがない）課題を見つけます。
4. 候補が複数ある場合、分離された worktree で並行して作業できるか、次の 2 つの方法で判断します。 a. Linear チケットを再確認します（スコープとブロッカー）。 b. 変更対象となる現在のコードの境界を調べ、隠れた依存関係がないか確認します。
5. ブロックされていない課題を候補として提示し、並行作業に関する指針やリスクも含めます。
6. プロジェクトに Linear ドキュメント（実行モデル、ワークフロー契約）がある場合は、柱やフェーズの順序を把握するため、list_documents と get_document で取得します。

---

モード：開始

ステップ 1 — 課題を検証する

1. includeRelations: true を指定して、対象の課題を get_issue で取得します。
2. blockedBy の各項目を確認します。各ブロッカーのステータスが Done であることを確認します。
3. Done でないブロッカーがある場合は停止し、未解決のブロッカーを報告します。

ステップ 2 — In Progress に移動する

1. update_issue を呼び出して、state を In Progress に設定します。

ステップ 3 — コンテキストを読み込む

1. 課題の説明から、仕様、モック、ドキュメント、デザインファイルへの参照を確認します。
2. プロジェクト固有の指針を把握するため、Linear ドキュメント（実行モデル、ワークフロー契約）を読みます。
3. ステップ 1 と 2 で見つかった関連する仕様ファイル、モック画像、デザイン資料を読みます。
4. 課題で変更する領域の既存ソースコードを確認します。

ステップ 4 — フィーチャーブランチを作成する

1. 課題のレスポンスにある gitBranchName フィールドの値をブランチ名として使用します。
2. main ブランチからブランチを作成します。

ステップ 5 — 要約する

次の内容をユーザーに提示します。

• 課題のタイトルと受け入れ基準
• ブロッカーの状況（すべて解消済み）
• 読み込んだコンテキスト（仕様、モック、関連コード）
• 作成したブランチ名
• AGENTS.md に記載されたプロジェクト固有のワークフロー上の注意事項（例：TDD の必須要件）

---

モード：完了

ステップ 1 — 証拠を集める

次の証拠を集めます。

• PR のリンク、または変更を含むブランチ
• テスト結果（ユニットテストおよび／または E2E）
• 受け入れ基準を満たしていることを示すスクリーンショット／動画、または仕様の状態に関する参照

現在のブランチに PR がすでに存在する場合は、gh pr view で検出します。

ステップ 2 — 完了ゲートを検証する

プロジェクトの CLAUDE.md または Linear のワークフロー契約に、必須のゲートが定義されているか確認します。 一般的なゲートは次のとおりです。

• 参照されている仕様の状態や操作が検証済みである
• 証拠へのリンク（テスト、スクリーンショット、または追跡可能な PR のメモ）が添付されている
• ギャップ分析の項目が解決済みであるか、フォローアップの課題に分割されている
• 課題のチェックリストで、すべての受け入れ基準が検証済みとしてマークされている
• Definition of Done のチェックリストが完了している

証拠が不十分な場合は、不足しているものを列挙して停止します。

ステップ 3 — エビデンスをイシューと PR に添付する

1. イシューに対して create_comment を呼び出し、構造化されたエビデンスの概要を記載します。

   ## Completion Evidence
   - PR: [link]
   - Tests: [pass/fail summary]
   - Acceptance coverage: [which criteria verified]
   - Screenshots/video: [if applicable]
   

2. 同じ概要を PR にコメントとして追加します。

ステップ 4 — チェーン内の次の項目を進める

1. 完了したイシューに対して、includeRelations: true を指定して get_issue を呼び出します。
2. blocks リスト内の各イシューに対して、次の操作を行います。 a. 下流のイシューに対して、includeRelations: true を指定して get_issue を呼び出します。 b. そのイシューのすべての blockedBy エントリが Done になっているか確認します。 c. そうなっている場合は、update_issue を呼び出して Todo に変更します。 d. どのイシューを進めたか報告します。

（注：現在のチケットは、PR がマージされると自動的に Done に移行します）。

ステップ 5 — まとめる

次の内容を提示します。

• エビデンスへのリンクとともに Done にしたイシュー
• Todo に進めた下流のイシュー
• 次に推奨されるアクション

重要な注意事項

• ブロック依存関係を確認できるよう、get_issue の呼び出しでは常に includeRelations: true を指定してください。
• デザイン仕様とモックの信頼できる情報源として、常に添付メディアを参照してください。