コードスリムリファクタ

コードスリムリファクタ は何をしますか？

トリガー境界

このスキルは、ユーザーが明示的に構造的な単純化または収束リファクタリングを希望する場合にのみ使用してください。

以下の場合はトリガーしないでください:

• 小規模なクリーンアップ
• 日常的なバグ修正
• 一度きりの名前変更
• 専用の収束ワークフローを必要としない通常のリファクタリング

モード

1回の実行につき1つのモードを選択してください:

• quick: 小規模または明確に区切られた領域に対する軽量な収束パス
• strict: 完全なトレーサビリティとマージゲートを備えた正式なリファクタリングパス

ユーザーが正式で監査可能なリリースに関わるリファクタリングを求めない限り、デフォルトで quick を使用してください。

必須入力

• repo_path: Gitリポジトリへの絶対パス
• refactor_goal: 1行の収束目標
• scope: オプションのパスまたはモジュールスコープ
• mode: quick または strict
• target_branch: strict の場合のみ必須、デフォルトは master

中核ルール

このワークフローはデフォルトで古い外部互換性を維持しませんが、スコープ内のシステムにおける意図された現在のコントラクトを維持しなければなりません。

テストを通すためだけにバックエンドコントラクト、レスポンスセマンティクス、またはアサーション基準を決して変更しないでください。

Quickモード

タスクが限定されており、ユーザーが主に収束を求めていて、正式な成果物トレイルを必要としない場合に quick を使用してください。

必要な手順:

1. 目標、スコープ、除去すべき主な複雑性を述べる。
2. 会話内または必要に応じて最小限のローカルノートとして短いアクションリストを保持する。
3. そのアクションリストに関連するスコープ内の変更のみを適用する。
4. バックエンドコントラクト、レスポンスセマンティクス、アサーション基準を維持する。
5. 変更された領域に対して集中した検証を実行する。
6. 検証がバックエンド/テストの不一致を示唆する場合は、さらなる編集の前に停止し、コントラクト不一致ゲートを実行する。
7. 除去された複雑性、保持されたもの、残存リスクを報告する。

./slim_refactor/ の成果物は quick モードではオプションです。

Strictモード

リファクタリングがトレーサブル、監査可能、またはマージゲート制御を必要とする場合に strict を使用してください。

必須ゲート:

1. 専用の作業ブランチを作成して使用する。ターゲットブランチ上で直接編集しないでください。
2. コード編集の前に設計を書く。
3. ./slim_refactor/ の下で成果物を追跡する:
   • todolist.md
   • plan.md
   • report.md
4. バックエンドコントラクト、レスポンスセマンティクス、アサーション基準を維持する。
5. すべての変更ラウンドでレビューを実行する。
6. 検証がバックエンド/テストの不一致を示唆する場合は、コントラクト不一致ゲートを実行する。
7. マージ前に完全なワークフローゲートを実行する。

コントラクト不一致ゲート

テストが実際のリグレッションではなくコントラクトの不一致を反映する可能性がある方法で失敗した場合は、このゲートを使用してください。

必要なアクション:

1. 分類が完了するまで実装変更を停止する。
2. 現在の動作、意図された現在のコントラクト、テストの期待値を比較する。
3. サブエージェントが利用可能な場合は、独立したサブエージェントレビューを起動する。
4. サブエージェントが利用できない場合は、明示的なローカルレビューフォールバックを実行し、そのフォールバックをラウンド出力に記録する。
5. 不一致を以下のいずれかに正確に分類する:
   • backend_regression: バックエンドの動作が意図された現在のコントラクトに対して間違っている。
   • stale_tests: テストが意図された現在のコントラクトに追いついていない。

分類後の許可されるアクション:

• backend_regression: バックエンドの動作を意図された現在のコントラクトに修正する。問題を隠すためにテストを弱めてはいけない。
• stale_tests: 影響を受けるテストのみを更新するか、このラウンドではそれらのテストをスキップする。バックエンドコントラクトやアサーション基準を緩めてはいけない。

テストがスキップされた場合は、ラウンド終了前に、陳腐化ゲートの状態、スキップされたスコープ、および必要なフォローアップを報告する。

実行ワークフロー

Quick

1. 目標、スコープ、検証ターゲットを確認する。
2. 最小の一貫した変更セットで非本質的な複雑性を除去する。
3. 新しい抽象化よりも削除と収束を優先する。
4. 構造を変更しながら意図された現在のバックエンドコントラクトを維持する。
5. 影響を受けるスコープを検証する。
6. 検証がコントラクト/テストの不一致を示唆する場合は、さらなる編集の前にコントラクト不一致ゲートを実行する。
7. 収束結果と残存リスクを要約する。

Strict

1. target_branch をチェックアウトして同期する。
2. BASE_SHA を記録する。
3. ブランチ codex/refactor/<topic>-<YYYYMMDD> を作成する。
4. ./slim_refactor/todolist.md を作成または更新する。
5. ./slim_refactor/plan.md を作成または更新する。
6. 計画で宣言されたアクションのみを実装する。
7. 構造を収束させながら意図された現在のバックエンドコントラクトを維持する。
8. 各変更ラウンドでレビューを実行し、結果を ./slim_refactor/report.md に記録する。
9. 検証がコントラクト/テストの不一致を示唆する場合は、コントラクト不一致ゲートを実行し、レビューアタイプと分類を記録する。
10. 完全なワークフローゲートを実行する。
11. トレーサビリティとマージまたはブロックの決定を付けて report.md を確定する。

出力要件

常に以下を報告する:

• 除去された複雑性
• 収束された構造
• 検証結果
• 残存リスク
• 維持または修正されたコントラクト不変条件
• 該当する場合は不一致の分類
• 不一致レビューが発生した場合のレビューアタイプ（subagent または local_fallback）
• 陳腐化テストが見つかった場合に変更またはスキップされたテスト

strict の場合は、以下も報告する:

• ブランチ名
• 成果物パス
• レビュー結果
• マージまたはブロックの決定

参照

• references/workflow-checklist.md
• references/design-spec-template.md
• references/todolist-template.md
• references/plan-template.md
• references/report-template.md