engineering-loop

エンジニアリングループ

最小限の監督と、リスクに見合った検証で、変更を検証済みの状態で届けます。 まずはエージェントを1つ使用します。権限があり、独立した作業やレビュー範囲の拡大によって負担に見合う効果が得られる場合に限り、委任します。適用されるリポジトリおよびチームの要件に従います。このスキルでは、チケット管理やエージェントの必須利用プロセスは追加しません。

ベースラインを確立する

1. 適用対象の AGENTS.md ファイルとリポジトリのドキュメントを読みます。
2. 要求された動作、制約、確認可能な完了条件を記録します。
3. ブランチと作業ツリーを調べ、ユーザーが所有する無関係な変更を保持します。
4. 共有動作を変更する前に、対象を絞った検索や利用可能なコードグラフを使って、影響を受ける呼び出し元、利用側、テストをたどります。関連する経路に沿って調査範囲を広げます。
5. リポジトリで標準的な検証方法を特定し、既存の不具合とタスクによるリグレッションを切り分けられる、最小限で安全なベースラインを実行します。

通常の選択は根拠に基づいて行います。不足している権限や重要な判断がある場合に限り、確認を求めます。重要な判断には、受け入れ条件が曖昧な場合、公開動作に互換性のない変更がある場合、またはすでに許可されていない破壊的な副作用やデータ変更が含まれます。回答を待つ間も、許可された独立作業は続けます。

必要なリファレンスだけを読み込みます。

• 長期にわたる作業、複数のスタックにまたがる作業、または高リスクの作業：loop-contract.md。
• 反復作業や明示的な予算がある場合：loop-policy.md。
• 間欠的な不具合、パフォーマンス問題、または未解決の不具合の場合：hard-debugging.md。
• 個別レビューが依頼された場合、またはリスク上妥当な場合：independent-review.md。

ループを実行する

1. 不具合を再現するか、機能の現在の動作を記録します。
2. 一貫性のある最小限の変更と、その変更を証明する根拠を選びます。
3. 可能な場合は、まず失敗するリグレッションテストを追加します。
4. 範囲を限定した変更を1つ実装し、関連する最小限のチェックを実行します。
5. 計画外の経路が必要になった場合は、その理由を記録し、スコープとチェック内容を更新します。
6. 失敗を、製品、テスト、環境、前提、外部要因によるブロッカーに分類します。環境の失敗を隠すために製品コードを変更してはいけません。
7. 影響を受ける利用側のチェックと、リポジトリで必須とされているより広範なチェックを実行します。
8. 完全な差分をまずタスクの契約に照らして確認し、次にコード品質、リグレッション、セキュリティ、保守性の観点で確認します。
9. 重大な指摘に対処し、その修正の影響を受けるチェックを再実行します。

受け入れの根拠がそろい、必須のチェックに合格したら、新たな変更や失敗、未解決の懸念がある場合に限り、チェックの範囲を広げたり、繰り返したりします。テストは、動作や重要な不変条件を証明する場合に追加します。影響の小さい編集をそのまま反映するだけのテストは追加しません。

テストハーネスがない場合は、入力、期待される動作、確認結果を含む、小規模で繰り返し実行可能なスクリプトまたは文書化された手動チェックを使います。自動テストの不足を記録します。ビルドだけでは実行時の動作を証明できません。このループを満たすことだけを目的に、大規模なテストフレームワークを追加してはいけません。

完全なログではなく、事実、変更したファイル、コマンド、結果、次の判断を簡潔に記録します。

停止条件

• 同じ失敗が2回続いたら、盲目的な再試行を止め、原因を再分類してください。 関連する状態が変わるか、証拠を得られる調査を行った場合にのみ再開してください。
• 新たな証拠がないまま調査やレビューが繰り返される場合は、差分、 未解決の問題、次に有効な調査をチェックポイントとして記録してください。同じサイクルを再開しないでください。
• 権限やシークレットの不足、インフラの利用不可、許可されていない破壊的な操作、 または未解決の重大なプロダクト上の判断が進行に必要な場合は、停止してブロッカーを報告してください。
• 明示的に定められたループの予算を使い切ったら、予算を黙って拡大せず、最新の判定証拠を示して停止してください。 明示的な予算がない場合は、上限を定めた次のアクションで新たな証拠が得られる間に限り続行してください。有効な反復に恣意的な固定回数はありません。
• アサーションを弱めたり、テスト範囲を削除したり、エラーを隠したり、受け入れ基準を黙って変更したりして、失敗するチェックを通過扱いにしてはいけません。
• ユーザーが明示的に許可しない限り、本番環境へのクエリ、デプロイ、マイグレーション、マージ、公開を行ってはいけません。

証拠を添えて完了する

変更した動作とファイル、回帰テストまたは受け入れテストの証明、チェックの正確なコマンドと結果、 レビューの処置、残っている制限事項を報告してください。独立したレビューを実施した場合は、最後にレビューしたリビジョンを記載してください。検証がブロックされている場合や、重大な未解決の指摘事項が残っている場合は、完了と記載してはいけません。 記入例については、evidence-example.mdを参照してください。