Slice

/slice - 計画を垂直スライス issue に分解

計画を独立して着手可能な issue へ分解する。各 issue は tracer bullet で、そのリポジトリが持つ層を端から端まで貫く 1 本の細い縦串になり、それ単体で demo または検証できる。層はリポジトリごとに違う。Web アプリなら schema、API、UI、test で、ハーネスやライブラリなら入力の受け口、判定、出力、test になる。Phase 1 で層の名前を確定してから割る。

入力

$ARGUMENTS から計画のソースを取る。番号、URL、パスのいずれかで issue を参照していれば gh issue view <N> で本文とコメントを取得する。空ならまず会話文脈にある計画を使い、無ければ何を分解するか AskUserQuestion で問う。

ソースが ## Plan 節を持つかを見る。持つなら単位は既に決まっているので、起草せず配分する。Phase 2 と引き渡し先がこの判定で分岐する。

publish した issue の引き渡し先

ソースが ## Plan を持っていたなら、各スライスも Plan を持って publish されるので、そのまま build workflow に issue 番号を渡す。

持っていなかった場合、生む issue に ## Plan は無く、そのまま build workflow に渡すと no-plan で止まる。スライスごとに次の順で進める。全スライスをまとめて進めず、ユーザーが選んだ 1 件から始める。

1. /think で plan を作る
2. /issue <番号> を実行する。番号だけを渡す経路が、その plan を issue の ## Plan 節へ移す
3. 手順 2 が ## Plan を入れた issue の番号を、build workflow に渡す

既に構造化 plan を手元に持つなら、2 を飛ばして /code を使う。

Phase 1: 層を確定する

このリポジトリが持つ層を名前で挙げる。Web アプリなら schema、API、UI、test。ハーネスやライブラリなら入力の受け口、判定、出力、test。ディレクトリ構成と、既存の 1 機能が触るファイルの並びから読む。層が読めなければ AskUserQuestion で問う。以降の Phase はこの名前で割る。

コードベースが未探索なら、あわせて現状を把握する。issue のタイトルと説明はプロジェクトの用語集に従い、触る領域の DR を尊重する。実装を楽にする prefactor の機会を探す。横断的な探索が要るときだけ Explore エージェントを 1 体起動する。per-slice の spawn はしない。

Phase 2: 垂直スライスを起草する

計画を tracer bullet issue に割る。横スライス (1 レイヤーだけ) ではなく縦スライス。各スライスの説明は、レイヤーごとの実装手順でなく端から端までの振る舞いで書く。具体的なファイルパスやコードスニペットは陳腐化が速く、着手時に読む人を誤らせるので書かない。例外は prototype が生んだ state machine、reducer、schema、型のスニペットで、散文より正確に決定を符号化する場合のみ。その場合は prototype 由来と一言添え、決定に効く部分だけに刈り込む。受け入れ基準は、そのスライス単体で demo または検証できる形にする。他スライスの完了を前提にした基準は、依存として Blocked by へ移す。

plan を持つソースの配分

ソースが ## Plan を持つなら、unit の束ね方でスライスを決める。各スライスの Plan は ${CLAUDE_SKILL_DIR}/references/plan-distribution.md の表に従って組む。plan の unit がレイヤーごとに切られていて配分では垂直にならない場合、その節が定める差し戻しを行う。

被覆チェック

起草後、user story、acceptance criteria、FR に相当する要求単位を列挙し、どのスライスにも割り当てられていない単位を抽出する。取りこぼしを偽検出より重く扱い、疑わしい単位は未カバーに含める。未カバーは Phase 3 の提示に明示する。

Phase 3: ユーザーに確認する

提案分解を番号付きリストで提示し、末尾に未カバーを 1 行足す。未カバーが無ければ「なし」と書く。提示後に次を問う。粒度は粗すぎず細かすぎないか。依存関係は正しいか。merge か split すべきスライスはあるか。未カバー単位をどう扱うか。扱いの選択肢は、既存スライスへの割り当て、新スライス、理由付きの意図的除外。ユーザーが承認するまで反復する。各スライスに示す項目は下表のとおり。

Phase 4: issue を publish する

承認後、batch publish の前に AskUserQuestion で「これら N 件の issue を作成するか」と最終確認する。N 件作成は外向きで巻き戻しにくいため、確認なしの自動 publish はしない。

承認したら、blocker を先にする依存順で publish する。"Blocked by" に実 issue 番号を書けるよう、blocker を先に作ってその番号を捕捉する。

1. テンプレート選択で決めた骨格に本文を流し込み、heredoc を使って cat で一時ファイルへ書き出す。<path> は変数でなくリテラルの絶対パスで書く。hook は変数を展開できず、起票が止まる
2. ${CLAUDE_SKILL_DIR}/../issue/scripts/validate-issue-body.ts <骨格ファイル> <title> <body-file> を実行する。エラーは ${CLAUDE_SKILL_DIR}/../issue/references/validation-errors.md に従って直し、直したら再実行する。N 件をまとめて起票するので、1 件の欠落が N 件に広がる
3. gh issue create --title "<title>" --body-file <path> --label priority:<値> で起票する。複数行の markdown は --body では壊れるので --body-file を使う。priority は critical、high、medium、low から影響度で選ぶ。骨格に priority の節があれば、その値とラベルを揃える
4. ソースが issue なら、gh issue edit <ソースの番号> --add-sub-issue <番号1,番号2,...> で全スライスを sub-issue として紐付ける。ソースが plan ファイルなど issue でない場合は飛ばす
5. triage label は付けない。AFK consumer 連携は対象外。親 issue は close せず、本文も変更しない
6. 作成した issue を依存順に列挙し、各行に issue 番号と blocker の番号を書く。blocker が無ければ「なし」と書く
7. Phase 3 で意図的に除外した要求単位を、理由を添えて報告の末尾に書く。親 issue の本文は変更しないので、ここに書かないと除外の理由が残らない

テンプレート選択

骨格の取り方は ${CLAUDE_SKILL_DIR}/../issue/references/template-source.md に従う。/issue と同じ順で選ぶことで、どちらの経路で起票しても本文の骨格が揃う。

どちらの骨格を選んでも ## Parent を先頭に、## Blocked by を末尾に足す。親子の正は手順 4 が張る sub-issue 関係で、## Parent はその写し。本文だけを読む経路へ届けるために置くので、片方だけを張らず同じ回に両方を揃える。当てはまらない任意節は落とす。確信度マーキングは適用しない。Phase 3 で粒度と依存をユーザーが承認済みなので、publish するスライスに未決の判断は残らない。

言語

~/.claude/settings.json から language を読み、issue 本文をその言語に翻訳する。未設定なら英語。技術用語、コード、識別子は翻訳しない。

エラー処理