re0-style

名前を指定した変更またはファイル群を修正し、スタイル以外は変更せず、リポジトリですでに採用されている規約に合わせます。

目標

あるセッションで書かれたコードは、周囲のコードからずれていきます。引用符のスタイルが異なったり、命名の大文字・小文字の使い方が違ったり、インポートの順序が異なったり、直前のプロジェクトで使われていた方法でエラーを発生させたりします。すると、読者はそれぞれの違いに意味があるのかを判断しなければなりません。re0-style は、対象範囲のコードが周囲のコードになじむようにします。規約はすべてリポジトリ自体から取り入れます。まずプロジェクトで設定されているフォーマッターとリンターを参照し、それらが判断しない部分については、近隣のファイルに見られるパターンを参照します。そして、動作を変えずにその場で修正を適用します。リポジトリ内で規約が分かれている場合は、どちらかを選ばずに確認を求めます。結果として得られるのは、スタイルだけを変更した差分と、ファイルおよびルールごとの変更内容を示すレポートです。

ワークフロー

1. スコープを明確にします。 変更内容（作業中の差分、またはユーザーが指定したベースとの差分）か、ユーザーが指定したファイル一覧を明記します。変更の場合、対象は変更された行です。変更が触れていないファイルはスコープ外であり、変更が触れたファイルでも、変更されていない行はスコープ外です。今すぐ、プロジェクトのマニフェスト、タスクランナー、または CI ワークフローで指定されたコマンドを使って、プロジェクトのテストを一度実行し、結果を記録します。これにより、すでに存在していた失敗を今回の作業のせいにしないようにします。
2. リポジトリ独自のものではない対象を除外します。 このスキルのフォルダーから、スコープ内のファイルに対して node scripts/scope.mjs <files...> [--json] を実行します。このコマンドはファイルごとに、linguist-generated と linguist-vendored 属性、先頭行にある生成ファイルのヘッダー、行番号付きのフォーマッターとリンターの無効化マーカー、ファイルのフォルダーからリポジトリルートまで適用されるスタイル設定ファイルを一覧表示します。終了コード 0 は該当するファイルがないこと、3 は 1 つ以上該当すること、2 は使用法の誤りまたは入力の読み取り不可を示します。該当箇所は判断材料であり、確定事項ではありません。実際に生成されたファイルやベンダー提供のファイルは対象から除外し、無効化マーカーの下にある領域はすべてそのままにします。
3. ツールの判断内容を確認します。 手順 2 で挙げられた設定ファイルと、プロジェクトのマニフェスト、スクリプト、ロックファイル、CI ワークフロー、pre-commit 設定から、リポジトリで実行されるフォーマッターとリンター、および設定されているオプションを特定します。それぞれをプロジェクト独自の解決方法（npm exec、bun run、./node_modules/.bin/、uv run、poetry run、固定されたツールチェーン）で解決し、実行予定のバージョンを同じ方法で --version を使って表示して、ロックファイルまたはマニフェストに記載されたバージョンと比較します。不一致がある場合、またはグローバルバイナリか一時インストールでしかツールにアクセスできない場合、そのツールの修正は中止し、その内容を報告に記載します。
4. ツールでは判断できない内容を確認します。 スコープで生じた疑問のうち、設定済みのツールでは判断できないもの（種類ごとの識別子の大文字・小文字、インポートのグループ分けと順序、ファイルとフォルダーの構成、エクスポート形式、エラーの発生方法と文言）について、近い順に周辺ファイルを確認します。同じフォルダー、次にリポジトリ内の別の場所にある同じ種類のファイルを調べ、それぞれのパターンを数えます。ほぼすべてのサンプルが従っていて、例外が散在する単独ファイル（多くは最近のもの）と見なせる場合、そのパターンを慣例とします。別のパターンがフォルダーまたはモジュール全体に定着している場合、あるいはドリフトと見なせない形で複数のファイルに繰り返し現れる場合、リポジトリにはその場所に 2 つの慣例があるため、両方の数と各パターンが使われている場所を記録します。判断できない場合は 2 つの慣例として扱い、質問します。フォルダー内で一貫して使われている慣例は、リポジトリの他の場所で使われている慣例より優先します。
5. ツールによる修正を適用します。 スコープ内のファイルだけを対象に、フォーマッターを実行してから、リンターの修正モードを実行します。ツールが安全と判断した修正だけを適用します。変更の場合、まず各ファイルのベース版を（git show <base>:<path> で一時コピーに読み込み）使って、フォーマッターのチェックを実行します。ベース版がすでに整形済みなら、ファイル全体を整形しても変更箇所だけに影響します。そうでなければ、変更行の範囲内にある編集だけを残します（ツールの範囲指定オプションを使うか、変更行と重なるハンクだけを残します）。以前からのドリフトはそのままにしたと報告します。ユーザーから、リポジトリにないフォーマッターまたはリンターの導入を求められた場合は、そのエコシステムとマニフェストがすでに示しているものを設定し、各オプションを手順 4 で確認したコードの状態に合わせ、スコープ内だけで実行します。スコープ外にも変更が及ぶ場合は、適用せずに報告します。
6. 手作業による修正を適用します。 残りの lint 指摘と、スコープ内にある手順 4 の慣例からの逸脱を、動作を維持しながら修正します。ローカルまたはプライベートの識別子を変更する場合は、すべての参照も併せて変更します。公開 API（別のモジュールまたはパッケージからインポートされるエクスポート、CLI フラグ、設定キー、ルート、シリアライズされたフィールド）をまたぐ名前の変更は、影響を受ける呼び出し元をすべて添えて報告に提案し、ユーザーが確認した場合にのみ適用します。ロジックの変更でしか解消できない lint 指摘は修正せず、報告します。
7. 慣例の分岐を明らかにします。 手順 4 で 2 つの慣例が確認された箇所は、コードを変更せず、その 2 つのパターン、それぞれの件数、使われている場所、および回答待ちのスコープ内の行を報告に記載して質問します。その場で作業を止める必要はありません。後続の作業で回答を適用します。
8. 以下のとおり検証し、報告します。

ルール

• すべての規約はリポジトリに由来します。リポジトリが保持する設定（その設定が明示的に拡張する公開スタイルガイドを含む）か、リポジトリ内のファイルが一貫して従っているパターンに限ります。外部のスタイルガイド、言語で一般的なデフォルト、リポジトリが採用していない好みは使いません。
• ユーザーが指定した範囲、または実行したパイプラインが対象とする範囲内にとどまります。変更対象外のファイルや行のスタイルは変更せず、範囲を広げません。範囲外で見つかった逸脱は修正せず、報告します。
• すべてのツールは、プロジェクト独自の解決方法で実行し、そのバージョンを表示して比較します。グローバルのバイナリや一時インストールは別のツールチェーンであり、その判定はプロジェクトの判定とは異なります。
• スタイルだけを変更します。値、条件、呼び出し、制御フロー、公開名は変更しません。読み込み時にコードを実行するインポート（ポリフィル、登録処理、スタイルシート）の順序は、移動すると動作が変わるため、そのままにします。
• 競合する2つの規約から黙って一方を選ぶことはしません。どちらのパターンが何件あるかを示した質問として、ユーザーに確認します。
• リポジトリが保護するものを尊重します。生成ファイル、ベンダー提供ファイル、フォーマッターまたはリンターのオフマーカー配下にあるすべての領域は変更しません。
• 他の処理が担当する内容は引き継ぎます。文章やコメントの句読点（em ダッシュと en ダッシュは dedash、韓国語の中黒は dedot）と、文章の冗長さや内容のないコード（デッドコード、コードを言い換えるだけのコメント）は debloat に引き継ぎます。実施せず、報告で各引き継ぎ先を明記します。
• 規約に反する箇所が見つからない場合、そのパスでは何も変更しません。
• 安全に編集します。変更前に対象が存在することを確認し、存在しない場合は黙って何もしないのではなく MISS と報告します。ファイルは UTF-8 として読み書きし、改行コードは変更しません。置換は一括走査ではなく、該当箇所ごとに行います。機械的な変更が大規模な場合はスクリプトを使います。

検証

完了前に、次の点を確認します。

1. プロジェクト独自の解決方法で実行したフォーマッターとリンターが、変更したファイルに問題がないと報告すること。または、残っている指摘すべてについて、残した理由を明記すること。
2. プロジェクトのテスト結果が、手順1の実行結果と同じであること。
3. 差分のすべてのファイルが対象範囲内にあり、すべてのハンクが報告した変更に対応していること。スタイルのみというルールに照らして、各差分ハンクを確認します。
4. 規約の分岐がある場合は、それぞれのパターンの件数を示すこと。また、公開名の変更は、ユーザーの確認がない限り適用せず、提案にとどめること。

変更内容は、ファイルごと、ルールごとに報告してください（ツールのルール ID、または規約と、それに該当するパターンの件数を記載）。続けて、未対応の内容を報告します。具体的には、件数付きの質問として提示する規約の分岐、ロジックの変更でしか解決できない指摘、提案した公開名の変更、対象範囲外の逸脱、ツールのバージョン不一致、および各引き継ぎ先です。