implement-small-change

小規模な変更を実装する

リスクを隠すことなく、要求された動作を証明できる最小限のワークフローを使用します。

1. 範囲を明確にする

編集する前に：

1. 適用されるリポジトリの指示を読み、現在の Git ステータスと差分を確認します。ユーザーによる無関係な変更は保持します。
2. 求められている観測可能な結果を一文で述べ、それを証明できる最小限のチェックを特定します。
3. 変更が小規模だと判断する前に、リポジトリの状況を把握します。エージェントに組み込まれたファイル検索よりも、ユーザーが現在利用できるローカル MCP や、リポジトリを認識するその他のツールを優先します。
   • コードベースのナレッジグラフ MCP が利用できる場合は、まずそれを使用します。リポジトリがインデックス化されていない場合は、クエリを実行する前に、そのツールで必要なインデックス化またはセットアップを完了します。その後、影響を受けるシンボルと影響範囲を把握するために、グラフ検索、依存関係や呼び出し元のトレース、対象を絞ったコード取得、アーキテクチャや関連性のクエリを優先します。
   • ローカルでリポジトリを認識する MCP やリポジトリナビゲーションツールがほかに利用できる場合は、rg、glob、広範囲なファイル読み込みを行う前に使用します。
   • 適切な MCP／リポジトリ認識ツールが利用できない場合、またはそのツールの結果が不十分、古い、もしくは該当しない場合に限り、エージェントに組み込まれたツールに切り替えます。グラフがモデル化していない文字列リテラル、設定、スクリプト、その他の非コードファイルには、組み込み検索を引き続き使用できます。
   • リポジトリ固有の調査手順に従い、利用可能な中で最も信頼できる証拠を使用します。ドキュメントに名前が記載されているというだけで、ツールが利用できると決めつけてはいけません。
4. 関係する正確なシンボルまたは設定を特定します。選択した調査ツールを使って、関連する呼び出し元、呼び出し先、テスト、コントラクト、実行時の経路を確認します。
5. 意味上の影響を分類します。ファイル数だけで分類してはいけません。共有コントラクトへの一行の変更でも影響範囲が広いことがあり、同じ箇所にまとまった複数ファイルの変更でも局所的な場合があります。

リポジトリ、実行環境、ログ、ツールから把握できる情報をユーザーに尋ねてはいけません。

2. 範囲の判定ゲートを適用する

以下の条件をすべて満たす場合に限り、簡易な進行手順を続けます。

• 要求されている動作が一つに定まり、期待される結果が明確である。
• 影響を受ける呼び出し元と、その下流の動作を把握している。
• 変更が一つのモジュールまたは確立された境界内に収まる。
• 対象を絞ったチェックで、要求された動作または元の不具合を検出できる。
• 変更を簡単に元に戻せ、破壊的な状態変更や外部状態の変更を行わない。
• 以下の中断条件に該当するものがない。

以下のいずれかに該当する場合は、中断します。

• 新たな判断が必要になる形で、変更がプレゼンテーション、API、ドメイン、永続化、インフラストラクチャの各レイヤーをまたぐ。
• パブリック API、シリアライズ形式、イベント、共有コントラクト、データベーススキーマ、マイグレーション、互換性の保証を変更する。
• 認証、認可、セキュリティ、プライバシー、支払い、トランザクション、並行処理、キャッシュ無効化、分散ワークフローに関わる。
• ドメイン用語、状態遷移、不変条件、所有権ルール、アーキテクチャ上の境界を新たに導入または変更する。
• 複数の解釈があり、それぞれでユーザーから見える動作が異なる。
• 共有ユーティリティまたは主要な経路の呼び出し元に対する影響を迅速に特定できない。
• 変更を検証するための信頼できる境界またはシグナルが既存システムにない。

中断条件に該当し、未解決の判断事項やレイヤー横断の動作が明らかになった場合：

1. 要求に隠れた範囲があるため、$implement-small-change を一時停止していることをユーザーに明示します。
2. 要求されている結果、判明したシンボルと呼び出し元、影響を受けるレイヤーやコントラクト、考えられる解釈、解決が必要な判断事項を含む簡潔な影響概要を作成します。
3. その概要を使って、ユーザーが使用する質問整理スキルや計画スキルなどで判断事項を解決するよう依頼し、このスキルのワークフローを終了します。

問題の再現が難しい場合、または原因が単に曖昧なのではなく不確かなままである場合は、$diagnosing-bugs に引き継ぎます。

3. 一貫性のある最小限の変更を行う

• バグの場合、実用上可能であれば編集前に、元の症状に対する対象を絞ったチェックを実行します。高速で決定論的であり、失敗を再現できる方法を優先します。
• 微調整や小規模な機能追加の場合、既存のインターフェースを通じた最小限の垂直スライスを1つ実装します。
• 既存の適切な接点で動作を簡単に表現できる場合は、回帰テストを追加します。プロセスを満たすためだけにテストフレームワークを作成したり、内部をモックしたり、表面的なテストを追加したりしないでください。
• 周辺のリファクタリング、推測に基づく抽象化、フォーマットの大幅な変更、依存関係のアップグレード、無関係なクリーンアップは避けます。
• 要求された結果を得るために明示的に必要でない限り、現在の公開インターフェースとドメイン用語を維持します。
• 新たな証拠によって影響範囲が広がった場合は、作業範囲の確認をやり直します。

4. 変更規模に応じて検証する

この変更の誤りを検出できる、最小限のチェックを実行します。

• バグの再現手順または動作チェックをそのまま再実行します。
• 関連するテストファイル、フィルター、パーサー、リンター、型チェック、ビルドターゲット、API リクエスト、UI 操作のうち、最も対象を絞ったものを実行します。
• コンパイルや静的な契約に変更があった場合は、影響を受けるプロジェクトまたはパッケージのビルドを追加します。
• 最終的な差分とステータスを確認し、意図しない編集、デバッグ用の計測コード、契約のずれ、新たに判明した重大な阻害要因がないか確認します。

リポジトリの指示で必要とされる場合、ユーザーから明示的に求められた場合、対象を絞った結果だけでは不十分な場合、または作業範囲の確認で変更が実際には小規模でないと判明した場合を除き、デフォルトではテストスイート全体を実行したり、正式な $code-review を呼び出したりしないでください。

ユーザーまたは適用されるリポジトリのワークフローから求められない限り、コミットやプッシュは行わないでください。

5. 根拠を報告する

以下を報告します。

• 確認できた結果。
• バグの場合、判明していれば根本原因。
• 変更したファイルまたはシンボル。
• 実行した検証コマンドまたは操作と、その結果。
• より広範なチェックを意図的に実行しなかった場合は、その理由と、対象を絞った証拠で十分と判断した理由。

差分が小さいというだけで、変更が安全だと決して主張しないでください。