Code Polish

統合的な簡潔化とレビューパイプライン。このスキルは 2 つのサブスキルを順序立てて実行します:

1. code-simplify — 可読性と保守性を高めるために簡潔化
2. code-review --fix — 正確性、セキュリティ、品質をレビューし、すべての修正を自動適用

スコープ解決は 1 回のみ、ユーザー向けレポートは 1 つ、簡潔化検証の重複なしを最適化します。

スコープ解決

1. リポジトリコンテキストを検証: git rev-parse --git-dir。失敗した場合は停止し、ユーザーに git リポジトリから実行するよう指示します。
2. ユーザーがファイルパス/パターン、コミット/範囲、または Resolved scope フェンスブロック (1 行に 1 つのリポジトリ相対パス) を提供した場合、スコープはそれらのターゲットに限定されます。
3. それ以外の場合、スコープはセッション内で変更されたファイルのみです。その他のコミット未実施の変更は含めません。
4. セッション内で変更されたファイルがない場合、すべてのコミット未実施追跡ファイルと未追跡ファイルにフォールバックします:
   • 追跡: git diff --name-only --diff-filter=ACMR
   • 未追跡: git ls-files --others --exclude-standard
   • 両方のリストを統合して重複を排除します。
5. 明示的に要求されない限り、生成されたファイル/低信号ファイルを除外: ロックファイル、ミニ化されたバンドル、ビルド出力、ベンダーコード。
6. スコープがまだ 0 ファイルに解決される場合、報告して停止します。
7. 最終スコープを Resolved scope フェンスブロック (1 行に 1 つのリポジトリ相対パス) に正規化します。スコープの再発見を求めるのではなく、両方のサブスキルで正確なブロックを再利用します。

ワークフロー

1) スコープを 1 回だけ解決

• 上記の「スコープ解決」ルールを適用します。
• 結果の Resolved scope ブロックをすべての後続処理の信頼できるソースとして扱います。
• ユーザーの意図、制約、リスク設定を転送しますが、解決済みブロックで既にキャプチャされた生のスコープセレクタはスキップします。

2) code-simplify を実行

code-simplify スキルを以下と共に呼び出します:

• 信頼できる Resolved scope ブロック
• --no-verify
• --no-report
• スコープ以外でまだ関連するユーザーの意図

code-simplify にスコープを広げたり再発見したりしないよう指示します。

3) code-review --fix を実行

code-review スキルを以下と共に呼び出します:

• 同じ信頼できる Resolved scope ブロック
• --fix
• スコープ以外でまだ関連するユーザーの意図

ユーザーが保守性カバレッジより速度優先のパスを明示的に要求した場合、--skip-profile naming を追加することもできます。デフォルトでは naming プロファイルをスキップしないでください。

4) 最終検証

• code-review の修正後検証を最終検証サマリーとして扱います。その検証がすでに最終的にタッチされたスコープをカバーしている場合。
• 検証がスキップされたか、部分的であるか、または最終的な差分と一致しなくなった場合、最終的にタッチされたスコープ全体で 1 つ の限定的な最終検証パスを実行します。
• スキップされたチェックを常に明示的に報告します。

5) レポート

最終状態を 1 つのサマリーに統合します:

1. スコープ: タッチされたファイルと関数。
2. 簡潔化: code-simplify からの主要な変更。--no-report が使用されたため、必要に応じて実際の差分から派生します。
3. レビュー結果と修正: code-review からの結果と適用された修正。
4. 検証: 実行されたコマンドと結果。
5. 残存リスク: 手動レビューが必要な仮定または項目。