mcpField
P
post-implementation-review

post-implementation-review

github.com/sjuneparkテスト・品質147 回インストール3 週間前に更新
リポジトリ

post-implementation-review について

Post-Implementation Reviewは、完了したコード変更をレビューし、安全で限定的な修正を適用して検証する技能です。すぐ対応できる問題と承認が必要な判断を分け、明示的な依頼がない限りステージング、コミット、プッシュは行いません。

主な機能

  1. 01対象範囲と関連コードの確認
  2. 02対応可能な重大問題の特定
  3. 03安全なBucket I修正の適用
  4. 04Bucket IIの判断を承認待ちにする
  5. 05関連する検証の実行

活用シーン

  1. 01未コミットの変更をレビュー
  2. 02実装後の明確な局所的不具合を修正
  3. 03安全な修正と設計判断を切り分け
  4. 04影響箇所を対象とした検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sjunepark/agent-scripts --skill post-implementation-review

インストール後、Claude Code で/post-implementation-reviewを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

実装後レビュー

完了した実装をレビューし、明らかで安全な Bucket I の修正を標準で適用し、Bucket I の項目がなくなるまで、範囲を限定したベストエフォートで再確認を続けます。明示的に依頼されない限り、ステージング、コミット、プッシュは行わないでください。

ワークフロー

  1. 対象範囲を確定します。

    • ユーザーが対象範囲を指定していない場合は、デフォルトで現在の未コミット変更を対象にします。
    • git status --short、関連する差分、および変更を判断するために必要な周辺コードを確認します。
    • レビュー対象の変更によって生じた問題と、既存の負債を区別します。
  2. 重要な問題をレビューします。

    • 根拠の弱い指摘をするより、指摘なしを選びます。
    • 具体的な影響対象パス、発生条件、保守担当者が取るべき対応を示せる、個別かつ対処可能な問題だけを記録します。
    • 正確性、状態とライフサイクルの順序、検証と不変条件、型とスキーマの適合性、所有権の境界、連携上の契約、テスト、ユーザーに見えるリグレッションを確認します。対象範囲内の変更ファイルすべてについて、この一覧に照らした確認が済んだ時点でレビューは完了です。
  3. 必要に応じてサブエージェントを使用します。

    • 確信度を実質的に高める、最小限のレビュー体制を選びます。多くの場合は不要で、ときには焦点を絞ったレビュアーを 1 人、範囲が広い変更やリスクの高い変更では、異なる観点を担当する複数のレビュアーを使用します。
    • 有効なサブエージェントのタスクには、ステップ 2 の各観点について新しいコンテキストでレビューすることや、並行性、セキュリティ/プライバシー、パフォーマンス、UI の動作、または不慣れなサブシステムの広範な調査などがあります。
    • サブエージェントにはレビューのみを依頼します。根拠、影響対象パス、発生条件、推奨される検証、および Bucket I/Bucket II/現状維持の推奨を含む簡潔な指摘を求めます。
    • サブエージェントの出力は結論ではなく手掛かりとして扱います。指摘を記録したり修正を適用したりする前に、自分で根拠を確認します。
    • 自律的なレビュー/修正ループや並行編集、範囲を限定した確認の完了後もレビューを続けるために、サブエージェントを使用してはいけません。
  4. Bucket I のクリーンループを実行します。

    • Bucket I の修正は、範囲が狭く、局所的で、対象範囲内にあり、機械的に検証可能または自明で、プロダクト、設計、アーキテクチャ、ロールアウト、互換性、変更量、リスクに関する判断を必要としないものです。
    • ユーザーが review-only、do not edit、または同等の指示をしていない限り、現在の Bucket I の修正はすべて標準で適用します。
    • Bucket I の編集後は、新しい差分と影響を受けるコードパスを再確認します。新たな Bucket I の項目が見つかった場合は、それを修正して再確認します。
    • 有用である限り、Bucket I の項目がなくなるか、Bucket II の判断のみが残るか、検証/対象範囲/コンテキストの制約によって安全な続行が妨げられるか、次のパスが単なる変更の繰り返しになるまで続けます。
    • 意図的と思われるコードの削除は、未使用のインポートや壊れたドキュメントリンクのように、明らかに不要な成果物である場合を除き、適用してはいけません。
  5. 人間の判断が必要な境界を守ります。

    • より広範なリファクタリング、曖昧な修正、リスクの高い動作変更、設計上の選択は Bucket II に分類します。
    • ユーザーの明示的な承認なしに Bucket II を実装してはいけません。
    • 検証が外部要因で妨げられている、利用できない、または失敗している場合は、その旨を報告して停止します。より広範な静的変更で埋め合わせてはいけません。
  6. 検証します。

    • 実用的であれば、関連性の高い既存の検証を実行します。
    • 変更箇所に絞ったチェックを、変更のリスクが広範かつコストの高いテスト一式を正当化する場合を除き、優先します。
    • 無関係な既存の失敗と、レビュー修正によって生じた失敗を分けて説明します。

最終回答

以下を報告します。

  • Bucket I — 適用した安全な修正:問題、変更したファイル、検証の根拠。なければ none
  • Bucket II — 判断が必要:必要な判断と主なトレードオフ。なければ none
  • 現状維持 — 意味のある懸念を調査し、意図的に却下した場合は、その内容(必要に応じて)
  • 実行した検証と結果
  • 検証を省略または妨げられた場合の残存リスク

コメント