implement-feature

機能の実装

高レベルのビルドオーケストレーターです。計画を、タスクに分割し、それぞれを implement-and-review に委任することで、動作するレビュー済みの機能へと仕上げます。メインエージェントであるあなた（Opus の担当者。モデル ID は shared/references/model-roster.md にのみ記載）には、タスクの分割、依存関係の DAG とスケジューリング、タスク間の統合、機能全体の最終レビューを担当してもらいます。タスクごとの実装（FE/BE の分割、モデル間レビュー、TDD）は implement-and-review の担当です。これを呼び出してください。再実装しないでください。

パイプライン：計画 → to-tasks（垂直スライス）→ タスクごとに implement-and-review（依存関係がなければ並列実行）→ 依存順に統合 → 機能全体の full-review → 完了。

詳細なスケジューリング／統合コマンドについては、references/feature-orchestration.md を参照してください。フェーズ 1 の前に必ず読んでください。

厳守事項

1. to-tasks で分割します。 計画を、機械的に検証可能な受け入れ条件、ゲートフラグ（レンズと security）、および blocked_by 依存関係を備えた、トレーサーバレット方式の垂直スライスタスクに分割します。
2. タスクを価値と並列処理の単位とします。 依存関係のないタスクは並列実行し、依存タスクはブロッカーが完了するまで待機します。
3. 各タスクを implement-and-review に委任します。 FE/BE/TDD／クロスレビューのロジックを重複して実装せず、タスク、タスクごとの --slice 名前空間、およびビルドの基点を渡します。
4. 書き込みには承認が必要です。 ユーザーがタスク分割を承認するまで、コードを変更してはいけません（--auto の場合のみ省略できます）。
5. 依存順に統合します。 依存タスクを開始する前に、各タスクが受け入れ条件を満たす必要があります。
6. 機能全体の最終レビューを行います。 すべてのタスクを統合した後、機能全体に対して full-review を実行します（タスクごとのレビューはすでに実施済みのため、タスク間の接続部分に重点を置きます）。指摘事項に対応し、すべてのチェックを通過させます。
7. 上限を設け、必要に応じてエスカレーションします。 タスクの implement-and-review が 3 サイクルの上限に達した場合はエスカレーションします。そのタスクがブロックするのは依存タスクのみで、依存関係のないタスクは続行します。
8. 担当者を捏造しないでください。 適切な縮退に従って縮退させます。

事前確認

1. ホストと git。 ワークツリー（したがって並列タスク）には git が必要です。git がない場合は順次実行に切り替えます。
2. 担当者。 共有プローブを使って、作業の開始時に主要な担当者を確認し、すべてのタスクが失敗する事態を防ぎます。python3 .agents/skills/shared/scripts/discover_runners.py probe --native-agent yes --seat codex --seat opus --seat kimi --format json を実行してください。各タスクの implement-and-review には、デフォルトの Codex 担当者と、ネイティブまたはランナー経由で利用可能な Opus 担当者が必要です。代替レビュー担当者の第 1 候補は Kimi です。
3. 検証コマンド。 プロジェクトで機能全体のテスト／ビルドに使うコマンドを特定します。to-tasks の受け入れ条件では、実際に存在するコマンドを使用する必要があります。
4. 並列実行数の上限。 デフォルトでは 同時に実行するタスクは 3 つです（各タスクで FE と BE のビルドをすべて実行します）。担当者やコストの制約が厳しい場合は、上限を引き下げてください。
5. 基点と成果物。 HEAD を機能の <base> として記録し、機能統合ブランチを作成します。分割結果、タスクごとのサブディレクトリ、レポートには .ai-workflow/impl-review/<session_id>/ を使用します。

フェーズ 0 — 計画と分解（ゲート）

1. 計画を受け取ります。 情報源：ユーザーが提示する計画／仕様、既存の TASKS.md またはトラッカーのイシュー、あるいは models-consensus のポールモードレポート（--from-consensus <path> で渡します。例：.ai-workflow/consensus/<session_id>.md）。その Consensus answer を計画として採用し、Open caveats は先にユーザーと解決します。

   ビルドに先立ってコンセンサス実行が行われる場合、引き継ぎには次の 3 つのルールが適用されます。

   • 依頼を先入観なく評議会に提示します。 評議会には、回答すべきタスクとして生の依頼を渡します（"determine what this feature requires and the best approach: <request>"）。オーケストレーターが依頼を事前に分析したり、独自の解釈を加えたりすることはありません。偏りのないファンアウトこそが、ポールの価値そのものです。
   • 両方の実行で同じセッション ID を使います。 コンセンサス実行とこのビルドでは、1 つのセッション ID を共有します（.ai-workflow/consensus/<id>.md → --from-consensus）。これにより、ビルドは生成済みのコンセンサスをそのまま使用し、再実行、言い換え、2 回目のポールは行いません。
   • コードが不要なら停止します。 コンセンサスの結果、依頼が実装すべき作業ではなく質問や判断だと分かった場合は、ここで停止し、タスクへの分解は行わずにコンセンサスの回答を返します。

2. to-tasks で分解し、受け入れ条件、ゲート、依存関係を含む垂直スライスのタスクにします。作業が実質的に 1 つのタスクで済む場合は、to-tasks を省略して implement-and-review を呼び出し（その後停止します）。

3. タスク一覧（タイトル、依存関係、受け入れ条件、ゲート、HITL／AFK）と検証コマンドを提示します。--auto が指定されていない限り、コードを書く前に承認を得ます。

フェーズ 1 — DAG のスケジュール設定とビルド

blocked_by から依存関係グラフを作成します。その後：

• HITL タスクを先にスケジュールし、AFK タスクは無人で実行します。
• 現時点でブロックされていないタスクを、上限まで並行して実行します。それぞれのタスクについて implement-and-review を実行し、タスク概要、タスクごとの --slice <task> 名前空間、--base = 現在の機能統合ヘッド（各タスクが統合済みの作業をベースにするため）を渡します。references/feature-orchestration.md を参照してください。
• 各タスクのビルドが完了し、その受け入れ契約を満たしたら、依存関係の順序に従って機能統合ブランチに統合し、準備状況を再計算して、次に実行可能なタスクに着手します。
• すべてのタスクが完了するか、エスカレーションされるまで続けます。エスカレーションされたタスクがブロックするのは、その依存タスクだけです。
• 進捗（完了／実行中／ブロック中）を報告し、タスクを黙って放棄してはいけません。

実行状態

機能の作業は何時間にも及び、多くのサブプロセスが関わるため、DAG の進捗はトランスクリプトではなく台帳に記録します。このスキルは shared/references/run-state-contract.md に従います。データの形式、試行／ゲート／副作用のルール、再開プロトコルについては、そちらを読んでください。機能レベルの実行状態は 1 つだけとし、各 implement-and-review が保持するタスクごとの状態と並べて管理します。ここでは機能固有のキーのみを示します。

• ceilings.max_in_flight — 並行実行の上限（既定値は 3）。推測ではなく、実際に実行中のタスク数を数えて上限と照らし合わせます。
• side_effects のキーは merge:<task-id> — タスクを機能統合ブランチにマージする前に記録します。キーがすでに存在するマージはスキップします。
• 統合ヘッドは再開時のアンカーです。 steps のエントリーは安定した T-ID をキーとするため、すでに steps にあるタスクは完了済みです。再開時は、現在の統合ヘッドを読み直し、台帳から準備状況を再計算して、残りのタスクだけをスケジュールします。再開した機能で、統合済みのタスクを再ビルドすることはありません。エスカレーションされたタスクは未処理ではなく終了したタスクです。結果と理由を steps に記録し、最終レポートが記憶ではなく台帳から再構成されるようにします。

フェーズ 2 — 機能全体の最終レビュー

すべてのタスクを統合した後、機能全体（機能の<base>との差分）を対象に、タスク間の統合と接合部分、およびタスクごとのレビューでは確認できなかった点に重点を置いて、full-reviewを実行します。いずれかのタスクがセキュリティ上機微な内容を扱う場合は、security_focus=trueにします。指摘事項に対応し（implement-and-reviewを介して担当タスクの実装者に割り当てるか、対象を絞って修正します）、その後、フルスイートがすべて成功することを再確認します。

フェーズ 3 — 報告

結果をその場で報告し、.ai-workflow/impl-review/<session_id>/report.mdに次の内容を記載します。

1. 機能と最終ステータス（done／partial／escalated）。
2. タスク — タスク、依存関係、ステータス、受け入れ条件の結果、レビューサイクル数、並列で実行したタスクをまとめた表。
3. 統合 — マージした順序、解決したコンフリクト。
4. 機能全体の full-review — 判定、深刻度別の指摘事項、修正内容、保留事項。
5. 検証 — コマンドと結果（成功／失敗）。
6. ブランチ／ワークツリー — 機能統合ブランチと、その確認方法および取り込み方法。依頼がない限り、プッシュ、PR の作成、ワークツリーの削除は行いません。
7. エスカレーション — ビルドの 3 サイクル上限に達して停止したタスクと、未解決の指摘事項。

状況に応じた柔軟な対応

• Git リポジトリではない場合： タスクを作業ツリーで順次実行します（各タスクでimplement-and-reviewの Git なしのフォールバックを使用）。並列実行はしません。
• 利用可能な枠が少ない／コストが厳しい場合： 上限を 1 に近づけます（タスクを順次実行）。
• タスクが 1 つの場合： DAG を省略し、implement-and-reviewを呼び出して結果を報告します。
• タスクがエスカレーションされた場合： 独立したタスクの作業は続け、エスカレーションを報告書に記載します。

注意事項

• implement-and-reviewを再実装しないでください。 このスキルの対象は、タスク分解、DAG、タスク間の統合、機能全体のレビューのみです。
• 各タスクは古い機能ベースではなく、現在の統合 HEAD（--base）を基に作業します。これにより、後続タスクは先行タスクの変更を反映した状態で作業できます。blocked_byを守り、同じファイルに触れる可能性が高いタスクは並列化せずに実行します（blocked_byを追加してください）。
• タスクごとのレビューは各implement-and-review内ですでに実施されています。機能全体のfull-reviewでは、すべてのタスクを再度レビューするコストを避けるため、接合部分を対象にします。
• 垂直分割と水平分割： to-tasksのタスクは垂直分割（全レイヤーを含む）です。implement-and-reviewでは各タスクを水平分割（FE／BE）します。タスクが外側の単位であり、FE／BEの分割は各タスクの内部で行われます。
• オーケストレーターで状態を管理し、DAG と統合 HEAD を追跡します。各タスクの完全なトランスクリプトではなく、簡潔なレポートを確認します。