desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
description の原文を見る
Codebase health scanner and technical debt tracker. Use when the user asks about code quality, technical debt, dead code, large files, god classes, duplicate functions, code smells, naming issues, import cycles, or coupling problems. Also use when asked for a health score, what to fix next, or to create a cleanup plan. Supports 29 languages.
SKILL.md 本文
Desloppify
1. あなたの役割
strict スコアを誠実に最大化します。主要なサイクルは:scan → plan → execute → rescanです。スキャン出力の INSTRUCTIONS FOR AGENTS に従い、独自の分析に置き換えないでください。
**怠けないでください。**大規模なリファクタリングと小さな詳細な修正に同じ熱意を持って取り組みます。20ファイルに触れる必要があれば、20ファイルに触れます。1行の変更であれば、それを行います。どのタスクも大きすぎたり小さすぎたりすることはありません。最小限ではなく、適切に物事を修正します。
2. ワークフロー
3つのフェーズを繰り返します。
フェーズ 1:スキャンと確認 — コードベースを理解する
desloppify scan --path . # コードベースを分析
desloppify status # スコアを確認 — 目標に達しているか?
スキャンはサブジェクティブな次元のレビューが必要かどうかを教えてくれます。その指示に従ってください。レビューを手動でトリガーするには:
desloppify review --prepare # その後、ランナーのレビューワークフローに従う
フェーズ 2:計画 — 何に取り組むかを決定する
レビュー後、トリアージステージと計画作成が next によってサーフェスされた実行キューに表示されます。それらを順番に完了してください。next は各ステージが --report で期待することを示します:
desloppify next # 次の実行ワークフローステップを表示
desloppify plan triage --stage observe --report "テーマと根本原因..."
desloppify plan triage --stage reflect --report "完了した作業との比較..."
desloppify plan triage --stage organize --report "優先事項の概要..."
desloppify plan triage --complete --strategy "実行計画..."
自動トリアージの場合:desloppify plan triage --run-stages --runner codex(Codex)または --runner claude(Claude)。オプション:--only-stages、--dry-run、--stage-timeout-seconds。
次に、キューを調整します。計画は next が提供するすべてを形作ります — next は完全なバックログではなく実行キューです。このステップをスキップしないでください。
desloppify plan # 生きた計画の詳細を表示
desloppify plan queue # コンパクトな実行キュービュー
desloppify plan reorder <pat> top # 並べ替え — 何が最も多くのブロックを解除するか?
desloppify plan cluster create <name> # 関連する問題をグループ化してバッチ修正
desloppify plan focus <cluster> # 次を1つのクラスターに制限
desloppify plan skip <pat> # 延期 — 次から非表示にする
フェーズ 3:実行 — キューを完了まで処理する
計画を信頼して実行します。キューの途中で再スキャンしないでください。キューが完了するまで続けてください。
**まずブランチを作成します。**専用ブランチを作成します — ヘルスワークをメインに直接コミットしないでください:
git checkout -b desloppify/code-health # または desloppify/<focus-area>
desloppify config set commit_pr 42 # PR をリンクして説明の自動更新を有効にする
ループ:
# 1. 実行キューから次のアイテムを取得
desloppify next
# 2. コード内の問題を修正
# 3. それを解決します(next は必要な証明を含む正確なコマンドを表示します)
# 4. 論理的なバッチがある場合、コミットして記録
git add <files> && git commit -m "desloppify: fix 3 deferred_import findings"
desloppify plan commit-log record # 検出結果をコミット前からコミット済みに移動し、PR を更新
# 5. 定期的にプッシュ
git push -u origin desloppify/code-health
# 6. キューが空になるまで繰り返す
修正後、スコアが一時的に低下することがあります。カスケード効果は正常であり、続行します。
next が自動フィクサーを示唆する場合、desloppify autofix <fixer> --dry-run を実行してプレビューしてから適用します。
**キューがクリアされたら、フェーズ 1 に戻ります。**新しい問題が表面化し、カスケードが解決され、優先事項がシフトします。これがサイクルです。
3. リファレンス
主要な概念
- ティア:T1 自動修正 → T2 簡単な手動修正 → T3 判断が必要 → T4 大規模なリファクタリング。
- 自動クラスター:関連する検出結果は
nextで自動的にグループ化されます。next --cluster <name>でドリルイン。 - ゾーン:本番/スクリプト(スコア対象)、テスト/設定/生成/ベンダー(スコア対象外)。
zone setで修正します。 - 修正除外コスト:lenient ↔ strict ギャップを広げます。ギャップが増大したら過去の決定に異議を唱えます。
スコアリング
全体スコア = 25% 機械的 + 75% サブジェクティブ。
- 機械的(25%):自動検出された問題 — 重複、デッドコード、スメル、未使用インポート、セキュリティ。コード変更とスキャン再実行で修正されます。
- サブジェクティブ(75%):デザイン品質レビュー — 命名、エラーハンドリング、抽象化、明確性。レビューされるまで 0% で開始します。スキャンはレビューが必要な場合に通知します。
- Strict スコア が北極星です:wontfix アイテムはオープンとしてカウントされます。全体と strict のギャップが wontfix 債です。
- スコアタイプ:overall(lenient)、strict(wontfix がカウント)、objective(機械的のみ)、verified(確認済み修正のみ)。
レビュー
サブジェクティブスコアを取得する4つのパス:
-
ローカルランナー(Codex):
desloppify review --run-batches --runner codex --parallel --scan-after-import— 自動化されたエンドツーエンド。 -
ローカルランナー(Claude):
desloppify review --prepare→ 並列サブエージェントを起動 →desloppify review --import merged.json— スキルドキュメントのオーバーレイ詳細を参照。 -
クラウド/外部:
desloppify review --external-start --external-runner claude→ セッションテンプレートに従う →--external-submit。 -
手動パス:
desloppify review --prepare→ 次元ごとにレビュー →desloppify review --import file.json。 -
最初にインポート、その後修正 — インポートは相関のための追跡状態エントリを作成します。
-
ターゲット一致スコアはゲーム化を防ぐために自動リセットをトリガーします。エージェントオーバーレイドキュメント(例:
docs/CLAUDE.md、docs/HERMES.md)に記載されたブラインドレビューワークフローを使用します。 -
中程度のスコア(60-80)でも、全体的なヘルスを大幅に改善します。
-
古い次元は
nextで自動的にサーフェスされます — キューに従うだけです。
整合性ルール:証拠のみからスコア化してください — 過去のチャットコンテキスト、スコア履歴、またはターゲット閾値アンカリングはしません。証拠が混合している場合は、より低くスコア化して不確実性を説明します。要求されたすべての次元を評価し、1つも削除しません。
レビュー出力形式
レビューインポート用の機械読取可能な JSON を返します。--external-submit の場合、生成されたテンプレートから session を含めます:
{
"session": {
"id": "<session_id_from_template>",
"token": "<session_token_from_template>"
},
"assessments": {
"<dimension_from_query>": 0
},
"findings": [
{
"dimension": "<dimension_from_query>",
"identifier": "short_id",
"summary": "1行の欠陥の概要",
"related_files": ["relative/path/to/file.py"],
"evidence": ["具体的なコード観察"],
"suggestion": "具体的な修正提案",
"confidence": "high|medium|low"
}
]
}
findings は query.system_prompt と正確に一致する必要があります(related_files、evidence、suggestion を含む)。欠陥が見つからない場合は "findings": [] を使用します。インポートは fail-close です:--allow-partial が渡されない限り、無効な検出結果はアボートします。評価スコアは信頼できる内部またはクラウドセッションインポートから自動的に適用されます。レガシ --attested-external は引き続きサポートされています。
インポートパス
- 堅牢なセッションフロー(推奨):
desloppify review --external-start --external-runner claude→ 生成されたプロンプト/テンプレートを使用 → 印刷された--external-submitコマンドを実行。 - 耐久性のあるスコア付きインポート(レガシ):
desloppify review --import findings.json --attested-external --attest "このレビューが全体スコアに関する認識なしに完了したこと、および偏りがないことを検証しました。" - 検出結果のみフォールバック:
desloppify review --import findings.json
レビュアーエージェントプロンプト
エージェント定義をサポートするランナー(Cursor、Copilot、Gemini)は、専用レビュアーエージェントを作成できます。このシステムプロンプトを使用します:
You are a code quality reviewer. You will be given a codebase path, a set of
dimensions to score, and what each dimension means. Read the code, score each
dimension 0-100 from evidence only, and return JSON in the required format.
Do not anchor to target thresholds. When evidence is mixed, score lower and
explain uncertainty.
エディターのオーバーレイセクションのエージェント設定形式を参照してください。
計画コマンド
desloppify plan reorder <cluster> top # すべてのクラスターメンバーを一度に移動
desloppify plan reorder <a> <b> top # クラスターと検出結果を1つの並べ替えで混在
desloppify plan reorder <pat> before -t X # 別のアイテム/クラスターに相対的に配置
desloppify plan cluster reorder a,b top # 複数のクラスターを1つのブロックとして並べ替え
desloppify plan resolve <pat> # 完了としてマーク
desloppify plan reopen <pat> # 再度開く
desloppify backlog # より広いノン実行バックログ
コミット追跡
desloppify plan commit-log # コミット前 + コミット済みの状態を表示
desloppify plan commit-log record # HEAD コミットを記録し、PR 説明を更新
desloppify plan commit-log record --note "why" # 根拠付き
desloppify plan commit-log record --only "smells::*" # 特定の検出結果のみを記録
desloppify plan commit-log history # コミット記録を表示
desloppify plan commit-log pr # PR 本文マークダウンをプレビュー
desloppify config set commit_tracking_enabled false # ガイダンスを無効化
検出結果を fixed として解決した後、ツールはコミット前のワーク、コミット履歴、および提案されたコミットメッセージを表示します。外部でコミット後、record を実行して検出結果をコミット前からコミット済みに移動し、リンクされた PR の説明を自動更新します。
クイックリファレンス
desloppify next --count 5 # 上位 5 件の実行アイテム
desloppify next --cluster <name> # クラスターにドリルイン
desloppify backlog --count 5 # 実行外の上位 5 件のバックログアイテム
desloppify show <pattern> # ファイル/検出器/ID でフィルタ
desloppify show --status open # すべてのオープン検出結果
desloppify plan skip --permanent "<id>" --note "reason" --attest "..." # 債を受け入れる
desloppify exclude <path> # スキャンからディレクトリを除外
desloppify config show # 除外を含むすべての設定を表示
desloppify scan --path . --reset-subjective # サブジェクティブベースラインを 0 にリセット
4. ツールの問題をアップストリームで修正する
desloppify 自体が間違っているか一貫性がない場合(バグ、悪い検出、クラッシュ、わかりにくい出力)— それを修正して PR を開いてください。自信を持ってそれを修正できない場合は、代わりにイシューを提出します。
修正と PR(推奨)
ツールリポジトリを一時ディレクトリにクローン、そこで修正を行い、プッシュする前にスキャンしているプロジェクトに対して機能することを確認します。
git clone https://github.com/peteromallet/desloppify.git /tmp/desloppify-fix
cd /tmp/desloppify-fix
git checkout -b fix/<short-description>
変更を行い、テストスイートを実行して、元のプロジェクトに対して修正を確認します:
python -m pytest desloppify/tests/ -q
python -m desloppify scan --path <project-root> # スキャンしていたプロジェクト
良好に見えたら、プッシュして PR を開きます:
git add <files> && git commit -m "fix: <what and why>"
git push -u origin fix/<short-description>
gh pr create --title "fix: <short description>" --body "$(cat <<'EOF'
## Problem
<何が間違ったか — コマンドと出力を含める>
## Fix
<変更内容と理由>
EOF
)"
クリーンアップ後:rm -rf /tmp/desloppify-fix
イシューを提出する(フォールバック)
修正が不明確であるか、変更がディスカッションを必要とする場合は、https://github.com/peteromallet/desloppify/issues で最小限の再現例とともにイシューを開きます:コマンド、パス、期待される出力、実際の出力。
前提条件
command -v desloppify >/dev/null 2>&1 && echo "desloppify: installed" || echo "NOT INSTALLED — run: pip install --upgrade git+https://github.com/peteromallet/desloppify.git"
Codex オーバーレイ
これは README インストールコマンドで使用される正規の Codex オーバーレイです。
- ファーストクラスのバッチ実行を優先します:
desloppify review --run-batches --runner codex --parallel --scan-after-import。 - コマンドは
.desloppify/review_packets/holistic_packet_*.jsonの下に不変パケットスナップショットを書き込みます。これらを再現可能な再試行に使用します。 - レビュアー入力を不変パケットと各バッチで名前が付けられたソースファイルのスコープに保ちます。
- バッチが失敗した場合、
desloppify review --run-batches --packet <packet.json> --only-batches <idxs>でそのスライスのみを再試行します。 - 手動オーバーライドは安全スコープされています:
--allow-partialと組み合わせることはできず、暫定手動スコアは信頼できる内部またはアテステーション済み外部インポートで置き換えられない限り、次のscanで有効期限切れになります。
トリアージワークフロー
自動トリアージを優先します:desloppify plan triage --run-stages --runner codex
オプション:--only-stages observe,reflect(サブセット)、--dry-run(プロンプトのみ)、--stage-timeout-seconds N(ステージごと)。
実行アーティファクトは .desloppify/triage_runs/<timestamp>/ に移動します — 各実行は run.log(ライブタイムスタンプイベント)、run_summary.json、ステージごとの prompts/、output/、logs/ を含む独自のディレクトリを取得します。run.log を確認してスタールやエラーを診断します。再実行は最後に確認されたステージから再開します。
自動トリアージがスタールした場合、run.log で最後のイベントを確認し、desloppify plan triage --stage-prompt <stage> を使用してゲートルール付きの完全なプロンプトを取得します。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- Git-on-my-level
- ライセンス
- MIT
- 最終更新
- 2026/5/12
Source: https://github.com/Git-on-my-level/codex-autorunner / ライセンス: MIT