absolute-debt について
コードベース全体に蓄積した lint と型チェックの問題を、安全な段階に分けて解消し、各段階でテストを検証するスキルです。現在の作業差分ではなく、既存の違反や抑制を対象にします。
主な機能
- 01JS/TS、Python、Go の lint と型エラーを検出
- 02抑制指定も負債として一覧化
- 03ルール単位で違反を分類
- 04動作リスクに応じて修正を優先付け
- 05各段階でテスト、lint、型チェック、ビルドを実行
活用シーン
- 01蓄積した lint 警告や型エラーの解消
- 02古いチェッカー抑制指定の削除
- 03lint や型チェック設定の厳格化
- 04main ブランチに残る既存違反の整理
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/absolute-debtを入力して読み込まれたか確認します。
同梱ファイルREADME.mdreferences/health-engine.md
詳細
最初の回答は🧾の絵文字で始めてください。
絶対的な負債
リポジトリ全体に蓄積した lint と型チェッカーの負債、つまり時間とともに増えた既存の警告、
エラー、抑制を、ルールごとに安全な段階に分けて解消します。各段階の後にはテストを
すべて成功させます。目標は、lint + typecheck の出力を単に減らすのではなく、
本当にクリーンな状態にすることです。
references/health-engine.md の共通エンジンを実行します。DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT の
ループと安全性に関する契約を確認してください。このファイルでは、lint／型の負債に
固有の内容のみを扱います。
使用するタイミング
- 「lint の警告を修正して」「型エラーを解消して」「コードベースを strict モードにして」。
- 設定を厳格化する（ルールを有効にする、
tsconfigの厳格さを上げる）と同時に、その影響を解消する場合。 - 蓄積した
eslint-disable/@ts-ignore/# type: ignoreの抑制を一掃する場合。
debt と simplify の違い： simplify は、作業中の差分の品質を高めます。debt は、
グリーンな main にあるリポジトリ全体の既存の lint／型違反を解消します。debt は
継続的なクリーンアップに使用し、現在作業中の変更には使用しないでください。
スキャン対象
| エコシステム | lint の負債 | 型の負債 |
|---|---|---|
| JS/TS | eslint .（ルールごとの完全なレポート） | tsc --noEmit |
| Python | ruff check / flake8 | mypy / pyright |
| Go | golangci-lint run | go vet ./...、staticcheck |
抑制も、それ自体が負債として洗い出します。eslint-disable*、
@ts-ignore/@ts-expect-error、# type: ignore、# noqa、//nolint が対象です。いずれも隠れた
違反です。違反はファイルごとではなく、ルールごとに集計します。これが段階的に解消する方法です。
リスクのランク付け（TRIAGE）
| 段階 | 分類 | デフォルト |
|---|---|---|
| 1 | 自動修正可能な lint（eslint --fix、ruff --fix、gofmt） | 今すぐ修正 — 機械的で安全 |
| 2 | 動作へのリスクが低い、ルールごとの手動 lint 修正（未使用、スタイル、インポート） | 今回のパスで、ルールごとに修正 |
| 3 | 型エラー、および誤った「修正」で動作が変わる可能性のある lint ルール | 要確認 — 個別にレビューし、実際のロジック修正が必要な場合あり |
| 4 | 抑制の削除（@ts-ignore など） | 要確認 — それぞれが実際のバグを表面化させる場合あり |
ファイルごとにすべてのルールを修正するのではなく、段階ごとにリポジトリ全体の1つのルールを修正します。こうすることで差分を レビューしやすくし、回帰を二分探索できるようにします。設定の厳格化（ルールの有効化／厳格さの引き上げ）も 検出事項です。まず提案し、その後で表面化した問題を解消します。
修正と検証
- まず自動修正ツールを実行し（段階1）、コミットできる状態にしてから再スキャンし、本当に手動修正が必要なものを確認します。
- 手動修正では、症状ではなく原因に対処します。型エラーは、どこかで型が
間違っていることを意味します。型を修正し、
anyへのキャストや# type: ignoreの追加は避けてください。 - 違反を抑制して解消することは絶対にしないでください。抑制の削除は目標であり、ツールではありません。
- 各段階の後に、テスト、lint、型チェック、ビルドをすべて実行します。違反数が減り、 回帰が起きないことを確認します。
注意点
- 抑制による修正。 型エラーを解消するための
@ts-ignoreは、負債を増やします。ここでは禁止です。 any/castで切り抜ける。 チェッカーを黙らせるだけで、バグは残ります。本当の型を修正してください。- 1ファイルですべてのルールを修正する段階。 懸念事項が混在し、レビューできなくなります。1つのルールを全ファイルで修正してください。
- レビューなしの自動修正。
--fixは動作を変える場合があります（例：バグで再代入されている変数に対するprefer-const）。自動修正の後もテストを実行してください。 - 修正ではなくルールを無効化する。 違反数をゼロにするために設定を緩めるのは、負債を解消することではなく、負債を隠すことです。
関連コマンド
/absolute simplify— 現在変更中のコードの品質を高めます。/absolute prune— デッドコードを整理すると、多くの未使用変数／インポートの警告がなくなります。/absolute work— 負債の解消に実際のリファクタリングが必要な場合に引き継ぎます。