to-issues

name	to-issues
description	Plan・仕様・PRD を曳光弾（縦スライス）に分け、それぞれ独立して着手できる Issue にする。「issue化して」「issueに分割して」と指示されたとき。

To Issues

Plan を縦スライス（曳光弾）に分け、それぞれ独立して着手できる Issue にする。

Issue の置き場は GitHub Issues。gh CLI を使う（リポジトリはローカルの git remote から解決される）。

貫く原則：コールドスタート再現性

各 Issue は 会話履歴を一切持たない別セッションの実装者 が読む前提で書く。判断基準は一文:

この Issue だけ読んで、別セッションが意図と判断を再構築できるか。ただし陳腐化する実装詳細はコードに委ねる。

「詳細に書く」と「簡潔に保つ」は対立しない。書くべき詳細（目的・WHY、却下した代替案とその理由、前提・制約・スコープ境界、受け入れ基準）と、書かない詳細（具体的なファイルパス・コードスニペット・レイヤーごとの実装手順）を分ける。

手順

1. 材料を集める

会話の文脈にあるものをそのまま使う。ユーザーが Issue の参照（番号・URL・パス）を引数で渡してきたら、Issue トラッカーから取得し、本文とコメントをすべて読む。

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

まだ調べていなければ、現在のコードの状態を把握する。Issue のタイトル・説明はプロジェクトの用語集の語彙を使い、触れる領域の ADR に従う。

3. 縦スライスの案を作る

Plan を曳光弾の Issue に分ける。各 Issue は、すべての統合レイヤーを端から端まで貫く薄い縦スライスにする。1つのレイヤーだけを切り取る横スライスにしてはならない。

スライスには HITL と AFK がある。HITL はアーキテクチャの決定や設計レビューなど、人間とのやり取りが要るもの。AFK は人間を介さず実装・マージできるもの。可能なら AFK を選ぶ。

- 各スライスは、狭くてもすべてのレイヤー（スキーマ・API・UI・テスト）を貫く**完結した**経路を届ける - 完了したスライスは、それ単体でデモまたは検証ができる - 厚いスライスを少数作るより、薄いスライスを多数作る

4. ユーザーに確認する

分割案を番号付きリストで提示する。各スライスについて次を示す。

• タイトル：短く内容が分かる名前
• 種別：HITL / AFK
• ブロッカー：先に完了している必要がある他のスライス（あれば）
• 対応するユーザーストーリー：元の資料にあれば、どのストーリーを満たすか

そのうえでユーザーに問う。

• 粒度は妥当か（粗すぎ／細かすぎ）
• 依存関係は正しいか
• 統合または分割すべきスライスはあるか
• HITL / AFK の割り当ては正しいか

ユーザーが分割案を承認するまで繰り返す。

5. Issue を登録する

承認された各スライスを、下の本文テンプレートで Issue として登録する。

Plan の「実装フロー（使用するSkill）」を各 Issue に必ず転記する（そのスライスが実際に触れる種別の Skill だけに絞る）。これは「issue NNN 対応して」だけで開発フローを自動追従させるための情報なので、issue 化で落とさないこと。Plan に同セクションが無ければ、変更種別から CLAUDE.md「開発フロー」の表で補って記載する。

各 Issue には ai-fixable / issue:needs-human-decision のどちらか一方を必ず付ける（boy-scout は付けない。正式フローを経ずに見つけた課題を後で棚卸しするためのラベルであり、/to-issues 産の Issue には当たらない）。どちらを付けるかの判定は quick-issue の「どちらを付けるか」 に従う。

「タスク一覧」「完了条件」は、登録前に該当するポリシー・rules（docs/policy-hub.md・.claude/rules/）と照合する。ポリシーに反する作業を指示していたら、タスク側を直してから登録する。実装時はポリシーが優先されるため、反したまま登録すると手戻りになる。

Issue は依存順（ブロッカーが先）に登録する。そうすれば「ブロッカー」欄に実際の Issue 番号を書ける。

文体：中学生が一度で追える文で書く。専門用語は使ってよい。読みにくさの原因は用語ではなく言い回しにある。

❌ 書かない	✅ こう書く
その位置づけが実効を持たない	そう書いてあるだけで守られない
変更耐性の最大化を企図する	変更に強くしたい
根拠を取り逃がす	使えるはずの理由を見逃す
担保する・企図する・起因する	保つ・ねらう・原因である

一文に主語と述語は1組まで。長い一文は切る。

図：次のどれか1つでも当てはまるときだけ、/design-doc-mermaid で図を描いて「作るもの」の直後に埋め込む。当てはまらないなら描かない。

発火条件	例
登場するファイル・仕組みが3つ以上あり、その参照が一直線でない（分岐・合流・双方向がある）	複数の Skill が同じ policy を参照し、policy 側が別の Skill を呼び返す
条件で振る舞いが分かれる、またはループする	失敗時にリトライする処理
状態が移る（未着手→作業中→完了 のような遷移）	Issue ラベルの遷移規則

自前で Mermaid を書き起こしてはならない（CLAUDE.md）。

## 親Issue

親 Issue への参照。元が既存 Issue だったときだけ書き、無ければセクションごと省く。

この変更が必要な理由

1文目に「何が困っているか」を言い切る。2文目以降に「放置するとどう損するか」を書く。合計4行以内。実装の詳細（HOW）は書かない。別セッションの実装者が、判断に迷ったとき優先順位を自力で決められる状態を目指す。

grill-me で確定した仕様

下の表を埋める。1行1決定・1セル1文。却下した案も書くと、別セッションでの蒸し返しを防げる。grill-me を実施していない場合は「grill-me 未実施」と書く（セクションごと省かない）。

決めたこと	なぜそう決めたか	却下した案（理由）
決定1		無ければ「なし」

作るもの

このスライスのエンドツーエンドの振る舞いを4行以内で書く。レイヤーごとの実装手順は書かない。

ファイルパスやコード片はすぐ古くなるので書かない。例外は、文章より正確に決定を表すコード片（状態機械・リデューサ・スキーマ・型）をプロトタイプが生んだときだけ。決定が読み取れる部分だけに切り詰めて貼り、プロトタイプ由来だと一言添える。

タスク一覧

実装を完了させるために必要なタスクをチェックボックス形式で列挙する。実装者はこのリストを1つずつ確認し、完了ごとに gh issue edit でチェックを更新する（CLAUDE.md の厳守ルール）。設計書・docs/requirements.md（要件定義）の更新が必要な場合は、その更新タスクも必ず含めること（Plan の「設計書・要件定義への影響」から転記）。

• タスク1
• タスク2
• （必要に応じて）設計書の更新
• （必要に応じて）requirements.md の更新

実装フロー（使用するSkill）

このIssueを実装する際に使う開発フローSkillを実行順に記載する（Planの「実装フロー」から転記。このスライスが触れる種別だけに絞る）。issue番号だけで開発フローを再現するための情報。種別→Skillの対応は CLAUDE.md「開発フロー」が正典。

順	変更種別	使用Skill
1	例：アプリ実装	/code-dev

完了条件

どうなったら閉じてよいかを書く。タスクの言い換えではなく、外から観測できる状態で書く（例：npm run lint が通る）。

• 条件1

ブロッカー

先に完了している必要がある Issue への参照。無ければ「なし（すぐ着手できる）」と書く。

親 Issue はクローズも変更もしてはならない。