implement

実装

setup-project のバックログから承認済みの作業を実行します。スコープや優先順位は変更しません。単独の WORK-NNN は、1 つの受け入れ単位です。EPIC-NNN とその承認済みの子項目すべては、1 つの成果受け入れ単位です。子項目は、構成された Epic のレビュー、検証、マージ、整合性確認、完了、アーカイブが済むまで暫定状態のままです。

受け入れ単位ごとに従来型のブランチを 1 つ使用し、ローカルにはプライマリ以外のブランチをほかに作成しません。Epic の子項目がプライマリに統合されたり、Wiki の状態を公開したり、個別に done になったりすることはありません。$implement-with-subagents による内部向けの暫定子項目パケットまたは暫定単独項目パケットは、レビュー、ガバナンス、受け入れのゲートを経ずに、そのブランチ上で 1 回分の差分を直列に実行します。

権限と承認

項目の成果、受け入れ基準、除外事項、承認済みの関係によって、実装のスコープを定義します。親 Epic は調整のコンテキストを提供しますが、子項目のスコープを拡大することはありません。承認済みの Wiki とリポジトリの指示が、現在の状態の基準とエンジニアリング上の制約を定義します。

この呼び出しは、ゲートを備えた実行ワークフローです。選択した承認済みスコープに対する一時的な作業担当の設定、チェックリストの証跡、通常の実行ステータス遷移を許可します。ただし、成果や受け入れ文言、順位、親子関係、関係性、キャンセル、子項目のスコープ、承認済み Wiki の知識の変更は許可しません。キャンセルの提案やスコープ外とする判断はバックログに残し、オーナーの承認を得るために作業を停止します。正確な Wiki 更新内容について明示的な承認を得てください。ただし、すでに明示的に承認されている場合は除きます。

$to-product のもとでは、自律実行契約が PRD に必要な、ユーザーが承認可能なすべての判断を定めます。これには、レコードや Epic の再構成、キャンセル、リカバリー、Wiki 更新、受け入れ、クローズが含まれます。ただし、PRD と無関係な実装を許可することはありません。隣接するスコープの作業は proposed として記録してください。

権限パケットの鮮度

今回の呼び出し中にレコード、インデックス、Wiki の概念、ADR、ガイダンスページ、ソースファイルなどの権限情報を最後まで読み込んだ場合、その情報は既読のままです。再読込は無駄です。ここから呼び出されるスキルは、今回の呼び出しですでに解決済みのパケットのパスと役割を受け入れ、それらを再発見することはありません。鮮度は呼び出しごとに管理します。他の呼び出しの鮮度を引き継いではならず、サブエージェントがその情報を保持していると想定してはなりません。

以下のいずれかに該当する場合、すでに読んだ権限情報は無効となるため、再読込が必要です。

• 読み込み後にコンテキストが要約または圧縮された。
• ブランチが変わった、またはマージが取り込まれた。
• 今回の呼び出しで作成していないコミットがそのパスに変更を加えた。
• 何らかのトランザクションでレコードが変更された。
• 作業担当の有効期限が切れた、または更新された。
• 読み込み後に node scripts/validate-project.mjs が失敗した。
• 固定点が変わった。

各選択と最終遷移の前に、最後の読み込み以降の git log -- docs/backlog を確認します。今回の呼び出しで作成していないコミットが該当ファイルに変更を加えている場合に限り、全体順位、作業担当、ステータス、インデックスを再読込してください。鮮度が不確かな場合は、再読込してください。

検証の鮮度： テスト一式全体が合格した場合、コードに影響する入力のテスト済みの内容が検証されます。対象はソース、テスト、依存関係のマニフェストとロックファイル、ランタイム／ビルド設定、生成されたランタイム成果物、関連する環境設定です。テスト対象のコミットと、影響を受けるパスの分類を記録してください。これらの入力がその状態と一致する場合に限り、結果を再利用できます。バックログ、Wiki、実行に影響しないドキュメントは異なっていてもかまいません。マージ後は、ツリー全体のハッシュではなく、マージ後のコードに影響する入力を、テスト済みのブランチ状態と比較してください。差異がある場合、または分類が不確かな場合は、再実行してください。

事前確認

ブランチの作成または切り替え、あるいは作業担当の変更を行う前に、次の確認を完了してください。

1. リポジトリのルートを特定します。該当する AGENTS.md、CLAUDE.md、ネストされた指示、およびコントリビューションやコーディング規約をすべて読みます。
2. $setup-project のスキャフォールドと、現在の Epic の受け入れ単位のライフサイクル（開始トランザクション、暫定的な子項目、チェックリスト証拠の一括処理、最終受け入れとアーカイブの原子的な実行）を必須とします。ファイルが不足している場合、またはプロジェクト内の保守手順で依然として子項目ごとの受け入れや証拠のコミットが求められる場合は、停止し、$setup-project にアップグレードと整合を依頼します。
3. node scripts/validate-project.mjs を実行します。ベースラインが無効な場合、ユーザーがその状態の修復を明示的に依頼していない限り、報告して停止します。
4. 現在のブランチ、プライマリーブランチ、ローカルブランチ、リモート、ステージ済み／未ステージの変更、および最近の履歴を確認します。$create-conventional-branch の不変条件を守ります。無関係な変更は保持し、ステージしません。
5. 対象を特定します。明示された ID またはパスがあれば優先します。それ以外は、会話の文脈から一意に選択できる場合に限ります。候補がない場合、または曖昧な場合は候補を一覧表示して質問します。
6. 選択したレコード、親 Epic、Epic のスコープ内にあるすべての子項目、全体ランク、アクティブインデックス、関連するすべてのレコード、および内向きブロッカーの算出に必要なすべてのレコードを完全に読みます。アーカイブインデックスを読むのは、それを書き込むアーカイブ手順の時点に限ります。
7. バックログ保守手順、該当する型のテンプレート、リンクされたすべての Wiki コンセプトと最も近いインデックス、Wiki 保守手順、関連するエンジニアリングおよびアーキテクチャのガイダンス、docs/wiki/architecture/decisions/index.md の ADR インデックス、レコードの草案 ## Decisions、提案に関する調査とローカルの証拠、影響を受けるリポジトリのコードとテストを読みます。個別の有効な ADR を開くのは、その内容が項目の変更差分または草案の決定に関係する場合に限ります。
8. 項目の変更差分が対象とするテクノロジーごと、横断的な標準ごとに、その項目自身のディレクトリインデックスから特定した docs/wiki/engineering/technologies/ および docs/wiki/engineering/standards/ 配下の該当するすべてのガイダンスページを読みます。準拠の強さは docs/wiki/maintenance.md § Adopted guidance に従います。一覧に記載された Known gap は既存の非準拠であり、さらなる非準拠を追加する許可ではありません。変更対象の主題についてページがない場合、または内容が古い場合は、報告対象のギャップです。項目の調査結果とリポジトリ内の証拠に基づいて実装し、受け入れ後の $guidance の提案および最終報告でそのギャップを明記します。これを理由に作業を止めてはならず、ここで docs/wiki にガイダンスを書いてはなりません。
9. この呼び出しにおけるプライマリーブランチの固定点を特定し、レビューおよび統合の証拠として保持します。Epic の場合、この固定点は最終 Epic レビューにおける不変の Epic 固定点でもあり、項目ごとの固定点で置き換えてはなりません。

影響を受けるコード、テスト、ガイダンスをここで確認します。$parallel-execution を使えるのは、具体的な読み取り専用の質問、または副作用のない確認が2つ以上ある場合に限ります。変更を伴う操作はすべて逐次実行します。内部の暫定ワーカーが処理を委任することはありません。

内部の暫定パケットが有効なのは、オーケストレーターの現在のセッション、受け入れ単位、唯一のブランチ、想定 HEAD、クレーム、固定点、権限パケット、およびモード（child または standalone）を明記している場合に限ります。ワーカーはクレームの所有者ではなく、クレームを変更してはなりません。

ブランチ作成前に拒否します：

• proposed、done、cancelled のいずれかが明示されたアイテム。
• ready ではないアイテム。ただし、このエグゼキューター／セッションが所有するアクティブな受け入れ単位、または有効な内部暫定パケットの対象である場合を除きます。
• Definition of Ready のフィールド、客観的な基準、承認済みの実行方法、検証コマンド、ランクの記載、解決済みの親／関係、完了済みまたは不要と判断された調査、または解決済みの decisions のいずれかを欠く ready のアイテム。
• ## Subtasks が、検証可能な単位として実行するには粒度が粗すぎる ready のアイテム。各サブタスクにスコープまたは検証方法が記載されていない場合が該当します。ただし、このセクションが正確に No subtasks. である場合を除きます。
• 未解決の内向き blocks 関係がある ready のアイテム。
• 不正なレコード、無効なプロジェクト、期限切れの claim、または claim とステータスの不一致。
• 別のエグゼキューターが所有する有効な claim。決して上書きしないでください。
• ready ではない Epic（その in-progress の Epic を再開する場合を除く）、または承認済みの子アイテムがない Epic。
• 別のエグゼキューターが claim している、必須の未完了の子アイテムを含む Epic のスコープ。

内部暫定の例外により変更されるのは、claim の所有権とブランチの一致条件のみです。準備状況、ブロッカー、スコープ、権限、検証に関するチェックはすべて適用されます。

ブロックしているレコード、競合する claim／有効期限、不正なフィールド、またはオーナーの判断をすべて報告してください。別個のブロック中ステータスを使用したり、却下後にブランチを作成したりしないでください。$to-product のもとでは、ワークフローだけを理由とする却下をすべて、その契約に従って修正し、再検証してから続行してください。

Epic モード

呼び出しが EPIC-NNN に解決された場合、プリフライトの後、最初の子アイテムを選択する前に references/epic-mode.md を読みます。このファイルが、子アイテムの選択順序、Epic の完了、クリーンアップを規定します。WORK-NNN の呼び出しでは読みません。

Epic の逐次実行順序

各子アイテムに着手する前に、現在のブランチに対して実行可能性、依存関係、共有インターフェース、競合ドメインを再検証します。

実行可能な子アイテムのうち最もランクの高いものをローカルで実装するか、$implement-with-subagents に新しいワーカーを 1 人割り当てさせます。別の子アイテムを開始する前に、その子アイテムのコミットを完了し、検証してください。この呼び出しでは、claim、権限、レビュー、調整、統合、受け入れを引き続き担当します。

ブランチと Claim

プリフライトの後：

1. 内部暫定パケットの場合は、ガバナンスを変更せずに、指定されたブランチと正確な HEAD を検証します。それ以外の場合は、唯一の受け入れブランチ、セッション、有効な claim が一致する場合に限り再開するか、単独アイテムまたは Epic に対して $create-conventional-branch を 1 回実行します。
2. 通常の単独アイテムまたは Epic の呼び出しでは、claim の有効期限を作業単位全体が完了するように設定します。単独アイテムを claim し、ready -> in-progress に移行するか、Epic と必須の未完了の子アイテムを in-progress に移行し、各子アイテムを同じセッション／受け入れブランチ用に claim します。Epic に claim フィールドはありません。
3. 通常の呼び出しでは、## Execution にブランチ／セッションを 1 回記録し、node scripts/validate-project.mjs を実行します。影響を受けたバックログのパスだけをステージし、差分を確認してから、この開始トランザクションを 1 つのコミットとしてコミットします。内部暫定パケットでは手順 2～3 をスキップし、そのまま実行に進みます。

通常の実行中にバックログの証跡を書き込まないでください。更新、安全な解放、ブロッカーからの復旧は、定例のゲートではなく、例外的な検証済みトランザクションです。期限切れの claim がある状態で続行したり、別のエグゼキューターの claim を変更したりしないでください。

実行

単独の項目、内部の暫定パケット、または Epic mode で選択したローカル所有の Epic 子項目ごとに、次の手順を実行します。

1. 差分の開始時点となるコードコミットを記録します。承認済みのアプローチとサブタスクに従い、まず実際に変更した経路を実装してスモークテストします。バグの場合は、再現可能な範囲で最も低コストの修正前の失敗再現を記録します。
2. 一貫性のあるコード変更単位をコミットします。変更単位を安定させてから、影響を受ける最小限のチェックを実行します。該当する各リンターまたは型チェックは一度だけ実行し、失敗したもの、または後続の変更で無効になったチェックだけを再実行します。決定論的なチェックは、可変のキャッシュ、出力、ポート、データベース、シミュレーター、リポジトリの状態を共有しない場合に限り、並行して実行します。ここでは全テストスイートや広範なプラットフォームマトリックスを実行しないでください。
3. 既存のカバレッジを再利用します。新しい観測可能な契約に証明がない場合に限り、永続的なテストを1つ追加します。優先順位は、受け入れ基準上重要なE2E、次に統合テスト／契約テスト、次にそれ以外では実施が現実的でない境界条件のユニットテストです。テストレイヤーを重複させたり、カバレッジを追い求めたり、機能開発でTDDを必須にしたり、過剰なE2Eを追加したりしないでください。
4. 可能な場合、検証専用の実行可能ファイルはワークスペースの外に置きます。それ以外の場合は、受け入れ前に削除します。観測可能な契約を保護し、一般的なテスト配置と確立されたコマンドを使用する場合に限り、1つだけ残します。
5. 未解決の依存関係またはツールのバージョンを固定する場合は、稼働中のレジストリからのみ取得し、出典と日付の証拠を残します。
6. 基準、サブタスク、コミット、対象を絞ったチェック、スモークテストの証拠を、実行台帳、任意の自律実行記録、または最終記録の編集にまとめます。サブタスクまたは子項目ごとにバックログ記録を変更またはコミットしないでください。
7. スコープを決して広げないでください。隣接する変更が作業を妨げる場合は、承認済みのバックログ処理が必要です。

内部の暫定実行はこれらの手順の後に停止し、コミットと簡潔な証拠をオーケストレーターに返します。レビュー、プライマリ、Wiki、ランク、クレーム、ステータス、アーカイブには決して触れません。

レビューと最終検証

受け入れ単位ごとに、包括的な $code-review を正確に1回実行します。単独の項目では最後に、Epicをまとめて完了する場合はその過程で実行します。アクティブなEpic受け入れ単位内で、暫定的な子項目を個別にレビューしないでください。セキュリティ／認証、破壊的なマイグレーションや信頼できるデータ損失のリスク、公開APIの互換性がある場合は、レビューで分割されたStandards／Specモードを選択します。これらの条件によってレビューを追加することはありません。

スコープ内のすべての指摘を修正し、修正差分を直接確認して、影響を受けるチェックだけを再実行します。修正レビューや差分レビューを実行しないでください。修正に未承認のスコープが必要な場合は停止します。

レビューへの対応が安定したら、受け入れ単位ごとに、サポート対象の代表的なターゲット1つで全テストスイートを一度だけ実行します。変更したコードがプラットフォーム固有の動作、アダプティブレイアウト、互換性、パッケージング、マイグレーション、その他のマトリックスに左右される契約に関わる場合に限り、デバイスやランタイムを増やし、各次元が該当する理由を記録します。リリースの結果を得る場合は、常にサポート対象の完全なマトリックスを実行します。その後、コードに影響する変更を行わないでください。避けられない変更によってテストスイートが無効になった場合は再実行し、その例外を報告します。バックログ、Wiki、実行記録、その他の実行されないドキュメントは、テストスイートを無効にしません。

整合

受け入れ単位のレビューと検証が完了したら、実装全体を、リンクされた wiki の概念、調査、ガイダンス、起草済みの決定と一度照合します。

• 永続的な変更なし → 理由とともに wiki reconciliation: no update required を記録します。
• 永続的な変更あり → $wiki を提案のみのモードで呼び出し、単独項目または Epic 全体を対象とする、受け入れ状態を正確に反映した単一のトランザクションを起草します。承認済みの子項目／Epic の決定と、ADR の置き換えをすべて含めます。公開前に ADR ID を割り当ててはいけません。
• 構成した実装に ADR の重要性テストを適用します。承認済みスコープに含まれていない、新たに重要と判断された決定がある場合、受け入れ前に承認済みのバックログ草案が必要です。
• 文言が wiki_refs の範囲外の知識を断定する場合、有効な ADR と矛盾する場合、または記録に一度も含まれていない場合は、オーナーの承認を得るまで停止します。

最終トランザクションまで、提案とすべての基準／サブタスク／レビュー／スイートの証拠を呼び出し台帳に保持します。作業ブランチで受け入れ済みの wiki の状態を編集してはいけません。また、完了の証拠を別途コミットしてはいけません。

受け入れと完了

単独項目または Epic 全体について、次の手順を実行します。

1. ライブの主張、裏付けのある基準とサブタスク、包括的なレビュー 1 回、根拠のあるマトリックス拡張を含む代表的なフルスイートの新規実行 1 回、正確な整合、バリデーターの合格、意図しない変更がないことを確認します。
2. 受け入れブランチをマージコミットで一度だけ primary にマージします。スカッシュマージやファストフォワードマージは行いません。コードに影響する入力を、検証済みブランチの状態と比較します。一致する場合はスイートを再利用し、異なる場合、または分類が不確かな場合は、影響を受ける対象を絞ったチェックまたはスイートのみを再実行します。
3. primary 上で node scripts/validate-project.mjs を実行します。実行可能でないバックログ、wiki、トランスクリプト、またはドキュメントの変更によって、実行可能な検証が無効になることはありません。
4. 承認済みの wiki トランザクションを primary 上で一度適用します。起草済みの ADR をすべて公開し、インデックス／ログを更新し、検証して、wiki のパスのみをコミットします。受け入れ後に不足または古くなったガイダンスがあれば、一度だけ提示します。wiki のみの変更後に実行可能なスイートを再実行してはいけません。
5. 検証済みの最終バックログトランザクションを一度適用します。単独項目の場合：蓄積した証拠を記録し、その項目の claim を解除し、決定を解決済みにし、done に設定して、rank を削除し、アーカイブします。Epic の場合：蓄積した Epic／子項目の証拠を記録し、すべての claim を解除し、すべての決定を解決済みにし、各子項目と Epic を done に設定し、すべての rank を削除し、Epic ディレクトリ全体を archive/epics/ に移動し、インデックスをアトミックに更新します。自律実行のトランスクリプトが提供されている場合は含めます。
6. 最終トランザクションのパスのみをステージし、差分を検証して、一度だけコミットします。Epic の子項目を、それより前に done にしてはいけません。

マージ、承認、整合、または必須チェックに失敗した場合は、done にする前に停止します。保留にする場合は、$create-conventional-branch の復旧プロトコルに従い、claim を解除し、未完了のレコードを ready に戻し、受け入れブランチを削除します。

完了と報告

最終トランザクションと検証の後、$create-conventional-branch の受け入れ後のクリーンアップに従い、primary にとどまります。スコープ、ブランチと claim、子項目の順序、コミット、レビュー、スイートとマトリックスの根拠、受け入れマージ、整合／ADR、ガバナンストランザクション、アーカイブ、ガイダンスの不足、ブロッカーを報告します。

最後に Next step: を記載します。ブロックされている場合は、正確な再開コマンドを記載します。それ以外の場合は、次に rank が最も高い単独項目または Epic を指定する $implement、または次に未解決の成果を示す $discuss を記載します。