to-tickets

tickets に分割する

plan、spec、または conversation を tickets のセットに分割します。各 ticket は tracer-bullet の垂直スライスとし、block する tickets を明記します。

Issue tracker と triage label の語彙は、すでに用意されているはずです。用意されていない場合は、ユーザーに /setup-matt-pocock-skills を実行してもらってください。

手順

1. context を収集する

conversation context にすでにある内容を使います。ユーザーが reference（spec path、issue number、URL）を引数として渡した場合は、その body と comments を取得してすべて読みます。

2. codebase を調べる（任意）

まだ codebase を調べていない場合は、まず code の現在の状態を把握します。Ticket の title と description には、プロジェクトの domain glossary の語彙を使い、関連する ADR に従います。

prefactor code を探し、implementation を容易にする機会を見つけます。「変更を容易にしてから、容易になった変更を行う」。

3. vertical slices を下書きする

作業を tracer bullet tickets に分割します。

• 各 slice は schema、API、UI、tests のすべての層を通る、狭くても完全な経路にします。vertical slice でなければならず、単一層の horizontal slice にはしません
• 完了した slice は単独でデモまたは検証できるものにします
• 各 slice は新しい context window に収まるサイズにします
• 先に prefactoring をすべて完了させます

各 ticket の blocking edges を示します。つまり、その ticket を開始する前に完了していなければならない他の tickets です。blockers のない ticket はすぐに開始できます。

大規模なリファクタリングは、vertical slicing の例外です。 大規模なリファクタリングとは、カラム名の変更や共有シンボルの型の変更など、codebase 全体に影響する機械的な変更です。1 回の編集で数千もの call sites が壊れ、どの vertical slice も単独で green を維持できません。無理に tracer bullet にせず、expand–contract の順序で進めます。まず expand：旧形式と並行して新形式を追加し、すべてが正常に動作する状態を保ちます。次に、blast radius に応じて call sites を複数の単位（package、directory など）に分けて移行します。各単位を 1 つの ticket とし、expand にブロックさせます。旧形式は残っているため、各バッチで CI は green を維持します。最後に contract：caller が残っていないことを確認したら、すべての migrate batches にブロックされる ticket で旧形式を削除します。個別のバッチでさえ green を維持できない場合も、この順序は保ちますが、共通の integration branch を使い、最後の integrate-and-verify ticket にすべてをブロックさせます。green を保証するのは最後の段階だけです。

4. ユーザーに手早く確認する

提案する分割を番号付きリストで提示します。各 ticket には次の内容を含めます。

• Title：簡潔で説明的な名前
• Blocked by：先に完了する必要がある他の tickets（ある場合）
• What it delivers：この ticket が実現する end-to-end behaviour

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

• Granularity は適切ですか（大きすぎる、または細かすぎる）？
• Blocking edges は正しいですか。各 ticket は本当に開始の条件となる tickets にのみ依存していますか？
• tickets をさらに統合、または分割する必要はありますか？

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

5. 設定済みの tracker に tickets を公開する

承認された tickets を公開します。具体的な方法は /setup-matt-pocock-skills で設定した tracker によって異なります。tickets の内容は同じですが、blocking edges の表現方法は異なります。

• Local files → .scratch/<feature-slug>/issues/<NN>-<slug>.md に ticket ごとに 1 つのファイルを作成します。dependency order（blockers を先に）で 01 から番号を付けます。各ファイルの「Blocked by」には、依存先の number/title を記載します。以下の per-ticket template を使います。各ファイルには ticket を 1 つだけ記載し、combined file には絶対にまとめないでください。
• 実際の issue tracker（GitHub、Linear など） → dependency order（blockers を先に）で ticket ごとに 1 つの issue を公開し、blocking edges が実際の identifiers を参照できるようにします。プラットフォームが対応している場合は、ネイティブの blocking/sub-issue relationship を使います。対応していない場合は、各 ticket の「Blocked by」に blocking issues を記載します。別途指示がない限り、ready-for-agent triage label を付けます。これらの tickets は、最初から agent が担当できる状態です。

frontier を扱います。つまり、すべての blockers が完了している tickets です。単純な linear chain なら、上から順に進みます。

親 issue を close したり変更したりしないでください。

:

What to build: 層ごとの implementation の一覧ではなく、この ticket によってユーザーの視点から実現する end-to-end behaviour。

Blocked by: この ticket の開始を妨げる numbers/titles、または「None（can start immediately）」。

Status: ready-for-agent

• Acceptance criterion 1
• Acceptance criterion 2

Parent

Tracker 上の親 issue の reference（既存の issue が情報源の場合。そうでなければこの section は省略）。

What to build

層ごとの implementation ではなく、この ticket によってユーザーの視点から実現する end-to-end behaviour。

Acceptance criteria

• Criterion 1
• Criterion 2

Blocked by

• blocking ticket ごとの reference、または「None（can start immediately）」。

どちらの形式でも、具体的な file paths や code snippets は避けてください。すぐに古くなるためです。例外として、prototype で作成した snippet が prose よりも正確に decision（state machine、reducer、schema、type shape）を表現している場合は、prototype に由来することを簡潔に説明したうえで inline に含めてもかまいません。decision を明確に表す部分だけを残し、動作する demo は含めないでください。