mcpField
M
modernize

modernize

github.com/t3dotgg開発2.2k277 回インストール今日更新
リポジトリ

modernize について

Modernizeは、プルリクエストが現在も製品に適合するかを再評価し、ブランチを更新するワークフローです。ベースブランチの変更とPRの当初の目的から、リベース、作り直し、クローズを判断します。

主な機能

  1. 01PRの目的と状態の確認
  2. 02ベースブランチの変更調査
  3. 03競合する実装の検索
  4. 04更新・再作業・クローズの選択
  5. 05range-diffによるリベース検証
  6. 06force-with-leaseでのプッシュ

活用シーン

  1. 01最近の変更に照らした古いPRの評価
  2. 02有用なPRの安全なリベース
  3. 03マージ済みの変更で不要になったPRの特定

インストール

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

$npx skills add https://github.com/t3dotgg/tstack --skill modernize

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

同梱ファイルagents/openai.yaml

詳細

モダナイズする

ブランチだけでなく、アイデアをモダナイズします。きれいにリベースできても、そのPRがまだプロダクトに必要である証明にはなりません。

ガードレール

  • 作業を始める前に、ブランチ、main ブランチ、および作業に関連するほかのブランチについて、origin の最新情報を取得済みであることを必ず確認してください。
  • 既存のワークツリーの変更はユーザーのものとして扱ってください。アクティブなワークツリーに未コミットの変更がある場合や、別の作業に使われている場合は、使い捨てのワークツリーを使用してください。
  • モダナイズの許可に含まれるのは、PR ブランチのリベースと更新です。マージ、クローズ、ベースブランチの変更、スコープの拡大は許可されていません。
  • ブランチ名を限定しない強制プッシュは絶対に使用しないでください。リベースしたブランチを更新する場合は、リベース前に確認した head SHA を基準に --force-with-lease を使用してください。
  • ユーザーから依頼されていない限り、PR にコメントを投稿しないでください。ユーザーに代わってコメントを投稿する場合は、すべてのコメントで leaving-pr-comments スキルを使用してください。

PR の意図を把握する

PR を特定し、その URL、状態、ベース、head のリポジトリとブランチ、現在の head SHA、作成者、チェック、レビュー状況を記録してください。タイトル、本文、関連する issue、コミット、レビューのスレッド、差分全体を確認してください。実装を評価する前に、PR が達成しようとしていた、筋の通った最小限の目標を明確にしてください。

最新のリモートのベースと PR head を取得してください。ローカルブランチが最新だと決めつけず、PR の実際のベースブランチ（通常は main）を使用してください。元の PR と、その後のベースブランチの変更を分けて比較できるように、マージベースを記録してください。

周辺で何が変わったか確認する

PR が分岐してからベースブランチに追加されたコミットと差分を調べてください。タイトル、コードパス、動作から代替案や競合する実装が示唆される場合は、マージ済みおよびオープン中の PR を検索してください。

重複する行だけに注目せず、次の点も確認してください。

  • 同じユーザー向けの問題はすでに解決されていますか？
  • API、型、スキーマ、依存関係、アーキテクチャ上の境界に変更がありましたか？
  • 今では双方が同じ動作や不変条件を担おうとしていませんか？
  • 変更対象のコードは削除、移動、または意図的に簡素化されましたか？
  • この PR を取り込むことで、古い動作が復活したり、同じことを行う方法が二つできたりしませんか？
  • 元のメリットは、保守コストに見合うほどまだ大きいですか？

Git が競合なしと報告しただけで、PR が現状に合っていると判断しないでください。

プッシュする前に処置を決める

次のいずれかを推奨してください。

  • MODERNIZE：目標は今も有用で、実装の形も適切です。リベースして競合を解決し、テストを実行してブランチを更新してください。
  • REWORK：目標は今も有用ですが、機械的なリベースでは不適切な実装がそのまま残ります。実現可能な最小限の書き直しを説明し、ユーザーからその書き直しも依頼されていない限り、プッシュ前に作業を止めてください。
  • CLOSE：PR は後続の変更によって不要になった、時代遅れになった、方向性が誤っている、またはコストに見合わなくなっています。具体的な根拠を示して作業を止めてください。時代遅れのブランチのリベースに時間をかけず、明示的な許可なくクローズしないでください。

CLOSE をためらわず推奨してください。古いことだけでは根拠にならず、これまでに費やした労力も PR を存続させる理由にはなりません。

意図を損なわずにリベースする

MODERNIZE と判断した場合は、次の手順を実施してください。

  1. 記録した PR head を起点に、安全なローカルブランチまたは使い捨てのワークツリーを作成します。
  2. 新たに取得したベースブランチに、そのコミットをリベースします。
  3. PR の現在の意図と、ベースブランチで新たに導入された不変条件に従って、それぞれの競合を解決します。競合によってプロダクトやアーキテクチャ上の意見の相違が明らかになった場合は、推測で解決せず、作業を止めて処置を再検討してください。
  4. git range-diff でリベース前後のコミット系列を比較し、最終的な差分を確認します。意図した動作が失われておらず、すでに取り込まれた動作が再導入されていないことを確認してください。
  5. 変更対象の領域について、リポジトリで定められた対象を絞ったチェックを実行します。実際の失敗と、既存の問題またはインフラストラクチャに起因する失敗を区別してください。
  6. 事前に確認したリモートの head を基準に --force-with-lease を使ってプッシュします。リースが失敗した場合は、新しい作業を上書きせず、取得して状況を再評価してください。

PR をマージしないでください。

レポート

最初に MODERNIZE、REWORK、または CLOSE とその理由を示します。その後、次の内容を要約します。

  • ベースブランチに加えられた重要な変更；
  • 概念上の競合、または競合が見つからなかったことの確認；
  • リベースとプッシュの結果（実施した場合）；
  • 実行したチェックとその結果；
  • PR へのリンクを添えた、残っている判断事項または作業。

確認できた事実と判断を分けます。確信を捏造するのではなく、確認できなかったことを伝えます。

コメント

Markdown 対応