Forward Implementation First が最初に行うこと
Forward Implementation First は、コーディングエージェントがパイプラインの記録管理に囚われるのを防ぐために設計されたエージェントスキルです。要求されたプロダクトの構築、影響を受ける動作の検証、作業の前進に意識を向け続け、ハッシュ、レシート、ロック、ダッシュボード、進捗マーカーなどを繰り返し修復することを避けます。
このプロジェクトは主に、YAML フロントマターを含む約 150 行の Markdown スキルで構成されています。Agent Skills の規約に従っており、モデル、ツール、ドメインに依存しません。
このスキルは、オーケストレーターが順序付けられたステージのメタデータを記録する長時間実行ワークフローで特に役立ちます。そのメタデータが古くなると、エージェントは不一致を、以前は有効だった出力が誤っている証拠と取り違えることがあります。Forward Implementation First は、実際の正確性に関する作業と管理上の保守を分離する判断ルールを提供します。
中核となる分類
エージェントは、アクションを実行する前に、それを次の 3 つのカテゴリのいずれかに分類します。
- 意味的な実装: プロデューサー、コンシューマー、アダプター、ランタイムパス、スキーマ、フィクスチャ、または最終出力を構築・接続する作業。
- 重点的な検証: 動作、スキーマ、件数、順序付きサンプル、保存性、一貫性、非切り捨て、測定した時間やメモリを通じて、変更された依存関係の範囲を調べるチェック。
- 管理上の記録管理: ハッシュ、ロック、レシート、ダッシュボード、認定マーカー、進捗メタデータ、または存在だけを示す記録を生成・修復する作業。
運用ルールは単純です。意味的な実装と重点的な検証は実行します。ユーザーが明示的に要求した場合、または成果物がプロダクトの一部である場合を除き、管理上の記録管理は省略します。正確性を守ることなく、記録管理だけを行う依存関係が生産的な作業を妨げる場合は、その依存関係を取り除きます。
パイプラインの記録管理が問題になる理由
ステージ 40 がステージ 41 用のファイルを作成するパイプラインを考えてみましょう。オーケストレーターは、完了マーカーと入力ハッシュを含む JSON レコードも書き込みます。プロデューサーが変更されると、既存のステージ出力が正しいままであっても、ハッシュが一致しなくなることがあります。
明確な方針がなければ、エージェントは以前の多くのステージを無効とし、ステージ 41 を手動で実行することを拒否し、関係のないマーカーを再生成し、修復したメタデータを進捗として報告する可能性があります。個々の判断は慎重に見えても、全体としては要求された出力を改善することなく時間を消費します。
管理用メタデータは、出力が正しいことの証拠の代わりにはなりません。
このスキルは、メタデータの存在や新しさを証拠として扱うのではなく、結果を検証するようエージェントに求めることで、この失敗を防ぎます。
このスキルが緩和しないもの
Forward Implementation First は、正確性を無視するよう促すものではありません。使い捨て可能なオーケストレーション記録と、プロダクトを実際に守る完全性メカニズムや証拠を区別します。
- プロダクトの完全性は引き続き必須です。 ユーザーが検証するチェックサム、必須の署名、出力契約で定義されたハッシュは、事務作業ではなくプロダクト機能です。
- 入力とリビジョンの識別情報は引き続き必須です。 エージェントは、どのバージョンまたは対象を変更しているのかを把握しなければなりません。
- 結果指向のテストは引き続き必須です。 ベンチマーク、再現手順、テスト、エンドツーエンドの実行は、今後も不可欠な証拠を提供します。
- カバレッジは結果ではありません。 パスを実行しただけでは、そのパスが正しい答えを生成したことの証明にはなりません。
コマンド、入力、結果、確認した期待値を含む実行記録は、実際の証拠になり得ます。それがなければ、エージェントはその記録が裏付ける主張を行えません。ただし、記録がないからといって、パイプラインの前段にある関係のないステージが自動的に無効になるわけではありません。
インストール
検出されたエージェントスキルディレクトリにインストールする
リポジトリをクローンし、付属のインストールスクリプトを実行します。
git clone https://github.com/Vuk97/forward-implementation-first
cd forward-implementation-first
./install.shこのスクリプトは、検出したすべての対応エージェントスキルディレクトリに SKILL.md をコピーします。ドキュメントに記載されている保存先は次のとおりです。
- Claude Code:
~/.claude/skills/forward-implementation-first/ - Codex:
~/.codex/skills/forward-implementation-first/ - 共有規約:
~/.agents/skills/forward-implementation-first/
1 つのプロジェクトにインストールする
プロジェクト単位の動作にするには、スキルディレクトリをリポジトリ内の .claude/skills/ または .agents/skills/ にコピーします。これにより、すべてのワークスペースにインストールするのではなく、そのプロジェクトにポリシーを関連付けられます。
インストール後にエージェントを再起動してください。既存のセッションでは、スキルは自動的に再読み込みされません。
スキルは提案であり、読み込むかどうかはモデルが判断します。エージェントが常時有効なルールやフックに対応している場合は、中核となる判断ルールもそこに配置してください。
基本的な使い方
ステップ 1: 次に行うプロダクト関連のアクションを特定する
現在のパイプラインカーソル、または次に未完了の依存関係から始めます。提案されたアクションが実装を変更するものか、変更による結果を検証するものか、それともオーケストレーションメタデータを修復するだけのものかを確認します。
提案されたアクション: ステージ 41 をステージ 40 が生成した出力に接続する。
分類: 意味的な実装。
判断: アクションを実行する。ステップ 2: 変更された依存関係の範囲を検証する
実装後は、影響を受けた可能性のある最小の領域をテストします。適切な確認には、スキーマ、行または項目数、順序付きサンプル、保存性、整合性、切り捨ての検出、エンドツーエンドの動作、測定したリソース使用量などが含まれます。
提案するアクション: ステージ41のスキーマ、出力数、順序付きサンプルを確認し、
その生成元を変更した後に切り捨てがないことを検証する。
分類: 焦点を絞った検証。
判断: 確認を実施し、証拠を記録する。ステップ3: 既定の目的としての帳簿管理を拒否する
提案されたアクションが古い受領記録や完了マーカーの再生成だけである場合、その成果物をユーザーが要求しているか、それ自体が納品物の一部でない限り、実施しません。
提案するアクション: 変更されていないステージ12から40の完了受領記録を再構築する。
分類: 管理上の帳簿管理。
判断: 明示的に要求された場合、または製品上必要な場合を除き、実施しない。ステップ4: 管理専用のゲートを削除する
古いマーカーによって次の有効なステージの実行が妨げられているものの、正しさを保護していない場合は、ステージを手動で実行し、その出力を検証して公開し、カーソル位置から続行します。その後、同じ障害が再発しないよう、管理専用の依存関係を削除します。
前進カーソルのルールを適用する
完了済みのステージは、実質的な理由がある場合にのみ再実行またはロールバックします。このスキルでは、次の理由を認めています。
- ステージ入力の意味が変わった。
- 対象または固定されたリビジョンが変わった。
- 出力が不正な形式、切り捨て、不保存、不整合、またはコンシューマーとの互換性を欠いている。
- 観測された実行結果によって、以前の静的な結果が否定された。
- 変更された生成元の宣言済み依存関係範囲に、そのステージが含まれている。
メタデータが欠落していることや古いことだけでは不十分です。完全な履歴を再開するのではなく、影響を受けた最小の依存関係範囲を再実行します。
復旧判断の例
観測: ステージ40の受領記録ハッシュが古い。
出力確認: ステージ40の成果物は正しい形式で、ステージ41と互換性がある。
依存関係確認: 変更された生成元は、ステージ40のセマンティクスに影響しない。
アクション: ステージ40は再実行しない。ステージ41に進み、その結果を検証する。検証によって不正な形式または互換性のない出力が見つかった場合は、その理由が管理上のものではなくセマンティクス上のものであるため、再実行が正当化されます。
競合する真実を作らずにワーカープールを使用する
このスキルでは、並列作業に対する規律あるアプローチも定義しています。
- コンパイラー、完全なテストスイート、大規模なデータジョブ、ベンチマーク、長時間のスキャンなど、負荷の高いプロセスは一度に1つだけ実行する。
- 重複しないファイルに対する軽量な作業には、並列レーンを使用する。
N人のワーカーによるプールが認可されている場合は、完全なウェーブを待つのではなく、レーンが完了するたびに補充する。- すべてのワーカーを稼働させ続けるためだけに、価値の低いタスクを作らない。
- 負荷の高い実行、公開、カーソルの移動、最終的な結論はルートレーンに保持する。
- 並列ワーカーには準備と調査をさせるが、その出力を使用する前に検証する。
- すべてのレーンを待って前進を妨げない。依存関係に到達した時点で、そのレーンの結果を取り込む。
この構造により、複数のワーカーが競合する真実の情報源になることなく、有用な並行処理が可能になります。
高度なヒント
判断ルールを常時有効な設定に移す
モデルがスキルを読み込まないことがあるため、永続的なルールやフックを備えた環境では、中心となるポリシーをそこにも記述します。つまり、各アクションを分類し、実装と焦点を絞った検証を実施し、要求された場合または製品に関係する場合を除いて管理作業を避けるという方針です。
製品の整合性を明示的に定義する
どのハッシュ、署名、マニフェスト、監査記録が出力契約の一部であるかを文書化します。これにより、エージェントが本当の機能を誤って破棄することを防ぎつつ、使い捨てのオーケストレーション用マーカーは無視できるようになります。
依存関係範囲を宣言する
可能な場合は、生成元とコンシューマーの関係を明示します。明確な依存関係範囲があれば、エージェントは影響を受けたステージだけを再実行でき、不確実性による広範な無効化を避けられます。
単なる存在ではなく証拠を記録する
コマンド、入力、結果、期待される条件を特定できる記録を優先します。存在だけを示すマーカーは何かが実行されたことを示すだけですが、証拠を含む記録はそれが機能したかどうかの確認に役立ちます。
準備と権限を分離する
並列ワーカーには、ファイルの調査、パッチの準備、情報の収集をさせますが、実行権限と結論はルートレーンに限定します。マージまたは公開する前に、ワーカーの出力を検証します。
このスキルを使用する場面
Forward Implementation Firstは、次の用途に適しています。
- 順序付きステージと永続化されたカーソルを持つパイプライン。
- 後続ステージで消費される生成成果物。
- オーケストレーターがマニフェスト、ロックファイル、受領記録を生成するワークフロー。
- 継続的な人間の監督なしで続行する実行。
- 複数のエージェントまたはセッションが変更するリポジトリ。
- ETLパイプライン、段階的なデータ処理、大規模なコード移行、ビルドおよびリリースのワークフロー、ドキュメント生成、バッチ分析、複数日にわたるロードマップ。
単発のタスク、短時間の対話セッション、または監査証跡自体が納品物であるワークフローでは使用しません。ユーザーやレビュー担当者が受領記録を利用することを想定している場合、それらの記録は管理上のオーバーヘッドではなく、製品の一部です。
結論
Forward Implementation Firstは、コーディングエージェントに、製品を構築し、影響を受ける動作を検証し、パイプラインの事務作業を正しさと取り違えないという、実践的で焦点を絞った規律を与えます。前方カーソルのルールは不要な再実行を抑え、ワーカープールに関するガイダンスは安全な並列処理を支援します。スキルをインストールしてエージェントを再起動し、利用可能な場合は常時有効な設定によって、その判断ルールを強化してください。