code-simplify

このスキルはコードを編集します。以下のルールは必ず守ってください。 1. 変更を加える前に、対象コード、近くの呼び出し元、関連するテストを読みます。 2. 実行可能な場合は、編集前に有用な範囲を絞ったベースラインチェックを実施します。 3. 挙動、副作用、エラー処理を維持します。 4. スコープが曖昧な場合、単純化にリスクがある場合、または現実的な選択肢が複数ある場合に限り、ユーザーに確認します。 5. 呼び出しの本体は単純化のループに集中させ、詳細なパターンは必要に応じてリファレンスから読み込みます。

コードの単純化

入力

• $request：ファイルパス、シンボル名、flatten nested conditionals のようなメモなど、任意のスコープまたは単純化の指針です。

目標

対象コードの動作を変えずに、読みやすさを重視した最小限かつ安全な変更を加え、理解と保守を容易にします。

ステップ 0：スコープと適切性を確認する

次の点を特定します。

• 単純化するファイル、シンボル、または差分の正確なスコープ
• ユーザーが限定的な整理を求めているか、より広範な見直しを求めているか
• 対象がアプリケーションコード、テスト、生成コード、またはパフォーマンスが重要な処理か

次の場合は作業を中止するか、確認します。

• 安全に作業するうえで、リクエストが曖昧すぎて対象を特定できない
• コードが生成されたものである
• 「単純化」の依頼が、実際には再設計に当たる
• 変更によって公開動作や契約が明らかに変わる

曖昧さのため安全に作業を進められない場合、または単純化の正当な方向性が複数ある場合に限り、AskUserQuestion を使用します。

成功基準：単純化のスコープが明確で、局所的な整理のワークフローに適しています。

ステップ 1：動作を理解し、ベースラインを確立する

編集前に、実際のコードを読みます。

• 対象のファイル
• 近くの呼び出し元、エクスポート、隣接するヘルパー
• 対象の動作をカバーする既存のテスト

次に、以下を特定します。

• 入力と出力
• 副作用と永続化の境界
• エラー処理とガード節
• 変更してはならない、外部から見える契約

検証のベースライン：

• 実行可能な場合は、関連するテスト、型チェック、対象を絞ったリント、またはビルド手順のうち、最も範囲の狭いものを実行します。
• 対象を絞った検証手段がない場合は、その旨を明示し、より慎重に作業を進めます。

ランタイム固有のルール：

• 毎回 CLAUDE.md を機械的に読み直す必要はありません。
• Claude Code は getUserContext を通じて、CLAUDE.md の階層構造をすでに会話コンテキストに挿入しています。
• 対象領域に固有の規約がある場合や、周辺コードが曖昧な場合に限り、追加のローカルドキュメントを読みます。

成功基準：編集を始める前に、現在の動作と検証のベースラインが明確になっています。

ステップ 2：単純化の候補を特定する

再設計に踏み込まず、局所的な複雑さを減らせる変更を探します。

• ガード節や早期リターンを使って深いネストを解消する
• 読みにくい式を、名前付きの変数やヘルパーに切り出す
• 誤解を招くローカルシンボルや暗号的なローカルシンボルの名前を変更する
• デッドコードや未使用の分岐を削除する
• 明らかな重複をまとめる
• ブール論理や条件分岐を単純化する
• 呼び出し箇所が分かりやすいまま、パラメーターの煩雑さを減らす

候補ごとに、次の項目を記録します。

• 場所
• カテゴリー
• リスク：low、medium、または high
• 必要な検証

詳しいパターン一覧、アンチパターン、リスクに関する指針については、references/simplification-patterns.md を読み込みます。

成功基準：具体的な候補があり、リスクと期待される効果の順に整理されています。

Step 3: 最小限で安全な変更セットを選択する

デフォルトの動作：

• リスクが低く、明らかに有益な簡素化は、そのまま適用します
• 関連する編集は、ファイル単位または密接に関連する呼び出し箇所ごとにまとめます
• 広範な「すべてをクリーンアップする」作業よりも、小規模で整理された一度の変更を優先します

次の場合は、作業を進める前にユーザーに確認します：

• 最適な簡素化の方法が明確でない場合
• 変更のリスクが中程度以上の場合
• 関連のないクリーンアップ候補が複数あり、範囲を選ぶ必要がある場合
• 名前変更や抽出が広範なパブリックインターフェースに及ぶ場合

些細で明らかに安全なクリーンアップに、形式的な変更前後の承認手順を求めないでください。

成功基準：意図した編集が限定的で、正当化でき、ユーザーの依頼に見合ったものになっています。

Step 4: 簡素化を適用する

最も安全な順序で変更します：

1. デッドコードの削除と、単純なブール式の整理
2. ネストの解消とローカルな抽出
3. 重複の集約
4. より広範な名前変更や小規模なヘルパーの抽出

編集時のルール：

• ユーザーがより広範なクリーンアップを明示的に希望していない限り、関数シグネチャを維持します
• エラー処理と、外部から観測可能な副作用を維持します
• 共有シンボルの名前を変更する前に、参照箇所を検索します
• ヘルパーファイルの作成が必要な場合は、関連ファイルの近くに配置し、対象を限定します
• クリーンアップがアーキテクチャ作業に波及し始めたら、中止します

成功基準：依頼された簡素化が、意図しない範囲の拡大を伴わずに実装されています。

Step 5: 動作が維持されていることを確認する

Step 1で実施した、関連性の最も高いチェックを再実行します：

• まず対象を絞ったテストを実行します
• 必要に応じて、型チェックまたはコンパイルを実施します
• 変更箇所に応じて必要な場合のみ、より広範なチェックを実施します

そのうえで、次を確認します：

• ベースラインのチェックが引き続き通ること
• 新たな型エラーや構文エラーが発生していないこと
• コードが単に短くなっただけではなく、実際にわかりやすくなっていること

簡素化によってリグレッションや曖昧な影響が生じた場合：

• 最後に加えたリスクの高い変更を元に戻します
• 安全な改善は維持します
• 無理に適用せず、見送った候補として報告します

成功基準：動作を変更することなく、ベースラインと同等以上の検証結果が得られています。

ガードレール

• 無関係な作業に、このスキルを先回りして使用しないでください。
• 簡素化の名目で、機能、コメント、アーキテクチャのリファクタリングを追加しないでください。
• 生成コードを簡素化しないでください。
• ユーザーがテストのクリーンアップを明示的に依頼していない限り、テストを簡素化しないでください。
• 行数の削減ではなく、認知負荷の軽減を優先してください。
• disable-model-invocation を追加しないでください。ユーザーが簡素化を明示的に依頼した場合に、モデルがこのスキルを呼び出せる必要があります。
• context: fork を追加しないでください。このワークフローは現在の作業コンテキストを編集するため、インラインで実行するのが適しています。
• paths: を追加しないでください。これは汎用的なワークフロースキルであり、パスで有効化されるドメインリファレンスではありません。
• パターンのカタログ全体を SKILL.md にインラインで記載しないでください。

リファレンスを読み込むタイミング

• references/simplification-patterns.md 対象コードが単純でない場合に、詳細なパターン例、リスクに関するガイダンス、アンチパターン、エスカレーションの判断基準を確認するために使用します。

出力要件

次を報告します：

1. 確定した作業範囲
2. 実施したベースラインチェック、または明示的な検証上の不足
3. ファイル別・カテゴリ別に適用した簡素化
4. 検証結果
5. 見送った、または保留した候補とその理由