to-tickets

チケット化

計画、仕様、会話をチケットのセットに分割します。各チケットはトレーサーバレット型の垂直スライスで、どのチケットがその着手をブロックするかを示します。

トリアージ用のラベルやトラッカーの慣例が必要なのに整っていない場合は、/setup-skills を実行してください。以下の宛先解決にはセットアップは不要です。

プロセス

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

会話のコンテキストにすでにある情報を使ってください。ユーザーが引数として参照先（仕様書のパス、課題番号、URL）を渡した場合は、それを取得して本文とコメントをすべて読んでください。

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

まだコードベースを調べていない場合は、現在のコードの状態を理解するために調べてください。チケットのタイトルと説明では、プロジェクトのドメイン用語集の語彙を使い、対象領域の ADR に従ってください。

実装を容易にするために、あらかじめコードをリファクタリングできる箇所を探してください。「変更を容易にしてから、容易な変更を行う」のが原則です。

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

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

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る狭い範囲の完全なパスとします。水平スライスではなく、垂直スライスにしてください。
• 完了したスライスは、それ単体でデモまたは検証が可能です。
• 各スライスは、新しいコンテキストウィンドウ1つに収まる規模にします。
• リファクタリングが必要な場合は、先に行ってください。

各チケットには、ブロッカーとなる依存関係を記載してください。つまり、着手前に完了している必要がある他のチケットです。ブロッカーのないチケットは、すぐに着手できます。

広範囲なリファクタリングは、垂直スライスの例外です。 広範囲なリファクタリングとは、列名の変更や共有シンボルの型変更など、コードベース全体に影響が広がり、単一の編集で多数の呼び出し箇所が壊れ、どの垂直スライスも CI をグリーンのまま完了できないような機械的変更を指します。無理にトレーサーバレットに分割せず、拡張・縮小の順に進めます。まず拡張として、新しい形式を古い形式と並行して追加し、何も壊れないようにします。次に、影響範囲に応じた単位（パッケージ単位、ディレクトリ単位）で呼び出し箇所を段階的に移行します。各移行チケットは拡張チケットにブロックされ、古い形式が引き続き存在するため、各バッチで CI をグリーンに保ちます。最後に縮小として、呼び出し元がなくなったら、すべての移行チケットにブロックされるチケットで古い形式を削除します。バッチ単体ではグリーンを保てない場合も、順序は維持したまま、すべてのバッチが最終的な統合・検証チケットにブロックされる共有の統合ブランチを使います。その場合、グリーンが保証されるのは統合・検証チケットのみです。

4. 各チケットの難易度を評価する

各チケットに難易度ティアと、担当者向けの推奨モデルを設定してください。推奨はあくまでヒントであり、必須ではありません。担当者が Claude Code、Cursor、または別の環境を使っている可能性があるため、ツールごとにモデルを記載し、必要に応じて代替できるようにします。

ティア	対象	推奨モデル
Heavy	インフラストラクチャ、デプロイ、移行、アーキテクチャ上の判断、セキュリティ境界、広範囲なリファクタリング、影響範囲がサブシステムをまたぐ作業	Opus（Claude Code）／Opus または利用可能な最も推論能力の高いモデル（Cursor）
Standard	一般的なプログラミングロジック：機能スライス、エンドポイント、コンポーネント、実質的な分岐を伴うバグ修正。デフォルトのティアであり、ほとんどのチケットが該当します	Sonnet（Claude Code）／Sonnet（Cursor）
Light	機械的で判断をあまり要しない作業：設定値の更新、文言の変更、影響範囲の小さい名前変更、既存テストを踏襲したテストの追加	Haiku（Claude Code）／claude-4.5-haiku-thinking（Cursor）

差分の大きさではなく、チケットで求められる判断の度合いを基準に評価してください。デプロイパイプラインの1行変更でも Heavy になり得ますし、既存のパターンに従う400行のコンポーネントは Standard です。2つのティアの中間にある場合は、上位のティアを選んでください。実行したチケットの大半が Heavy になった場合は、スライスの範囲が広すぎる可能性があります。ステップ3を見直してください。

5. 内訳を示す

提案する内訳を番号付きリストで提示します。各チケットについて、以下を示します。

• タイトル：内容が分かる簡潔な名前
• 難易度：段階と推奨モデル
• ブロック元：先に完了する必要がある他のチケット（ある場合）
• 提供するもの：このチケットによって実現するエンドツーエンドの動作

公開前に確認を求めないでください。 リストを示したら、すぐに公開します。「これでよさそうですか？」と確認のために一時停止しないでください。この実行で内訳の確認または承認を明示的に求められた場合に限り、先にユーザーと反復してから進めます。

6. チケットを公開する

公開先は確認せずに決めてください。 次の順に、内部で選択します。

1. 今回の実行で、ユーザーが GitHub、GitLab、ローカルの Markdown、または別のトラッカーへの公開を明示的に求めた場合：その公開先を使用します。
2. それ以外で、docs/agents/issue-tracker.md（/setup-skills によって作成されたもの）が存在し、トラッカーを指定している場合：それを使用します。
3. それ以外の場合：ローカルの Markdown。git remote を調べないでください。公開先の選択肢を提示しないでください。

チケットの内容はどちらの場合も同じです。異なるのはブロック関係の形式だけです。

• ローカルの Markdown → チケットごとに .scratch/<feature-slug>/tickets/<NN>-<slug>.md の下へ1ファイルずつ書き込みます。依存関係の順（ブロック元が先）に 01 から番号を付けます。各ファイルの「ブロック元」には、依存するチケットの番号とタイトルを記載します。チケットごとのファイルテンプレートを使用します。1ファイルにまとめず、チケットごとに1ファイル作成してください。
• 実際の課題トラッカー（GitHub、GitLab、Linear など） → 依存関係の順（ブロック元が先）に、チケットごとに課題を1件公開し、ブロック関係で実際の識別子を参照できるようにします。docs/agents/issue-tracker.md がある場合は、その指示に従います。プラットフォームにネイティブのブロック関係またはサブ課題関係がある場合はそれを使い、ない場合は各チケットの「ブロック元」にブロックする課題を記載します。既存の課題が元になっている場合は、トラッカードキュメントの手順に従い、各チケットをそのサブ課題として作成します。特に指示がない限り、トリアージラベル ready-for-agent を付けます。チケットはエージェントがすぐに着手できるように作成されるためです。

フロンティアを進めます。ブロック元がすべて完了したチケットが対象です。依存関係が単純な直列の場合は、上から順に進めます。

親課題をクローズしたり、変更したりしないでください。

# <NN>: <Ticket title>

> **Difficulty:** Heavy | Standard | Light: **suggested model:** <model> (Claude Code) / <model> (Cursor). Suggestion only, use whatever model you have to hand.

**Spec:** the path of the spec this ticket comes from, relative to this ticket file (with the default layout, `../SPEC.md`). Omit the line only when no spec file exists (the plan came from the conversation).

**What to build:** the end-to-end behaviour this ticket makes work, from the user's perspective, not a layer-by-layer implementation list.

**Seams:** the seams from the spec's Testing Decisions that this ticket exercises, one per bullet. If the ticket tests no seam (for example a pure config change), write "None" explicitly. Never leave the line out.

**Blocked by:** the numbers/titles of the tickets that gate this one, or "None (can start immediately)".

Status: ready-for-agent

- [ ] Acceptance criterion 1
- [ ] Acceptance criterion 2

難易度： Heavy | Standard | Light：推奨モデル： （Claude Code）／（Cursor）。あくまで提案です。手元にある任意のモデルを使用してください。

難易度の行は課題本文の先頭に置き、すべてのセクションより前に記載します。

親課題

トラッカー上の親課題への参照（既存の課題が元になっている場合。そうでなければ、このセクションは省略してください）。

作成するもの

レイヤーごとの実装ではなく、ユーザー視点で、このチケットによって実現するエンドツーエンドの動作を記載します。

接点

このチケットで検証する、仕様書の「テストの決定事項」にある接点を箇条書きで1つずつ記載します。接点をテストしないチケットでは、「なし」と明記します。このセクションは省略しないでください。

受け入れ条件

• 条件1
• 条件2

ブロック元

• ブロックする各チケットへの参照、または「なし（すぐに着手できます）」を記載します。ブロック関係をネイティブのエッジとして設定した場合は、このセクションを省略してください。

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