build-by-story

エフェメラルパス：FEATURE_CODE / <CODE> を解決してから templates/skills-ephemera-paths.md に従います（機能ルートは .skills/<CODE>/）。パックのシードは次の順に解決し、最初に存在するパスを使います：（1）この SKILL.md と同じ場所にある templates/、（2）変数が設定されている場合は ${CLAUDE_PLUGIN_ROOT}/templates、（3）この SKILL.md からの相対パス ../../../templates。

ストーリー単位でのビルド

承認済みのストーリー単位の計画を完了まで進めます。要件ストーリーからレビュー単位を導き、各単位内で共有の継続スケジューラーを実行し、各単位の後に人間の確認のために停止し、単位台帳から再開して、最後にブランチ全体をレビューします。

単位の区切りなしで複数タスクのオーケストレーションを継続する場合は build-in-waves を使います。サブエージェントを使わずにコントローラーが実装する場合は build-inline を使います。このスキルを呼び出すと、ストーリー単位の実行が選択されます。継続モードへの引き継ぎについては、以下の「モードの所有権」を参照してください。ユーザーがサブエージェントを使わないことを希望する場合は、build-inline を指定します。

共有コントローラー手順： 必須サブスキル：execute-common を使います。これは事前確認／台帳／ToDo／終了処理を一元管理し、以下の各セットアップ手順で指定された箇所に適用します。このファイルではストーリー単位の区切りと単位の導出を扱います。タスクの割り当て／レビューには ../execute-common/task-lifecycle.md を読み込み、各単位内では build-in-waves の継続スケジューラーのルールを使います。

ナレーション： ツール呼び出しの間に添えるのは、短い一文までにします。記録は台帳とツールの結果に残します。

鉄則

NO NEXT UNIT WITHOUT HUMAN UNLOCK (OR A WRITTEN MODE CHANGE)

エージェントの確認が完了しても、人間の確認への移行は許可されていません。終業時刻、デモのプレッシャー、「PR全体は後で」という理由で区切りをなくしてはいけません。「停止をやめる」はモード変更です。区切りをなくす前に、tasks.md に Execution-mode: continuous を記載します。

鉄則（ストーリー単位）

1. レビュー単位は導出するものであり、tasks.md に記述するものではありません（分割には、PM の「人間によるレビュー順」のコメントを使いません）。
2. 各単位のタスクがすべて問題なく完了したら、単位のエージェントレビュー → 人間の確認のために停止 → ロック解除の順に進めます。
3. 確認後の 「続けて」 は次の単位だけを指します。「停止をやめて」／「全部そのまま実行して」 と言われた場合は、まず tasks.md に Execution-mode: continuous を記載してから、残りの作業を build-in-waves に引き継ぎます。チャット上の指示だけではモード変更になりません。
4. 台帳には Unit <k>: complete (tasks …, range <base>..<head>) と記録します。再開時はこの記録を読みます。
5. 最後の単位の後も、ブランチ全体のエージェントレビューを実施します。人間による単位ごとのレビューで代用することはできません。

考え	実際
「ユーザーは続けてと言ったので、tasks.md を編集する必要はない」	「停止をやめて」はモード変更です。ヘッダーを記載しなければ、計画が実態と食い違います
「単位のエージェントレビューに問題はなかったので、人間の確認は省略する」	単位のエージェントレビューは、人間の確認のための停止ではありません
「終業時刻／PR全体は後で——単位ごとの停止は省略する」	時間や後で行うレビューによって、Execution-mode が変わることはありません
「続けてというのは、残りをすべて実行するという意味」	「続けて」で解除されるのは次の1単位だけです。すべて実行するにはモード変更を明示する必要があります
「PM のレビュー用ウェーブのほうがストーリーより分かりやすい」	分割は、記述されたリストではなく、要件のストーリー ID から導出します

モードの所有権

tasks.md をストーリー単位の方式に合わせてから、作業を続けます。

tasks.md の Execution-mode:	対応
story-unit	続行
continuous	必須サブスキル：build-in-waves を使います
欠落／unset／無効	tasks.md に Execution-mode: story-unit を記載します（追跡対象の場合はコミットします）。続行します

セットアップ

1. モードの管理。 上記の表を適用します。完了条件：ヘッダーが story-unit であり、このスキルを続けるか、build-in-waves に引き継いでいること。
2. セッションの事前確認。 ../execute-common/SKILL.md の Session preflight を適用します。 完了条件：そのセクションの完了条件を満たしていること。
3. 台帳の確認。 ../execute-common/SKILL.md の Ledger check を適用します（その story-unit 条項では、すでに完了として台帳に記録されたユニットをスキップするケースを扱います）。 完了条件：次のタスク／ユニットが判明していること。
4. 計画を読む。 tasks.md を一度読みます。正規の Global Constraints のパスとコンテンツハッシュを記録します。ディスパッチでは、それを各レビュアー向けプロンプトに貼り付けず、そこを参照し、そこから検証コマンドを取得します。 docs/agents/project.md がない場合は、その旨を伝え、configure-repo を提案します。## Team にロスター／バンドがある場合は、バンドの packaging のみを読み込みます。Solo のデュアル判定レビューは決して省略しないでください。完了条件：制約を一字一句そのまま記録していること。
5. ユニットの導出 — ゲート。 このファイルと同じ場所にある story-unit-mode.md を読み込みます。Derive partition ＋ File count を実行し、Unit table を出力します。ハードフェイルがある場合はディスパッチをブロックします。完了条件：テーブルが出力され、ハードフェイルが解決済みまたは報告済みであること。
6. ToDo — ゲート。 ../execute-common/SKILL.md の Todos — GATE を適用します。 完了条件：リストが計画と一致し、Close 分岐の ToDo も含まれていること。
7. 計画の事前レビュー。 ディスパッチ前に、計画内の欠陥についてまとめて質問します。問題がなければコメントしません。完了条件：矛盾が解消されているか、矛盾がないこと。
8. ユニットの順序。 ステップ 5 の Derive partition によって、すでに固定されています。各ユニット内では、共有の ready-set スケジューラーを使用します。準備できているタスクが 1 つのみ、または作業対象のサーフェスが重複している場合は逐次実行します。安全なワークツリー分離が可能で、サーフェスが重複しない場合に限り並列実行します。完了条件：ユニットごとの並行実行方式が確定していること。

ユニットごとのループ

各ユニット U について、順番に実行します。

A. ユニット内のタスク

U 内の準備ができているタスクごとに ../execute-common/task-lifecycle.md を実行します。スケジューラーがレーン、ワーカー／レビュアーのリース ID、ベースリビジョン、ブリーフ、レポート、差分パッケージのパスを提供します。問題のないタスクレビューはユニットのバリアより前に台帳に記録します。そのファイルに記載された単一タスクのクローズアウトとレビュアー重複禁止のルールに従い、B のディスパッチが引き続き必要かどうかを判断します。

B. ユニットのバリア（U 内のすべてのタスクが台帳に記録された後）

story-unit-mode.md の Per-unit barrier を読み込み、全手順を実行します。人に提示する STOP メッセージは、そのレシピで REQUIRED とされるすべての項目を必ず埋めなければなりません。時間がない場合でも、自由形式の省略は認められません。複数タスクのユニットでは、A で実行したユニットスコープのディスパッチが統合レビューに相当します。単一タスクのユニットは A ですでにクローズアウトされているため、ここでは再レビューしません。

ロック解除：

ユーザーの発言	アクション
続行 / LGTM / （確認後に）問題ありません	Unit <k>: complete (tasks …, range <base>..<head>) を台帳に記録します。次のユニットにのみ進みます。モードは story-unit のままにします。
stop stopping / 全部そのまま実行して	tasks.md に Execution-mode: continuous を書き込みます（追跡対象の場合はコミットします）。このユニットの完了を台帳に記録します。必須のサブスキルとして、残りのタスクには build-in-waves を使用します（以降、ユニットのバリアは実施しません）。
stop / 保留 / 変更が必要	停止したままにし、次のユニットを開始しません。

C. 次のユニット

ユニットごとのループを再開します。最後のユニットのロック解除と台帳への記録が終わったら → 最後のユニットの後。

実装者のステータスへの対応

ステータス	対応
DONE	差分をパッケージ化 → タスクをレビューします。
DONE_WITH_CONCERNS	懸念事項と .skills/<CODE>/implementation-notes.md の両方を読みます。記載内容は ../execute-common/implementer-prompt.md の9フィールドの Deviations の手順に従う必要があります。メモのパスがない、フィールドが不完全、または逸脱を主張しているのに5フィールドしかない場合は未完了です。まず記録するよう再ディスパッチしてください。影響をマッピングし、reroute-plan / realign-spec に該当する場合、または計画の前提を覆す場合は、サブスキルの使用が必須です。reroute-plan を使用してください（問題なしの DONE として受け入れないでください）。
NEEDS_CONTEXT	指定された情報を提供し、同じモデルで再ディスパッチします。
BLOCKED	コンテキストが不足している場合は提供します。モデルの能力上限の場合は、より高性能なモデルを使います。規模が大きすぎる場合は分割します。計画が誤っている場合は、サブスキルの使用が必須です。reroute-plan を使用してください。

タスクごとの再ディスパッチは最大2回までです。それでも DONE にならない場合は、ユーザーにエスカレーションします。

モデルのティア

ディスパッチのたびにモデルを明示的に指定してください。

• 低コスト： 文字起こし／単一ファイルの機械的な修正。
• 中位が最低条件： すべてのレビュアー、および文章を基に作業するすべての実装者。
• 最上位： 設計上の判断、広範なコードベースの理解、ブランチ全体のレビュー。

レビュアープロンプトの衛生管理

• ディスパッチ時に、指摘内容を先回りして決めつけないでください（「Xは指摘しないでください」「せいぜい軽微な指摘にしてください」など）。
• 計画で必須とされた欠陥も指摘事項です。どちらを優先するかユーザーに確認してください。
• 具体的な理由なしに「すべて確認してください」といった範囲が曖昧な指示を出さないでください。
• 実装者が報告で実施を証明済みのテストを再実行しないでください。

進捗の保持

• 台帳で完了と記されたタスクを再ディスパッチしたり、単位を再オープンしたりしないでください。
• コンパクション後は、完了行がない最初のタスクから再開してください。単位の完了行は、その単位の人間による確認がすでに完了していることを意味します。
• .skills/ は Git で無視される作業用領域です。削除された場合は git log から復元してください。

最後の単位の後

../execute-common/SKILL.md の Close sequence をすべて適用してください。確認するベースは git merge-base main HEAD です。最後の単位だけを対象にした範囲にしてはいけません。

完了条件：そのセクションの Done when を満たしていること。

レッドフラグ — 絶対にしないこと

• トラッカー同期、占有状況、ワークスペースの事前確認を省略する
• 設定がない場合やユーザーが同期を断った場合に、トラッカーやチケットの一覧をでっち上げる
• 人間による解除、または文書化されたモード変更なしに、次の単位を開始する（または台帳上で解除済みであるかのように単位を完了扱いにする）
• 「停止するのをやめて」という指示をチャット内だけで処理し、Execution-mode: continuous を記録しない
• 「続けて」を残りの全単位を実行する指示だと過剰に解釈する
• 派生したストーリー単位より PM のレビュー順リストを作成したり優先したりする
• 単位エージェントのレビューを省略し、生の単位を先に人間へ送る
• すべての単位が人間の承認を得ていることを理由に、ブランチ全体のレビューを省略する
• レビューのベースとして HEAD~1 を使う
• サブエージェントに計画ファイル全体を渡す
• Critical／Important の指摘が未解決のまま先へ進む
• コントローラーのコンテキスト内でレビュアーの指摘を修正する
• 台帳で完了と記された作業を再ディスパッチする
• ToDo リスト（タスクおよびClose ブランチ）ができる前にディスパッチする
• クローズシーケンスを省略する、polish を暗黙に省略する、または EOD／デモを polish の条件として扱う
• 明示的な同意なしに main/master で実装する
• 許可を求めずにワークツリーを作成する
• ヘッダーが story-unit のままなのに、黙って continuous のルールに切り替える