to-tickets

チケットへの分割

計画、仕様、会話を複数のチケットに分割します。各チケットはトレーサーバレット方式の垂直スライスで、作業をブロックするチケットを明示します。これらのチケットを epic-runner が取り込みます。作業はフロンティアを一度に1件ずつ進めるため、ここで設定したブロック関係が実際の作業順序になります。

トラッカー。 リポジトリ内のエンジニアスキルと同じ場所にある TRACKER.md を読みます。そこにはトラッカー、そのコマンド、このリポジトリのラベル文字列の意味が記載されています。ファイルがない場合は、ユーザーから提供された情報、Git リモート、インストール済みで認証も済んでいる CLI から、この実行で使うトラッカーを特定します。特定できない場合は、ローカルの Markdown ファイルを置くディレクトリを既定で使用します。

エンジニアスキルのディレクトリはハーネスごとに異なるため、glob で探します。

ls */skills/*-engineer/TRACKER.md .*/skills/*-engineer/TRACKER.md 2>/dev/null

プロセス

1. コンテキストを集める

会話のコンテキストにすでにある情報をもとに進めます。ユーザーが引数として参照先（仕様のパス、イシュー番号、URL）を渡した場合は、その内容を取得し、本文とコメントをすべて読みます。

2. コードベースを調査する（任意）

まだコードベースを調査していない場合は、現在のコードの状態を把握するために調査します。チケットのタイトルと説明には、プロジェクトのドメイン用語集の語彙を使い、変更対象の領域に関する ADR に従います。

実装を容易にするために、事前にコードを整える機会がないか探します。「変更を容易にしてから、容易な変更を行う。」

3. 垂直スライスを作成する

作業をトレーサーバレット形式のチケットに分割します。

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る、狭くても完全な経路を作ります。垂直スライスであり、単一レイヤーの水平スライスではありません。
• 完了したスライスは、それ単独でデモまたは検証できます。
• 各スライスは、単一の新しいコンテキストウィンドウに収まる規模にします。
• 事前のコード整備は、先に行います。

各チケットにブロック関係を設定します。つまり、着手前に完了していなければならない他のチケットを指定します。ブロックするチケットがないチケットは、すぐに着手できます。

広範なリファクタリングは、垂直スライスの例外です。 広範なリファクタリングとは、列の名前変更や共有シンボルの型変更など、コードベース全体に影響が広がる単一の機械的な変更です。1か所の編集で何千もの呼び出し箇所が一度に壊れ、垂直スライスを単独で正常に取り込めない場合が該当します。これを無理にトレーサーバレットに分割せず、拡張–縮小の順序で進めます。まず拡張として、既存の形式を壊さないよう、新しい形式を古い形式と並行して追加します。次に、影響範囲に応じた規模（パッケージ単位、ディレクトリ単位）で呼び出し箇所を段階的に移行します。各段階をそれぞれチケットにし、拡張チケットによってブロックします。古い形式を残すことで、段階ごとに CI を成功させます。最後に縮小として、すべての移行チケットによってブロックされるチケットで、呼び出し箇所がなくなった古い形式を削除します。各段階だけでは正常な状態を維持できない場合も、順序は保ったまま、それらを統合ブランチで進めます。各段階が最終的な統合・検証チケットをブロックし、正常な状態はそのチケットでのみ保証されます。

4. ユーザーに確認する

提案する分割を番号付きリストで提示します。各チケットには、次の内容を示します。

• タイトル：短く説明的な名前
• ブロック関係：先に完了していなければならない他のチケット（あれば）
• 提供するもの：このチケットによって実現する、エンドツーエンドの動作

ユーザーに次の点を確認します。

• 粒度は適切ですか？（粗すぎる／細かすぎる）
• ブロック関係は正しいですか？各チケットは、本当に着手を妨げるチケットだけに依存していますか？
• チケットを統合したり、さらに分割したりすべきものはありますか？

ユーザーが分割を承認するまで、調整を繰り返します。

5. チケットをトラッカーに公開する

承認済みのチケットを公開します。方法はトラッカーによって異なります。チケット自体はどちらの場合も同じで、変わるのはブロック関係の表し方だけです。

• ローカルファイル → TRACKER.md で指定されたディレクトリに、チケットごとに1つのファイルを作成します。指定がない場合は .scratch/<feature-slug>/issues/<NN>-<slug>.md とし、依存関係の順（ブロッカーを先）に 01 から番号を付けます。各ファイルの「Blocked by」には、そのチケットが依存するチケットの番号／タイトルを記載します。以下のチケット別ファイル用テンプレートを使い、チケットごとに1ファイル作成してください。1つにまとめたファイルにはしないでください。
• 実際の課題トラッカー（GitHub、GitLab、Jira、Linear など） → ブロッカーを先に、依存関係の順でチケットごとに1件の課題を公開し、各チケットのブロック関係に実際の識別子を参照できるようにします。プラットフォームにネイティブのブロック関係／サブ課題の関係がある場合はそれを使い、ない場合は各チケットの「Blocked by」にブロックする課題を設定します。指示がない限り、エージェント向けの作業として TRACKER.md で指定されたラベルを付けます。チケットは作成時点でエージェントが着手できる状態です。そのようなラベルが指定されていない場合は、ラベル付けを省略し、その旨を伝えてください。

フロンティアに取り組みます。ブロッカーがすべて完了しているチケットが対象です。依存関係が単純な直列の場合は、上から順に進めます。

親課題をクローズしたり、変更したりしてはいけません。

6. 一連のチケットをまとめて参照できるようにする

個々のチケットは、後続のオーケストレーターが取得できる単位ではありません。epic-runner は参照を1つ受け取り、その下にチケットを列挙します。そのため最後に、チケット一式をまとめて参照できるようにし、その参照先をユーザーに伝えます。

• ローカルファイル → チケットファイルと同じ場所に <dir>/issues.md というチェックリストを作成し、依存関係の順に各チケットのファイル名を記載した - [ ] 行を1つずつ追加します。このチェックリストが一括参照先となり、詳細はチケットごとのファイルに記載します。
• 実際のトラッカー → マイルストーン、共通ラベル、親の追跡課題、Jira エピックなど、そのトラッカーにある任意のコンテナーの下に課題をまとめます。どれを使ったかを伝えます。

次のように、参照先を明確に記載します。例：「/epic-runner .scratch/csv-export/issues/issues.md を実行してください」。この文字列を伝えることが、この手順の目的です。

—

作成するもの： このチケットによって実現する、ユーザー視点でのエンドツーエンドの動作。レイヤーごとの実装項目ではありません。

ブロック元： このチケットの前提となるチケットの番号／タイトル、または「なし — すぐに着手できます」。

ステータス： ready-for-agent

• 受け入れ条件1
• 受け入れ条件2

親課題

トラッカー上の親課題への参照（既存の課題を元にした場合。そうでない場合はこのセクションを省略します）。

作成するもの

このチケットによって実現する、ユーザー視点でのエンドツーエンドの動作。レイヤーごとの実装項目ではありません。

受け入れ条件

• 条件1
• 条件2

ブロック元

• ブロックするチケットへの参照、または「なし — すぐに着手できます」。

どちらの形式でも、具体的なファイルパスやコードスニペットは避けてください。すぐに古くなるためです。例外として、プロトタイプで作成したスニペットが、文章よりも正確に決定事項（ステートマシン、リデューサー、スキーマ、型の形状など）を表している場合は、インラインで記載し、プロトタイプ由来であることを簡潔に注記してください。決定事項の要点だけに絞り、動作するデモではなく重要な部分だけを残してください。

---

mattpocock/skills を参考にしています。MIT © 2026 Matt Pocock。このファイルをコピーする場合は、この行を残してください。