Menu
git logのhotspot分析・循環参照・デッドコード・不安定性メトリクスを組み合わせて リファクタリング優先候補を提案する。「hotspot」「リファクタリング提案して」 「どこを直すべき」「技術的負債を調べて」のように使う。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | x-hotspot-refactoring |
| description | git logのhotspot分析・循環参照・デッドコード・不安定性メトリクスを組み合わせて リファクタリング優先候補を提案する。「hotspot」「リファクタリング提案して」 「どこを直すべき」「技術的負債を調べて」のように使う。 |
| context | fork |
| allowed-tools | ["Bash","Read","Glob","Grep","AskUserQuestion","TaskCreate","TaskUpdate","TaskList"] |
git履歴・静的解析・依存関係分析を組み合わせ、リファクタリング投資対効果がもっとも高い箇所を特定して提案する。
フロー: スコープ確認 → 観点確認 → 分析実行 → クロスリファレンス → 優先度付き提案出力
フローを開始する前に、全ステップをTaskCreateで登録します。各ステップを開始するときTaskUpdateでin_progressへ、完了したときcompletedへ更新します。
| # | subject | blockedBy |
|---|---|---|
| 1 | Step 1: スコープを確認する | — |
| 2 | Step 2: リファクタリングの観点を確認する | 1 |
| 3 | Step 3: git履歴分析 | 2 |
| 4 | Step 4: 構造的問題を検出する | 2 |
| 5 | Step 5: コード品質を検出する | 2 |
| 6 | Step 6: クロスリファレンスして優先度付きで提案を出力する | 3, 4, 5 |
プロジェクトの構成を把握する。
# 言語・フレームワークの自動検出
ls package.json tsconfig.json pyproject.toml Cargo.toml go.mod 2>/dev/null
AskUserQuestionツールで対象範囲を質問する。
{
"question": "リファクタリング分析の対象範囲を選択してください",
"options": [
{ "label": "プロジェクト全体", "description": "すべてのソースコードを分析する" },
{ "label": "特定のディレクトリ", "description": "Otherから対象パスを入力（例: src/features/）" }
]
}
回答と自動検出の結果から以下の変数を決定する。
TARGET_DIR: 分析対象ディレクトリ（未指定の場合は .）IS_TS: TypeScript/JSプロジェクトか（Madge・Knip・type-coverageの使用可否）SINCE: git分析の期間（デフォルト: 12.month）AskUserQuestionツールの multiSelect: true で質問する。
{
"question": "どの観点で分析しますか？（複数選択可。気になることがあればOtherに自由記述も可）",
"multiSelect": true,
"options": [
{ "label": "ホットスポット", "description": "頻繁に変更される・複雑なファイルを特定する" },
{ "label": "構造・依存関係", "description": "循環参照・隠れた結合・アーキテクチャ違反" },
{ "label": "デッドコード削減", "description": "未使用ファイル・未使用エクスポート" },
{ "label": "お任せ", "description": "すべての観点で分析する" }
]
}
AskUserQuestionは最大4選択肢のため、IS_TSがtrueの場合は追加でもう1回質問する。
{
"question": "TypeScriptプロジェクト向けの追加分析も行いますか？（複数選択可）",
"multiSelect": true,
"options": [
{ "label": "型安全性", "description": "any型が残っている箇所を検出する" },
{ "label": "コード品質", "description": "アンチパターン・フレームワーク固有の問題" }
]
}
| キーワード例 | 対応する観点 |
|---|---|
| 重たい・遅い・パフォーマンス | ホットスポット |
| テストが書きにくい・テストできない | 構造・依存関係 |
| 特定ファイルに変更が集中・繰り返し直している | ホットスポット + temporal coupling |
| 不要・使われていない・ゴミが多い | デッドコード削減 |
| any・型・TypeScript | 型安全性 |
| 読みにくい・わかりにくい・命名 | コード品質 |
| 依存関係・import・循環・複雑 | 構造・依存関係 |
解釈した結果を「〇〇と〇〇の観点で分析します」と明示してからStep 3に進む。
観点に 1・6 が含まれる場合、または自由記述から関連すると判断した場合に実行する。
git log --format=format: --name-only --since=<SINCE> -- <TARGET_DIR> \
| grep -v '^\s*$' | sort | uniq -c | sort -nr | head -50 \
| while read count file; do
if [ -f "$file" ]; then
lines=$(wc -l < "$file")
score=$((count * lines))
echo "$score $count $lines $file"
fi
done | sort -nr | head -20
出力形式: スコア 変更回数 行数 ファイルパス
git log --numstat --format=format: --since=<SINCE> -- <TARGET_DIR> \
| grep -v '^\s*$' \
| awk '{add[$3]+=$1; del[$3]+=$2} END {
for(f in add) {
total=add[f]+del[f];
if(total>20 && del[f]>0)
printf "%.0f%% %d %d %d %s\n", del[f]/total*100, total, add[f], del[f], f
}
}' \
| sort -nr | head -20
出力形式: 削除率 総変更行数 追加行数 削除行数 ファイルパス
削除率50%超は「書いては消す」が繰り返されている設計の不安定シグナル。
git log --grep="fix\|bug" -i --format=format: --name-only --since=<SINCE> -- <TARGET_DIR> \
| grep -v '^\s*$' | sort | uniq -c | sort -nr | head -20
git log --format=format: --name-only --since=6.month -- <TARGET_DIR> \
| awk '
/^$/ { for(i in files) for(j in files) if(i<j) pairs[i" <-> "j]++; delete files; next }
/[^ ]/ { files[$0]=1 }
END { for(p in pairs) if(pairs[p]>2) print pairs[p], p }
' | sort -nr | head -20
出力形式: 共変更回数 ファイルA <-> ファイルB
常にペアで変更されるのに静的依存がないファイルは隠れた結合のシグナル。
結果を「ホットスポットランキング」として内部に保持する。
観点に 2・6 が含まれる場合は実行する。
# tsconfig.jsonが存在する場合
madge --circular --ts-config tsconfig.json <TARGET_DIR> 2>/dev/null
# tsconfig.jsonが存在しない場合
madge --circular <TARGET_DIR> 2>/dev/null
tsconfig.jsonの有無は Glob で確認してから実行する。
観点に 2・6 が含まれる場合は実行する。
madge --summary <TARGET_DIR> 2>/dev/null | sort -t: -k2 -nr | head -20
依存数が多いファイルは変更リスクが高く、分割検討対象。
観点に 3・6 が含まれる場合は実行する。IS_TSの場合はKnipを優先し、失敗した場合はMadgeで代替する。
# IS_TSの場合: Knip優先
knip --reporter compact 2>/dev/null
# Knipが失敗した場合、またはIS_TSでない場合: Madgeで孤立ファイルを検出
madge --orphans <TARGET_DIR> 2>/dev/null
Knipはプロジェクトに設定ファイル（knip.config.* または package.json の knip フィールド）がないと誤検知が多い。大量出力またはエラーの場合はMadgeに切り替える。
観点に 2・6 が含まれる場合は実行する。
depcruise --metrics -T metrics <TARGET_DIR> 2>/dev/null | head -40
不安定性指数（I = Ce/(Ca+Ce)）が高いのに多くから依存されているモジュールはもっともリスクが高い。
観点に 5・6 が含まれる場合は実行する。IS_TSに応じてルールセットを選択する。
# TypeScript/JSの場合
semgrep scan --config p/typescript --config p/react \
--severity=ERROR --severity=WARNING \
--no-rewrite-rule-ids \
<TARGET_DIR> 2>/dev/null
# その他の場合
semgrep scan --config auto \
--severity=ERROR --severity=WARNING \
<TARGET_DIR> 2>/dev/null
Semgrepはルールセット取得にネットワークアクセスが必要。失敗した場合はスキップしてその旨を記載する。
観点に 4・6 が含まれ、IS_TSがtrueの場合に実行する。
type-coverage --detail --strict \
--ignore-catch --ignore-nested --ignore-as-assertion \
--show-relative-path 2>/dev/null | head -50
収集したすべての分析結果を突き合わせ、以下の優先度で分類する。
| Priority | 条件 |
|---|---|
| P1: 最優先 | 複数のシグナルが重なるファイル（例: ホットスポット上位 かつ 循環参照あり） |
| P2: 高優先 | 単一のシグナルだが深刻（例: 循環参照があるが変更頻度は低い） |
| P3: Quick Win | 削除・整理だけで完結するもの（未使用ファイル・未使用エクスポート） |
## リファクタリング提案
### 分析サマリー
- 対象: <TARGET_DIR>
- 期間: 過去<SINCE>
- 観点: <指定された観点（自由記述の場合は解釈結果も記載）>
---
### P1: 最優先候補
**<ファイルパス>**
- シグナル: <検出されたシグナルを列挙（例: ホットスポットスコア 1240 / 循環参照あり / バグ修正5回）>
- 問題: <何が問題か、なぜ問題か>
- 提案: <具体的なリファクタリング手法（責務分割・インターフェース抽出・循環解消の方向性など）>
...
---
### P2: 高優先候補
...
---
### P3: Quick Win（削除・整理で即完結）
- `<ファイルパス>` — 未使用ファイル（knip検出）
- `<エクスポート名>` in `<ファイルパス>` — 未使用エクスポート
...
---
### 観点別の補足
<指定された観点ごとの追加所見・注意点>
---
### 免責事項
上記はコードの変更履歴と静的解析に基づく機械的な候補です。
ビジネスコンテキスト・チームの優先事項・リリース計画に照らして判断してください。
git log --oneline | wc -l でコミット数を確認してユーザーに伝える--config auto が失敗するためスキップする--orphans に切り替えるGitコミットを適切な粒度に分割し、有用なメッセージを付けて作成するスキル。「コミットして」「commitして」「変更をコミット」「まとめてコミット」など、コミット操作を依頼されたら必ず使う。
指定したスキルを3回繰り返し適用します。レビュー・計画・実装など、ファイルを変更するスキルに使います。「iterateで<スキル名>して」「<スキル名>を繰り返し適用して」のように使います。
既存テストをレビューして改善するスキル。「テストをレビューして」「テストを改善して」「テスト名を直して」のように頼まれたら使う。新規にテストを書くのではなく、`.claude/docs/test-implementation.md` のルール（テスト名・AAA構造・アサーション設計・テストダブル・非決定性制御・テスト間独立性・Testing Library 等のフロントエンド固有ルールまで全観点）に既存テストが沿っているかを見直す。対象は `.test.ts` / `.test.tsx` / `.spec.ts` ファイルと、テストコードブロックを含む `.md` ドキュメントファイル。
作った成果物について、ユーザーがその振る舞いと目的を確実に理解できているかを問いかけで確認します。細かな実装ではなく、何をするものか・目的にかなうかに焦点を当て、あらゆる可能性を踏まえてエージェントが判断して問いを立てます。「理解できているか確認して」「振る舞いを確認して」「目的にかなっているか見て」「作ったあとのすり合わせをして」と要望された際に必ず使用します。実装や変更が一段落したとき、作ったものの理解をすり合わせたいと感じたら積極的に提案してください。
`/compact`で要約する前に、残したい情報をユーザーに選んでもらい`/compact`の引数を組み立てます。 「compact前に整理したい」「コンテキストを圧縮したい」「/compactの引数を作って」 「会話が長くなってきたので整理したい」「重要な情報を引き継ぎたい」のように使います。
マージ済みのローカル・リモートブランチを整理するスキル。「ブランチ掃除」「マージ済みブランチを削除」「ブランチ整理」「gh poiを実行」「不要なブランチを片付けて」「リモートのブランチも消したい」「mainだけ残して」のような依頼で必ず使う。gh-poi拡張がインストール済みであることを前提とする。mainなどベースブランチは絶対に削除しない。