code-quality について
開発者やコーディングエージェント向けの、コード品質を確認する7段階のワークフロースキルです。機能上の問題解決確認とは分けて、ドキュメント調査、影響分析、重複検出、リンター実行から再検証まで行います。
主な機能
- 01アーキテクチャと規約の調査
- 02ドキュメントとAPIの調査
- 03Grepによる変更影響の評価
- 04jscpdによる重複検出
- 05リンター実行と的確な修正
- 06リンター、テスト、重複の再確認
活用シーン
- 01修正の機能確認後のコードレビュー
- 02リファクタリング前の重複検出
- 03変更箇所の利用状況とリスクの確認
- 04複数言語のプロジェクトの品質検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ fusengine/ claude-plugins --skill code-qualityインストール後、Claude Code で/code-qualityを入力して読み込まれたか確認します。
詳細
これは事後に品質を検証するものであり、元の問題が実際に解決されたことを確認するものではありません。まず verification スキルを実行して機能上の解決を確認し、その後 code-quality で修正が適切であることを確認してください。
Code Quality スキル
標準ワークフローの定義:agents/sniper.md(このスキルと sniper エージェントは同じ7フェーズのワークフローを共有します。両方を一緒に更新してください)。
🚨 必須の7フェーズワークフロー
PHASE 1: Exploration (explore-codebase) → BLOCKER
PHASE 2: Documentation (research-expert) → BLOCKER
PHASE 3: Impact Analysis (Grep usages) → BLOCKER
PHASE 3.5: DRY Detection (jscpd duplication) → NON-BLOCKING
PHASE 4: Error Detection (linters)
PHASE 5: Precision Correction (with docs + impact + DRY)
PHASE 6: Verification (re-run linters, tests, duplication)
重要:フェーズ1~3は必須です。決して省略しないでください。 DRY:フェーズ3.5は必須ではありませんが、調査結果はフェーズ5の修正に役立ちます。
フェーズ1:アーキテクチャの調査
最初に explore-codebase エージェントを起動してください:
> Agent(subagent_type="fuse-ai-pilot:explore-codebase", prompt="...")
以下を収集します:
- 検出されたプログラミング言語
- 既存のリンター設定(.eslintrc、.prettierrc、pyproject.toml)
- パッケージマネージャーとインストール済みのリンター
- プロジェクトの構造と規約
- フレームワークのバージョン(package.json、go.mod、Cargo.toml)
- アーキテクチャパターン(Clean、Hexagonal、MVC)
- 状態管理(Zustand、Redux、Context)
- インターフェース/型のディレクトリの場所
フェーズ2:ドキュメントの調査
research-expert エージェントを起動してください:
> Agent(subagent_type="fuse-ai-pilot:research-expert", prompt="Verify [library/framework] documentation for [error type]. Find [language] best practices for [specific issue].")
各エラーについて以下を確認します:
- 公式 API ドキュメント
- 現在の構文と非推奨項目
- エラーパターンに関するベストプラクティス
- バージョン固有の破壊的変更
- セキュリティ勧告
- 言語固有の SOLID パターン
フェーズ3:影響分析
変更する要素ごとに:Grep で使用箇所を確認 → リスクを評価 → 影響を記録します。
| リスク | 条件 | 対応 |
|---|---|---|
| 🟢 低 | 内部のみ、使用箇所が0~1件 | 進める |
| 🟡 中 | 使用箇所が2~5件、互換性あり | 慎重に進める |
| 🔴 高 | 使用箇所が5件以上、または破壊的変更 | まずユーザーに警告する |
フェーズ3.5:コード重複の検出(DRY)
ツール:jscpd — 150以上の言語に対応 — npx jscpd ./src --threshold 5 --reporters console,json
| レベル | しきい値 | 対応 |
|---|---|---|
| 🟢 優秀 | < 3% | 対応不要 |
| 🟡 良好 | 3~5% | 記録し、時間があれば修正 |
| 🟠 許容範囲 | 5~10% | 共通ロジックを抽出 |
| 🔴 重大 | > 10% | 必須のリファクタリング |
言語ごとのしきい値、設定、抽出パターンについては、references/duplication-thresholds.md を参照してください。 言語固有の jscpd コマンドについては、references/linter-commands.md を参照してください。
リンターコマンド
言語固有のコマンドについては、references/linter-commands.md を参照してください。
エラー優先度マトリクス
| 優先度 | 種類 | 例 | 対応 |
|---|---|---|---|
| 重大 | セキュリティ | SQL インジェクション、XSS、CSRF、認証の回避 | 直ちに修正 |
| 高 | ロジック | SOLID 違反、メモリリーク、競合状態 | 同じセッション内で修正 |
| 高 | DRY | コード重複が10%超、コピー&ペーストされたロジックブロック | 必須のリファクタリング |
| 中 | DRY | コード重複が5~10%、繰り返しパターン | 共通ロジックを抽出 |
| 中 | パフォーマンス | N+1 クエリ、非推奨 API、非効率なアルゴリズム | 時間があれば修正 |
| 低 | スタイル | フォーマット、命名、ドキュメントの不足 | 時間があれば修正 |
SOLID の検証
S-O-L-I-D の検出パターンと修正例については、references/solid-validation.md を参照してください。
ファイルサイズのルール
行数の上限、計算方法、分割方法については、references/file-size-rules.md を参照してください。
アーキテクチャルール
プロジェクトの構造とパターンについては、references/architecture-patterns.md を参照してください。
検証レポートの形式
完全なスナイパーレポートのテンプレートについては、references/validation-report.md を参照してください。
ワークフローの完全な例
詳しい手順については、references/examples.md を参照してください。
禁止されている行為
ワークフロー違反
- ❌ PHASE 1(explore-codebase)を省略する
- ❌ PHASE 2(research-expert)を省略する
- ❌ PHASE 3(impact analysis)を省略する
- ❌ PHASE 3.5(DRY detection)を省略する
- ❌ PHASE 1〜3を完了せずに修正に進む
- ❌ BLOCKER が有効な状態で作業を進める
コード品質違反
- ❌ リンターエラーを1つでも未修正のままにする
- ❌ 新たなエラーを引き起こす修正を適用する
- ❌ SOLID 違反を無視する
- ❌ 5%を超える重複を伴う DRY 違反を無視する
- ❌ 共通ロジックを抽出せず、コードをコピー&ペーストする
- ❌ プロジェクトにテストがない場合にテストを作成する
アーキテクチャ違反
- ❌ コンポーネントファイル内にインターフェースを定義する(許容度ゼロ)
- ❌ コンポーネント内にビジネスロジックを記述する(フック内に記述する必要があります)
- ❌ モノリシックなコンポーネントを作成する(セクション分割が必要です)
- ❌ 分割せずにファイルを
FUSE_SOLID_MAX_LINESを超える長さにする - ❌ グローバルデータにローカル状態を使用する(ストアを使用してください)
安全性に関する違反
- ❌ ユーザーの承認なしに高リスクの変更を行う
- ❌ 後方互換性を損なう変更を黙って行う
- ❌ 非推奨化せずにパブリック API を変更する