code-deduplication

code-deduplicationスキルの概要

code-deduplication スキルは、すでにある関数、モジュール、パターンで同じ仕事ができるなら、新しいコードを増やさないよう Claude を導きます。特に、「ちょっとしたヘルパー」や共有ユーティリティ、リファクタリング用の修正パッチが増え続け、気づくと重複した振る舞いになっているチームに向いています。Refactoring のための code-deduplication を目指すなら、このスキルはまず既存実装を確認し、それを拡張・再利用して、ゼロから作り直さないよう促します。

このスキルが実際にやること

このスキルの中心は、通常 CODE_INDEX.md という機能インデックスです。モデルは新しいコードを書く前に、コードベースがすでに何をできるのかをそこから推論します。結果として、重複しがちなヘルパーを減らし、共有抽象化をすっきりさせ、同じ問題を少しずつ違う形で解くファイル間のズレを抑えるのに役立ちます。

最適な用途

ユーティリティ関数を追加するとき、ビジネスロジックを統合するとき、リポジトリ全体に散らばった繰り返し実装を整理するときに、code-deduplication スキルを使ってください。特に、複数ファイルにまたがるリファクタリングで、重複より拡張を優先させたい場面に向いています。

何が違うのか

一般的な「これをリファクタして」というプロンプトと違い、このスキルは「書く前に確認する」姿勢と、変更後の保守ループを追加します。単にコード量を減らすだけではなく、既存機能を守り、その対応関係を明確にし、新しいコードに存在理由を持たせることが目的です。

code-deduplicationスキルの使い方

ワークフローに組み込み、適用してから使う

スキルマネージャーから code-deduplication install の手順で導入し、新しい共有コードやリファクタリング作業を依頼する前に適用してください。リポジトリの frontmatter では user-invocable ではないとされているため、これは単独で直接実行するコマンドではなく、Claude の計画と記述を支えるバックグラウンドのワークフロースキルとして扱うのが適切です。

まず適切なプロジェクト文脈を与える

プロンプトの前に、現在の機能目標、関連ファイル、そしてあれば既存のインデックスを渡してください。このスキルは、意図する振る舞いと既存実装を比較できるときに最もよく働きます。単に「もっときれいにして」のような曖昧な依頼だと、重複の有無を信頼できる形で判定するための情報が足りません。

うまく機能するプロンプトの形

強い code-deduplication usage プロンプトでは、欲しい機能、対象ファイル、重複のリスクを明示します。例えば次のように書けます。「支払いサマリーの流れをリファクタしてください。まず CODE_INDEX.md に、フォーマット、丸め、税計算がすでに載っているか確認してください。一致する既存ヘルパーがあれば再利用し、機能が存在しない場合だけ新しい関数を追加してください。」これなら、単なる作業指示ではなく、判断基準まで渡せます。

まず読むべきファイル

最初に SKILL.md を読み、次にプロジェクト全体の CODE_INDEX.md や同等のアーキテクチャノートを確認してください。リポジトリにユーティリティマップ、依存関係ガイド、リファクタリング方針があるなら、コードを直す前にそれも読むべきです。このスキルの価値は、実装後ではなく、早い段階で再利用の機会を見つけることにあります。

code-deduplicationスキル FAQ

これは大規模コードベース専用ですか？

いいえ。小規模なリポジトリでも有効です。特に、初期の重複が後からほどきにくくなる場合に効きます。このスキルが最も役立つのは、「とりあえずのヘルパー」が、ほぼ同じ目的のヘルパーをさらに3つ生んでしまうようなケースです。

普通のリファクタプロンプトと何が違いますか？

通常のプロンプトは、スタイルを改善しても重複の発生を防げないことがあります。code-deduplication スキルは構造的な確認を追加します。既存機能を特定し、意図を比較し、まず再利用または拡張し、書き終えたらインデックスを更新します。そのため、一般的な書き換え依頼よりも、Refactoring のための code-deduplication に向いています。

初心者にも必要ですか？

既存コードが見つけにくいために、つい新しいコードを書いてしまう人には必要です。このスキルは、検索して判断するステップを強制することで、意図しない重複を減らせます。逆に、リポジトリに明確な構造がない、または機能インデックスを維持する文化がない場合は、効果が薄くなります。

使わないほうがいいのはいつですか？

単発の実験、一時的なスパイク、実際の重なりが見込めない新機能では、頼りすぎないでください。そうした場合は、書く前に確認する流れが、結果を良くするどころか単に遅くするだけです。

code-deduplicationスキルを改善するには

モデルには機能レベルの目標を伝える

最も効果的な改善は、欲しいファイルの形ではなく、やるべき仕事を説明することです。「ヘルパーを追加して」ではなく「レポート全体の日時パースを標準化して」と伝えてください。そうすると、code-deduplication スキルは目的ベースで比較できるようになり、再利用できるかどうかを判断しやすくなります。

既存の重なりを早めに見せる

見た目がかなり似ている関数、近くにあるモジュール、繰り返しの分岐があれば、具体例として示してください。すでに2つの実装が近いと分かっているなら、その両方を名前で挙げて、どちらか一方を単一の所有者にするよう依頼してください。これで、最初のパスで新しい重複がうっかり作られるリスクを下げられます。

再利用の判断を明示的に求める

強い code-deduplication guide の依頼では、次の3点を求めるとよいです。再利用できる既存コード、拡張すべき箇所、本当に新規コードが必要な箇所です。こうすると、出力が単なる生成物ではなく、判断に基づいた提案になります。

1回目の後にインデックスを更新して回す

モデルがコードを書いたあと、次の変更に備えて機能インデックスを更新または下書きするよう依頼してください。このスキルの主な失敗は、実装が悪いことではなく、リファクタ後に再利用のシグナルが失われることです。インデックスを最新に保つことが、code-deduplication を持続的に機能させる鍵です。