implement

実装

コードパスと出力の利用箇所を根拠として、要求された動作を実現します。この変更に適した、必要最小限のフィードバックループを選びます。不確実性、統合範囲、影響が大きくなるほど、検証を強化します。

ユーザーの指示は、このスキルのガイドラインより優先されます。既存の権限を引き継ぎ、範囲内で作業を完了します。日常的で元に戻せる選択は、必要に応じて前提を明示したうえで解決します。不足情報によって結果が大きく変わる場合や、適用される境界によって必要な場合に限り、質問します。スキルのワークフローだけを理由に、新たな承認を求めてはいけません。

変更の把握

編集前にリポジトリの状態を確認し、変更対象ファイルに既存の差分があれば読みます。チェックアウトを共有領域として扱います。自分が作成していない作業を保持し、所有権の申告を尊重します。

実際の呼び出し元と利用箇所を通して、動作をたどります。関連する最も近いパターン、テスト、実際に使用するゲートコマンドを特定します。コード構造に関する質問では構文で検索し、名前や説明文についてはテキスト検索を使います。変更の理解に必要な範囲を読みます。最低限読むファイル数を設けたり、広範なコンテキストを一度に読み込んだりする必要はありません。

設定済みのメモリーワークフローを使って、把握しにくい過去の決定を確認します。変化しやすい API、依存関係、デプロイに関する主張は、現在の一次情報またはインストール済みバージョンと照合して再確認します。慣れていないフラグを推測せず、必要に応じて専門ツールのガイダンスを読み込みます。

原因の診断と実装を区別します。「なぜこうなるのか」という問いには、まず確認済みの原因で答えます。修正が許可されたら、壊れた動作と意図した動作を見分けられる確認方法を定めます。

検証可能な範囲を選ぶ

状況	次の対応
明確で影響の小さい編集	編集を行い、関連する構造面または動作面のチェックを実施します
観測可能な失敗を伴うバグ	再現して原因を切り分け、修正を検証します
境界をまたぐ新しい動作	テストを伴う、代表的なエンドツーエンドの範囲を実装します
共有インターフェースまたはスキーマの変更	契約を変更する前に、利用箇所と互換性をたどって確認します
不確実性の高い大規模な変更	依存関係と受け入れ基準を整理するために plan を使います
有用な統合方法がある独立した作業	許可された委任と明示的な所有権のもとで進めます

実装とその検証を一緒に進めます。先行するテストが設計の指針になる場合、機能が完成するまでテストをすべて後回しにしてはいけません。同様に、手順を踏むことだけを目的として、元に戻せるテキスト編集にテストを追加する必要もありません。

一貫した動作または契約の境界で作業を区切ります。ファイル数や編集回数は、常に適用できる作業間隔の基準ではありません。誤った前提をもとに作業を積み重ねる前に、次に起こりそうな失敗を見つけられる、最も低コストのチェックを実行します。

設計に説明責任を持たせる

具体的な問題によって逸脱が正当化されない限り、既存のパターンに従ってください。別のスタイルを好むという一般論ではなく、その理由を説明してください。

圧力	判断
新しいモードや設定が追加される	それぞれを、要求された動作または実証された差異に結び付けます
同じ判断が複数の呼び出し元で繰り返される	その判断を適切な単一の所有者に任せます
ラッパーが呼び出しを転送するだけである	削除する前に、API、ポリシー、またはテストの境界を強制しているか確認します
キャストが互換性のないデータを覆い隠す	実際の境界でコントラクトを修正するか、検証します
フォールバックがエラーを隠す	失敗の原因を保持し、意図された復旧を明示的に処理します
互換性コードが増え続けている	残すか削除するかを決める前に、リリース済みの利用者とロールアウト要件を確認します
複雑さが増え続けている	別の特殊ケースを追加する前に、所有権とデータフローを再検討します

実際の境界を強制する抽象化なら、2つ目の呼び出し元が現れる前でも有用な場合があります。エラーの挙動や互換性をわかりにくくするなら、実装が短くてもかえって劣ることがあります。行数だけでなく、概念とコントラクトを評価してください。

編集は依頼された範囲内にとどめてください。自分の変更によって生じた不要なインポート、古くなったラベル、使われなくなった分岐は削除してください。無関係な問題を扱う必要がある場合は、プロジェクトのサイドクエストまたはイシューワークフローに回してください。実装に黙って取り込まないでください。

スケーラビリティの問題が発生したら、競合しているリソースを特定してください。原因に対処するため、分離、インデックス作成、バッチ処理、所有権、または容量を改善します。一時的な同時実行数の削減は、管理された原因調査や承認済みのインシデント緩和には役立つ場合がありますが、ひそかに恒久的な解決策にしてはいけません。

意図する主張を検証する

実際のリポジトリと影響を受ける動作に基づいて、チェックを選択します。

チェック	確認できること	よくある制限
型／静的解析	選択した型および構造上の特性	実行時の動作は実行しません
対象を絞った動作テスト	意図したケースで変更箇所のパスが実行されること	モックによって統合部分が迂回される場合があります
パッケージまたは統合チェック	影響を受けるコンポーネント間の契約が保たれること	パッケージ化やデプロイの違いが対象外の場合があります
ビルド／パッケージ検証	成果物を生成できること	インストールまたは使用できることは証明しません
利用者側のチェック	成果物が想定する利用者に役立つこと	観測した環境とケースに限られます

内側のループでは範囲を絞ったチェックを使い、関連するコミットまたは納品の境界までに、必須のリポジトリゲートを実行します。共有依存関係や失敗、残存リスクに応じて、テストの範囲を広げてください。適切なチェックに合格したら、無関係なスイートを繰り返し実行せず、完了に進みます。

コマンドの終了コードと生の失敗ログを保持してください。パイプラインの状態を処理しない限り、tail へのパイプで失敗したコマンドが見えなくなることがあります。詳細なログは取得した後に要約してください。任意のタイムアウトを設定したり、他のエージェントの作業に対して自動修正を実行したりしないでください。フィルター付き実行を信頼する前に、実際のテストフレームワークにおけるテスト選択の仕様を確認してください。

有用な実行記録には、コマンド、リビジョンまたは作業ツリーの状態、該当する場合は環境、終了ステータス、実際に実行された内容を記載します。意図したテストを選択するフィルターがテストを1件も選択しなかった場合、その変更は検証されていません。入力が一致するなら、キャッシュ結果も正当な場合があります。その場合は、実行したばかりの結果として説明せず、キャッシュ結果であることを明示してください。経過時間だけでは、作業が行われたこともゲートに欠陥があることも証明できません。

利用境界をチェックする

成果物	代表的な検証方法
生成された設定	変更の動機となった不変条件について、合成後の出力を確認する
パッケージ	宣言されていない兄弟依存関係なしで、ビルド済みディストリビューションをインストールして呼び出す
UI	可能であれば agent-browser を使い、実際の画面で変更された操作を試す
CLI	影響を受けるエラー時やデフォルト時のパスを含め、関連するコマンドを呼び出す
データベースマイグレーション	代表的なスキーマ／データに適用し、互換性またはロールバック要件を確認する
サービス	実行中のリビジョンを確認し、変更されたリクエストパスを試す

「コマンドが成功した」ことだけでなく、不変条件を確認してください。構文上有効なセレクターでも、何も一致しない場合があります。パッケージをビルドできても、インポーターに必要なファイルが含まれていないことがあります。修正をマージしても、デプロイ済みの成果物に反映されていない場合があります。

本番環境への適用など、外部に影響を及ぼすチェックには、引き続き該当する承認が必要です。利用可能なローカルの根拠をすべてそろえ、ライブ環境でのチェックに合格したかのように示すことなく、残る制限を報告してください。

新しい検出器やガードには、正と負の両方の根拠が必要です。捕捉すべき失敗を意図的に発生させて検証し、通常の動作は引き続き許容されることも確認してください。パフォーマンスの変更には、ベースライン、代表的なワークロード、関連するリソース測定が必要です。観測できない画面については、人間が結果を見分けられる手順と期待される結果を示してください。スクリーンショットやハードウェアに関する判定を捏造しないでください。

仮説を更新して復旧する

再度編集する前に、失敗を分類してください。環境の障害、古い生成物、呼び出し方の誤り、共有出力の競合、ランタイムの不具合では、それぞれ異なる対応が必要です。元のエラーを保持し、下流の症状をすべて修正するのではなく、最初に失敗した依存関係を特定してください。

修正が失敗したら、その結果によって何が否定されたのかを述べ、残る説明を見分けられるチェックを選んでください。新たな証拠がないままバリエーションを繰り返すのは、試行回数にかかわらず、問題の捉え直しが必要なサインです。診断の代わりに、隣接する箇所のリファクタリングを行わないでください。

ベース上での失敗は、その症状が変更前から存在していたことを示す場合がありますが、トレースに変更したファイル名がないことは、それを示しません。再実行に成功しても、不安定な動作が無害だとは証明されません。失敗の原因を判断する前に、同じコマンド、入力、リビジョン、環境で比較してください。CI とインシデントの詳細な手順は、references/recovery.md に記載されています。

一貫性のある作業をレビューしてコミットする

プロジェクトのコミットポリシーに従ってください。アトミックなコミットが求められる場合は、無関係な作業をため込まず、検証済みの論理的なまとまりごとにコミットしてください。動作変更には、それを理解するために必要なテストを含めてください。レビューが明確になり、有効な中間状態を保てる場合は、機械的な移動を分けてください。

ステージングする前に、ステータスと差分を確認してください。自分が担当するパスまたはハンクを明示してステージングし、ステージ済みのパッチを確認して、他の人のインデックス変更を含めないようにしてください。現在のプロジェクトのメッセージ規則と帰属規則に従ってください。共有インデックスの処理、ワークツリー、リベース、競合からの復旧には git を使用してください。プッシュ、マージ、リリースの権限は、このスキルではなく、ユーザーとプロジェクトの取り決めに従います。

コミットまたは統合のチェックポイントで、差分全体がタスクに沿っているか比較してください。テストがすべて成功していても、不要な変更が含まれている場合があります。レビューでの指摘には、実証された仕組みと影響が必要です。すべての提案を新たな要件とみなすのではなく、ブロッカーと任意の改善を選別してください。

プロジェクトで求められる場合、またはリスクの大きさから妥当な場合は、重要でないとは言えない変更について、独立した敵対的検証を受けてください。利用可能で適用可能な場合は、cross-model-review を使用してください。別のモデルによって盲点が見つかることはありますが、相関した誤りがなくなるわけではありません。重要な指摘は証拠に照らして検証し、判定をレビュー対象の状態に結び付けてください。レビューが未完了の場合は、そのように報告してください。

状態を保持して完了する

引き継ぎ時またはコンテキスト圧縮時には、元の結果、ユーザーによる修正、変更したパス、リビジョン、すでに実行したチェック、未解決の指摘、次のステップを保持してください。作業を再開する際は、続行する前に現在のステータスを再確認してください。別のエージェントがツリーを変更している可能性があります。

再発見を防げる場合は、設定済みのメモリーに、長期的に役立つ原因と修正を記録してください。何を変更したか、なぜ変更したか、それを裏付けるもの、未検証の重要な範囲を報告してください。その結果が得られるまで、許可された必要な作業を続けてください。

証拠と参考資料

レビュー日：2026-09-04。Astra guidance では、小規模なタスクに対する過剰なテストや、指示の競合によって不必要に作業を妨げることが明示されています。ここで定める、リスクに応じたチェックとユーザーの指示の優先は、こうしたリスクに対処するものです。

ワークフローの有効性を評価する場合、またはベンチマークの主張を解釈する場合は、references/benchmarks.md を読んでください。CI の選別、断続的な失敗、インシデントからの復旧については、references/recovery.md を読んでください。どちらの参考資料も、普遍的に適用できる編集比率や、モデルに依存しない性能保証を示すものではありません。

アンチパターン

アンチパターン	より良い対応
編集回数を適当に決めてから検証する	不確かな新しい契約に依存する前に検証する
小さな変更でもすべてのスイートを実行する	必須かつ関連性のあるゲートを実行し、証拠に基づく理由がある場合に範囲を広げる
カバレッジを確認せずに緑のバッジを受け入れる	何が実行され、どのアサーションを裏付けているかを確認する
grep の結果が空だから既存の問題だと判断する	条件を制御した実行を比較し、因果関係をたどる
古く見えるという理由で互換性を削除する	利用者と段階的な導入に伴う義務を確認する
定型的な選択のたびに許可を求める	実行中も既存の承認を引き継ぐ
レビュアーの承認を利用者側での検証とみなす	出力が使われる箇所で変更後の動作をテストする

このスキルではないもの

• 固定された手順、編集回数の上限、必須の調査段階、またはエージェントの割り当てではありません。
• 周辺コードの変更、承認の回避、未実行のチェックを実行済みと主張することを許可するものではありません。
• 実際の実装とその利用者を理解することに代わるものではありません。