desloppify について
Desloppify は、コード品質の改善やリポジトリレビューを進めるためのスキルです。CLI がスキャンして結果を報告し、エージェントが問題を分類して修正を判断します。段階的な包括レビューも選択できます。
主な機能
- 01適切な分析パックでリポジトリをスキャン
- 02結果を確認して対応の優先度を決定
- 03安全な修正を適用して再スキャン
- 04任意の段階的な包括レビュー
- 05フックとスキャン範囲の設定
活用シーン
- 01未使用コードや弱い型を見つける
- 02複雑さやアンチパターンを整理する
- 03段階的なリポジトリ監査を計画する
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ fasalzein/ desloppify --skill desloppifyインストール後、Claude Code で/desloppifyを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
reference/commands.mdconfig-and-plugins.mdoverhaul-review.mdpacks-and-tools.md詳細
Desloppify
はい。このファイルは簡潔に保ってください。
この SKILL.md は実務上のエントリーポイントです。ここにはワークフローと判断ポイントだけを記載してください。詳細なコマンド/設定/リファレンス情報は補足ドキュメントに記載し、必要なときだけ読み込んでください。
reference/commands.mdreference/packs-and-tools.mdreference/config-and-plugins.mdreference/overhaul-review.md
このスキルの用途
ユーザーが次のことを希望するときに使用します。
- リポジトリの不要なコードを整理する
- AI 生成コードの不要な部分を整理する
- コード品質を確認する
- デッドコード/弱い型付け/複雑さ/アンチパターンをスキャンする
- 構造化された抜本的なレビューや段階的なクリーンアップ監査を実施する
CLI が検出し、エージェントが優先順位を付け、修正するものを判断します。
デフォルトの動作は引き続きスキャン → 優先順位付け → 修正です。ユーザーがより広範な監査や段階的なクリーンアップ計画を明確に希望する場合に限り、抜本的なレビューのモードに切り替えてください。
デフォルトのワークフロー
任意の抜本的なレビューのモード
ユーザーがすぐにクリーンアップを実施するのではなく、より広範な監査を希望する場合は、reference/overhaul-review.md を読み込み、まずモードを選択してください。
- Surgical — テーマを1つに絞る
- Systematic — セクションごとにレビューし、各セクションで一時停止する
- Full audit — 広範な段階的ロードマップ
通常の desloppify の依頼で、暗黙のうちに抜本的なレビューのモードに切り替えないでください。
0) セットアップ
実行します。
desloppify check-tools [path]
リポジトリに明らかにセットアップの支援が必要な場合は、こちらも使用します。
desloppify install-skill
desloppify install-hooks
desloppify setup
install-hooks は .githooks/ を現在の git リポジトリに作成し、有効にします。インストールされたフックは、リポジトリ、bunx、または PATH から CLI を解決します。候補が1つに絞れる場合は、リポジトリで推奨されているパックを自動選択します。また、管理されていないフックファイルや、.git/hooks、.husky、worktree スコープのフック設定にある他の有効なフックチェーンを上書きしません。フックの実行対象はデフォルトで現在の変更です。フックスキャンでリポジトリ全体を対象にする場合は、DESLOPPIFY_HOOK_SCOPE=repo を設定してください。
正確なコマンドやパック/ツールのセットアップの詳細が必要な場合は、次を読んでください。
reference/commands.mdreference/packs-and-tools.md
1) スキャン
最も関連性の高いパックを使って通常のスキャンを開始します。
一般的なデフォルト:
desloppify scan [path] --pack js-ts
このデフォルトの JS/TS パスでは、madge をメインの実行から意図的に除外しています。循環依存の解析が利用できない場合や時間がかかる場合に、通常のスキャンが妨げられるのを防ぐためです。ユーザーが循環依存の解析を明示的に希望した場合に限り、--with-madge または --category circular-deps を追加してください。
次に、以下の順序で成果物を確認します。
.desloppify/reports/latest.findings.jsondesloppify report [path].desloppify/reports/latest.report.md.desloppify/reports/latest.wiki.jsonまたは.desloppify/reports/latest.handoff.md
成果物を書き込む最初のスキャンでは、git リポジトリ内の状態がデフォルトでローカルに保たれるよう、.desloppify/ も .gitignore に自動追加されます。
タスクで必要な場合に限り、--json、--markdown、--wiki、--handoff、--delta、またはベンチマークコマンドを使用してください。非常に大きなリポジトリでは、標準出力を簡潔に保ちながら完全な成果物をディスクに書き込めるよう、--json --summary を優先してください。正確なバリエーションについては、reference/commands.md を読んでください。
2) 優先順位付け
各問題の種類について、次のように判断します。
- Fix — 今すぐ変更する価値がある
- Skip — 意図的なもの、または変更の価値が低い
- Flag-only — 公開 API/動的な動作/シリアライズ/リスクの高いリファクタリング
重要:
- 外部アナライザーの警告を、リポジトリに問題がないという意味に取り違えないでください
- 部分スキャンでは、プロジェクト全体を対象とするアナライザーが省略されます
- JS/TS の全体スキャンでは、オプトインしない限り
madgeがデフォルトで省略されます - スキャン前に
check-toolsを使うと、同梱されているjs-ts、python、rust、go、rubyの各パックから候補を提案できます
パック/ツールの動作の詳細が必要な場合は、reference/packs-and-tools.md を読んでください。
3) 修正
並行して修正する作業には、分離した worktree を優先してください。
desloppify worktrees [path]
次に、各修正エージェントに以下を渡します。
- worktree のパス
- 保存済みレポートのパス、または対象を絞ったスキャン結果
- まず
desloppify fix . --safeを実行すること - 編集後に再スキャンすること
現在の目安:
fix --safeが信頼できるデフォルトです- より広範な修正レベルは一部に限られ、判断が必要です
4) 検証
修正後:
desloppify scan [path]
desloppify report [path]
回帰の判定や修正前後の比較が必要な場合は、desloppify delta ... を使用してください。
付属ドキュメントを参照するタイミング
次が必要な場合は、reference/commands.md を参照してください。
- CLI の正確な実行方法
- レポート/差分/ベンチマークのワークフロー
- 成果物のパス
次が必要な場合は、reference/packs-and-tools.md を参照してください。
- サポート対象のパック
- ツールアダプター
- インストールコマンド
- madge/部分スキャン/リポジトリ内ツールの動作
次が必要な場合は、reference/config-and-plugins.md を参照してください。
- 設定ファイルの検出
- サポート対象の設定フィールド
- プラグインの例
desloppify/plugin-api- プラグインの
rules.<id>.options - 安定したルートプログラム API
identityGroup/fixプラグインの動作
次が必要な場合は、reference/overhaul-review.md を参照してください。
- Surgical/Systematic/Full のレビュー方式
- セクションごとに分けた監査のワークフロー
- 影響度/作業量マトリックスの出力
- スコープ外/障害モード/実行順序の概要
大規模な検出結果に関するガイダンス
GOD_FILE は、むやみに分割するための指示ではなく、リファクタリングの兆候として扱ってください。
検出された理由を調べてください。
- インポートが多すぎる
- ルートと DB に関する処理が混在している
- バレル/エクスポートが集中している
- 1 つのルートファイルに HTTP メソッドが多すぎる
useStateの呼び出しが多すぎる- 汎用的なバケットファイル構造
安全性の段階
- T1 — 機械的な修正
- T2 — AST で検証する修正
- T3 — 複数ファイルにまたがる修正
- フラグのみ — 自動修正しない
抑制
インライン:
console.log("intentional"); // desloppify:ignore CONSOLE_LOG
プロジェクトレベルで抑制するには、.desloppifyignore を使用します。