build-inline

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

インラインでのビルド

承認済みの計画を、実装担当（またはレビュー担当）のサブエージェントを一切呼び出さずに、自分でタスクごとに完了まで進めます。すべてのステップで test-first を実施します。進捗は台帳に記録して保持します。最後にブランチ全体をレビューします。

これはサブエージェントのオーケストレーションではありません。 複数タスクを継続的に進めるサブエージェントのウェーブには build-in-waves を使用します。サブエージェントを使った、人によるゲート付きのレビュー単位には build-by-story を使用します。

意図	代わりに使用するもの
サブエージェントの継続的なウェーブ	必須サブスキル：build-in-waves を使用
ストーリー単位のバリアとサブエージェント	必須サブスキル：build-by-story を使用

このスキルが起動する条件： ユーザーがインラインで進める方法を選んだ場合、環境上、実装担当を並列に実行できない（または実行してはならない）場合、あるいは plan-tasks がインライン実行を提示し、ユーザーが承諾した場合です。ツールが利用可能でも、実行経路は変わりません — インラインでの実行を求められたら、サブエージェント用のツールがあってもインラインで進めます。

進行状況の説明： ツール呼び出しの間に挟む短い説明は、最大1行にします。記録は台帳とツールの結果に残します。

共通コントローラーの手順： 必須サブスキル：execute-common を使用します。Setup の事前確認／台帳／TODO の開始時、または最後のタスク開始後に ../execute-common/SKILL.md を読み込みます。これらの手順とクローズシーケンスの判定条件は、すべてこのファイルにまとめられています。 このファイルでは、インラインの鉄則と、コントローラー自身が実装を担うループを定めます。

鉄則

NO IMPLEMENTER SUBAGENT — YOU ARE THE IMPLEMENTER
NO PRODUCTION CODE WITHOUT TDD
NO GUESSING THROUGH A BLOCKER

「ツールがあるから」または「サブエージェントのほうが速いから」という理由で実装担当を呼び出すことは、このスキルへの違反です。変更が「1行だから」という理由で RED を省略することも、このスキルへの違反です。計画が曖昧なときに API、パス、受け入れ条件を独自に考案することも、このスキルへの違反です — 作業を止めて確認してください。

スコープと実行モード

このスキルを呼び出すと、インラインの実行経路が選択されます。Execution-mode ヘッダーは、関連するスキルと後続の引き継ぎのための管理情報です。

ヘッダー	このスキルでの動作
continuous または story-unit	タスクを順番に実行します。単位ごとのバリアなし。人による単位ごとの停止なし
欠落／unset／無効	tasks.md に Execution-mode: continuous を記述します（追跡対象ならコミットします）。ここではバリアは実行しません

サブエージェントを使った、人によるゲート付きのレビュー単位には build-by-story を使用します。インラインでは、会話の各ターンで人がすでに関与します。

考え	実際の動作
「サブエージェントが使える — 全工程を実行しよう」	実行経路はインラインです。ツールによって実行経路が変わることはありません
「1行の変更だから、失敗するテストは省こう」	必須サブスキル：すべてのタスクステップで test-first を使用します
「計画が曖昧だから、妥当な形を選ぼう」	計画に不足があれば、作業を止めて確認します。決して推測しません
「story-unit ヘッダーがあるから、各ストーリーの後で止めよう」	バリアは build-by-story で扱います。インラインでは順次実行のみです
「実装担当ではなく、レビュー担当だけを呼び出そう」	タスクレビュー担当のサブエージェントも呼び出しません。最後に inspect-change でブランチ全体を確認します
「並列ウェーブなら早く終わる」	インラインは逐次実行です。ワークツリーへの並列展開は行いません

セットアップ

1. ルートの判定。 インライン実行が意図された経路であることを確認します（ユーザーがそう述べた場合、またはサブエージェント機能がない場合）。サブエージェントによる連続ウェーブを希望している場合は、build-in-waves を使用します。ストーリー単位のバリアを希望している場合は、build-by-story を使用します。完了条件：実行経路がインラインであること。
2. ヘッダーの確認。 Execution-mode: を解析します。存在しない／unset／無効な場合は、tasks.md に Execution-mode: continuous を記入します。すでに設定されている場合は、そのままにします。完了条件：ヘッダーが存在すること。
3. セッションの事前確認。 ../execute-common/SKILL.md の Session preflight を適用します。完了条件：そのセクションの完了条件を満たすこと。
4. ランタイムのバインド。 ../execute-common/SKILL.md の Runtime binding and lease preflight を適用します。インライン実行ではワーカーリースはありませんが、アクティブなハーネス／プロバイダー／モデル、料金ポリシー、コンテキストの予約量、有効な同時実行数を .skills/<CODE>/execution-session.json に記録します。完了条件：最初の本番コードの編集前にランタイムスナップショットが存在すること。
5. 台帳の確認。 ../execute-common/SKILL.md の Ledger check を適用します。完了条件：次のタスクが分かっていること。
6. 計画を読む。 tasks.md を一度読みます。正規の Global Constraints のソースパスとコンテンツハッシュを記録します（docs/agents/project.md が存在しない場合は、検証コマンドがここにあるか確認し、その旨を伝えて configure-repo を提案します）。完了条件：ソース参照とタスクの差分を把握していること。
7. ToDo — GATE。 ../execute-common/SKILL.md の Todos — GATE を適用します。完了条件：リストが計画を反映し、Close ブランチの ToDo も含んでいること。
8. 実装前の計画レビュー。 コーディング前に、計画内の不備について一括で質問します。問題が見つからない場合はコメントしません。完了条件：矛盾が解消されているか、矛盾がないこと。
9. 順序。 Depends-on に基づくトポロジカル順序に従います。Depends-on がない場合は、先行するすべてのタスクに依存します。none の場合は前提条件がありません。このスキルでは直列のみです。並列ウェーブや複数ワークツリーへの分岐は決して行いません。完了条件：タスクの順序が確定していること。

タスクごとのループ

各 Task N について、順番に以下を行います。

1. ベースを記録します。 BASE=$(git rev-parse HEAD)。
2. タスク用の要約を作成します（自分用）。 Task N、Canonical Global Constraints のソースパス／ハッシュ、タスクの差分を .skills/<CODE>/task-N-brief.md に記録します。このファイルは、実装時に従うべき契約です。 正確な値、パス、シグネチャ、_Requirements: ID を記載します。 docs/architecture/ の背骨がある場合は、関連する **ARCH-N** を含めます。事前確認でチケット ID が記録されている場合は、 要約に列挙します。完了条件：要約ファイルが存在し、内容を読んでいること。
3. まず明確化します。 要約に曖昧な点（API の形式、パス、受け入れ条件、依存関係など）があれば、停止して今すぐ質問します。明確になるまで RED を開始してはいけません。
4. TDD で実装します。 タスクのすべての手順で test-first を使用することが必須のサブスキルです。テストではドメインの振る舞いを記述します。要件 ID はレポート／セルフチェックで対応付け、ソースコードに埋め込まないでください。計画で指定されたファイルのみを作業対象にします。
5. 逸脱。 作業範囲の制約により要約から外れる場合、実装者であるあなたは ../execute-common/implementer-prompt.md の Deviations 手順に従います （.skills/<CODE>/implementation-notes.md に Unknown class、Map said、 Territory showed、Map impact などの9項目を記録します）。タスクを完了する前に記録し、追記のみとします。 Map impact が reroute-plan／realign-spec の場合、または修正によって計画／共有契約が事実に反する場合は、停止し、必須サブスキルの reroute-plan を使用するか、質問してください。黙って無理に進めてはいけません。
6. コミットします。 変更内容を説明する Conventional な件名を使います。Implements:／Guards: のトレーラーは不要です。
7. レンダリングを確認します。 実装者であるあなたは、差分がブラウザーに表示されるものに触れる場合、../execute-common/implementer-prompt.md の Render check 手順を実行します（スクリーンショットを .skills/<CODE>/task-N-render.png に保存し、要約と照らして評価し、修正して撮り直します）。Visual check の行は、手順9のエビデンス一式に含めます。
8. セルフチェックします（サブエージェントではなく、コントローラーとして）。 要約と差分を再確認します。すべての要件 ID に対応する振る舞いが網羅されているか、TDD の証拠（RED の後に GREEN）が確かなものか、成果物に問題がないか、Plan File Structure を守っているかを確認します。別途タスクレビュアーによる確認はないため、不備があれば今すぐ修正します。
9. エビデンス一式を任意で作成します。 重要なタスクでは、変更内容、対応した ID、RED／GREEN のコマンドと出力、レンダリング確認を実施した場合は Visual check の行、懸念事項、逸脱の記録先または none を .skills/<CODE>/task-N-report.md に記載します。簡単なタスクでは、コミットメッセージと台帳で十分な場合にファイルを省略できます。迷った場合は作成してください。
10. 台帳に記録します。 次の行を追記します。 Task N: complete (commits <base7>..<head7>, inline, review self)。 TODO を完了済みにします。
11. 次に進みます。 許可待ちや単位の区切りを挟まず、すぐに次のタスクに進みます。タスクの途中でブロッカーが発生した場合は、ループを止めて質問します（Stop conditions を参照）。

停止条件

以下の場合は、推測したり、回答を考案するサブエージェントを呼び出したりせず、停止してユーザーに質問してください。

• 要約または計画が曖昧、もしくは矛盾している
• 検証に失敗し、要約から明確な修正方法を判断できない
• 逸脱によって計画／設計／要件が事実に反することになる
• タスク外のファイルや契約に触れる必要がある
• main/master で作業しているのに、main/master の承認がない

ユーザーの回答を受け取ったら、台帳の手順を省略せず、同じタスクを要約に沿って再開します。

進捗の保持

• 開始時に .skills/<CODE>/progress.md を読みます。記憶よりも、このファイルと git log を信頼してください。
• 台帳で完了済みと記録されたタスクをやり直してはいけません。
• コンパクション後は、完了行のない最初のタスクから再開します。
• .skills/ は Git の追跡対象外です。削除された場合は、git log から再構築します。

最後のタスクの後

../execute-common/SKILL.md の Close sequence をすべて実施してください。このスキルでは test-first に従って修正を行います（ユーザーがインラインのルートを明示的に解除しない限り、実装担当のサブエージェントは引き続き使用しません）。台帳／implementation-notes.md にある Minor またはメモを inspect-change に渡してください。

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

レッドフラグ — 禁止事項

• トラッカーとの同期、占有状況の確認、ワークスペースの事前チェックを省略する
• 設定がない場合、またはユーザーが同期を辞退した場合に、トラッカーやチケットのセットを作り上げる
• このスキルの実行中に、実装担当またはタスクレビュー担当のサブエージェントを起動する
• test-first を省略する／失敗するテストを先に作成せずに本番コードを書く
• 曖昧さ、失敗したテストスイート、または計画の不足を推測で補う
• ユニットテストのゲートや人によるユニットテストの停止条件を実行する（これは build-by-story の担当です）
• 並列ウェーブ／複数ワークツリーへの分岐
• 圧縮後に台帳で完了済みのタスクをやり直す
• 明示的な同意を得ずに main/master で作業を始める
• 許可を得ずにワークツリーを作成する
• 台帳に記録せずにタスクの完了を宣言する
• クローズシーケンスを省略する、仕上げ作業を黙って省略する、または EOD／デモを仕上げ作業の完了条件として扱う
• TODO リスト（タスクと Close ブランチの両方）ができる前にタスク 1 を始める
• ユーザーが明示的にルート変更を指示せずに、計画の途中で build-in-waves のサブエージェントループへ引き継ぐ