to-tickets

To Tickets

計画、仕様、会話を一連のチケットに分割します。各チケットは、トレーサーバレット方式の垂直スライスであり、それをブロックするチケットを明示します。

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

プロセス

1. コンテキストを収集する

会話のコンテキストにすでにある情報をもとに作業します。ユーザーが引数として参照情報（仕様へのパス、課題番号、URL）を渡した場合は、それを取得して本文とコメントをすべて読みます。

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

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

実装を容易にするため、コードを先にリファクタリングできる機会を探します。「変更を容易にしてから、容易な変更を行う」。

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

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

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る、狭くても完全な経路を切り出します。垂直スライスであり、単一レイヤーだけの水平スライスではありません。
• 完了したスライスは、それ単独でデモまたは検証が可能です。
• 各スライスは、新しいコンテキストウィンドウ1つに収まる規模にします。
• 先行するリファクタリングが必要な場合は、先に実施します。

各チケットにブロッカーの関係を付けます。つまり、着手前に完了している必要がある他のチケットを示します。ブロッカーのないチケットはすぐに着手できます。

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

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

各チケットに難易度ティアと、担当者向けの推奨モデルを設定します。推奨はあくまでヒントであり、必須ではありません。担当者は Claude Code、Cursor、または他のツールを使う可能性があるため、ツールごとにモデル名を示し、別のモデルに置き換えられるようにします。

ティア	該当する作業	推奨モデル
Heavy	インフラストラクチャ、デプロイ、移行、アーキテクチャ上の判断、セキュリティ境界、大規模なリファクタリング、影響範囲がサブシステムをまたぐ作業	Opus（Claude Code）／Opus、または Cursor で利用可能な最も推論能力の高いモデル
Standard	通常のプログラミングロジック：機能スライス、エンドポイント、コンポーネント、実際の分岐処理を含むバグ修正。デフォルトのティアであり、ほとんどのチケットが該当します	Sonnet（Claude Code）／Sonnet（Cursor）
Light	判断をほとんど必要としない機械的な作業：設定値の更新、文言の変更、影響範囲が小さい名前変更、既存のテストを模倣したテストの追加	Sonnet（Claude Code）／Sonnet（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

ブロック元

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

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