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 へ移す。

ルール	内容
全レイヤー	各スライスは Phase 1 で確定した層をすべて貫く
単独検証可能	完了スライスはそれ単体で demo または検証できる
prefactor 先	prefactor が要るなら最初のスライスに置く

plan を持つソースの配分

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