specs-to-tickets

仕様 → チケット

人間専用です。 人間が名前を指定して依頼した場合にのみ、これを開始してください。別のスキルからここに来た場合は、停止して、いずれかの手順を実行する前に明示的な確認を得てください。

/decisions-to-specs の後続工程です。このスキルでは、wayfinder マップの決定事項をリポジトリの仕様ファイルにまとめ、マップの ## Specs settled に記録しました。このスキルはその記録を読み、各仕様を Matt の /to-tickets に渡して実装チケットを作成します。

ここが、計画から構築へ移る境界です。決定事項と仕様の作成は完了しています。ここからは、トレーサーバレットチケットを作成し、/implement に進みます。

承認内容はトラッカーに記録してください。 手順 2 で確認したスコープと、手順 3 で決めた粒度は人間が決めるもので、どちらもこのセッションが終了した時点で失われます。approval-policy スキルに従って、指定された場所に記録してください。実行で決まった内容はマップに、1 つのスライスをどのように形作るかはチケットに記録し、仕様ファイルにメモとして残さないでください。

プロセス

1. マップと確定済みの仕様を読み込む

引数（issue の URL または番号）からマップを特定します。/decisions-to-specs が記載した ## Specs settled セクションを読みます。ここには、各仕様ファイルとその処置（new／updated／ADR）の一覧があります。

このセクションがない場合は、停止して、まず /decisions-to-specs <map> を実行するようユーザーに伝えてください。スライス対象となる確定済みの仕様がありません。

完了条件： 仕様ファイルとその処置の一覧がそろっていること。

2. スライス対象の範囲を確認する

仕様ファイルをユーザーに提示します。既定の対象は new と updated の仕様すべてです。ADR の行は除外してください。ADR は決定の理由を記録するものであり、実装可能な仕様ではないため、そこからは何もスライスしません。チケットを作成する前に、対象を確定してください。

完了条件： ユーザーがスライス対象の仕様を承認していること。

3. /to-tickets で各仕様をスライスする

まず、実行全体を通して使う粒度を一度だけ決めてください。 /to-tickets は独自の手順 3 で、スライスの境界に従うか、最小限のチケットを目指すかを尋ねます。仕様が 5 つあるときにこの質問を仕様ごとにするのでは、この手順が使いものになりません。ここで人間に一度だけ質問し、その回答をすべての呼び出しに渡して、再度質問されないようにしてください。

承認された仕様ごとに、/to-tickets <spec-path> を 1 つずつ実行し、決めた粒度を呼び出し時に指定します。残りの作業は /to-tickets に任せてください。垂直方向のトレーサーバレットスライス、ブロック関係、トラッカー（GitHub）への公開が行われます。ここでそのロジックを再実装しないでください。このスキルの役割は、適切な仕様を /to-tickets に渡すことだけです。

この手順から停止せずに連携できるよう、/to-tickets は skill-callable に設定されています。連携して呼び出してください。手法をここで言い換えないでください。

次の手順で使うため、作成された issue 番号を仕様ごとに、依存関係の順に控えておいてください。

完了条件： 承認されたすべての仕様について、人間が選んだ 1 つの粒度に従ってスライスされたチケットがトラッカーに作成されていること。

4. すべてのチケットをマップのサブイシューとしてリンクする

設計上、/to-tickets は親 issue に手を加えないため、リンクはこのスキルの役割です。リポジトリの issue トラッカーに関するドキュメント（docs/agents/issue-tracker.md）の Wayfinding operations を読み、子 issue をマップにリンクする方法に従ってください。ドキュメントに記載がない場合は、次のとおりです。

gh api --method POST repos/<owner>/<repo>/issues/<map>/sub_issues -F sub_issue_id=<ticket-db-id>

<ticket-db-id> はチケットの数値のデータベース ID（gh api repos/<owner>/<repo>/issues/<n> --jq .id）であり、#number ではありません。サブイシューが有効になっていない場合は、マップの本文にタスクリストを作成し、各チケット本文の先頭に Part of #<map> を追加してください。

マップの子 issue 一覧が構築順になるよう、ブロッカーを先にして依存関係の順にリンクしてください。issue に親は 1 つだけです。それがマップです。/to-tickets がチケット間に設定した関係は依存関係であり、そのまま維持してください。

これらのチケットはマップの構築バックログであり、wayfinder の子ではありません。ready-for-agent を付け、wayfinder:<type> ラベルは付けないでください。これにより、wayfinder のフロンティアを決定作業に限定できます。

完了条件： 手順 3 で作成したすべてのチケットが、マップのサブイシュー一覧に表示されていること。

5. チケットをマップに記録する

マップ本文に ## Tickets セクションを追加し、仕様ごとにグループ化します。それぞれの仕様の後に、その仕様から作成された実装チケット（名前＋リンク）を記載します。ステップ 4 のサブイシューリストは有効なリンクです。このセクションでは、そのリストでは表現できない仕様ごとのグループ分けを加えることで、マップから「意思決定 → 仕様 → チケット」までたどれるようにします。

## Tickets

- `src/<Package>/spec/<feature>.md` → #31, #32, #33
- `spec/<cross-cutting>.md` → #34, #35

完了条件： 分割したすべての仕様について、実装チケットがマップに記載されていること。

6. 報告する

仕様ごとに作成したチケットを一覧表示し、次のステップとして /implement を案内します。チケットごとに新しいコンテキストを使用し、ブロッカーを優先します。これらの実装チケットはビルドのバックログであり、wayfinder の意思決定イシューは根拠としてクローズ状態のままにすることをユーザーに伝えます。

このフローにおける位置づけ

/wayfinder → 意思決定イシュー → /decisions-to-specs → 仕様ファイル ＋ ## Specs settled → /specs-to-tickets → 仕様ごとの /to-tickets → GitHub の実装チケット → /implement。