code-antipatterns

このスキルを使用するタイミング

次の場合にこのスキルを使用します…	次の場合は別のものを使用します…
並列アンチパターンスキャンを実行してレポートを作成する場合	YAML ルールカタログ全体を確認する場合 → REFERENCE.md を参照
空の catch、未処理の Promise、または || true を特に対象とする場合	専用スキャナーを使用 → code-hidden-failures --track errors
成功扱いとなる空の結果／サイレントな劣化パターンを見つける場合	専用スキャナーを使用 → code-hidden-failures --track degradation
セキュリティ、パフォーマンス、アーキテクチャにわたる幅広いコード品質レビューを行う場合	レビュー全体を担当するデリゲートを実行 → code-review

コンテキスト

• 分析パス：$1（指定しない場合は現在のディレクトリ）
• JS/TS ファイル：!find . -type f \( -name "*.js" -o -name "*.ts" -o -name "*.jsx" -o -name "*.tsx" \)
• Vue ファイル：!find . -name "*.vue"
• Python ファイル：!find . -name "*.py"

タスク

包括的なアンチパターン分析を実施してください。機械的な検出は、同梱されたルールプロジェクトに対する決定論的な ast-grep scan 1 回です。sg -p '…' パターンを自分で書き直したり、単にパターンを実行するためだけにエージェントを分散させたりしないでください。あなたの役割は、スキャンで得られた構造化された検出結果に基づく判断、つまり重大度のトリアージ、推奨事項、修正計画です。

Step 1: 決定論的なスキャンを実行する

検出カタログは ast-grep のルールプロジェクトとして rules/ にあります（rules/lib/ の各パターンに *.yml が 1 つずつあり、それぞれに rules/tests/ の有効・無効テスト用フィクスチャが用意されています）。カタログ全体を一度に実行してください。

ast-grep scan -c ${CLAUDE_SKILL_DIR}/rules/sgconfig.yml --json=compact <path>

各 JSON 検出結果には、ruleId、file、range（行／列）、message、一致した text が含まれます。これを解析してください。以下の各カテゴリにおけるすべての検出結果の生データです。ルールの対象は、空の catch、console.log、var、eval／new Function、innerHTML／outerHTML、as any／: any の型注釈、タイマーのマジックナンバー、Vue の props の変更、Python のミュータブルなデフォルト値、裸の except、global、および type() == です。

グレースフルなフォールバック — ast-grep（ast-grep または sg としてパッケージ化）がインストールされていない場合は、パターンごとの手順に切り替えてください。REFERENCE.md を読み、各ルールに対応するソース .yml へのリンクを確認し、個別に ast-grep -p '<pattern>' --lang <lang> コマンドを手動で実行してください。ルールプロジェクトが最速の方法で、リファレンスがフォールバックです。

Step 2: 判断（エージェントが実際に行う作業）

スキャンは機械的かつ再現可能です。トリアージ、推奨、修正計画が判断を要する作業です。パターンを再実行するエージェントを起動するのではなく、スキャン結果に基づいて自分で実施してください。

• 重大度のトリアージ — 以下のカテゴリ表のコンテキストとアプリの種類（フロントエンド／バックエンド／CLI／ライブラリ）に基づいて、各検出結果の重大度を上げるか下げてください。
• エラーの握りつぶしに関する検出結果（空の catch、未処理の Promise、裸の except）→ 重大度モデル、推奨事項の提示、プライバシー情報のマスキングについては /code:hidden-failures --track errors に委任してください。ここで再分類しないでください。
• 推奨事項と修正計画 — システム的な問題をまとめ、ast-grep で自動fixできる検出結果を記載し、プロセスの変更（lint ルール、pre-commit）を提案してください。

並列の Task 分散は、（詳細なセキュリティレビューやフレームワーク固有のアーキテクチャ分析など）本当に独立した推論が必要な場合に限ってください。Step 1 ですでに一度、決定論的に実行したパターンの実行には使用しないでください。

分析カテゴリ

検出された言語に基づいて、次のカテゴリを分析します。

1. JavaScript/TypeScript のアンチパターン

   • コールバック、マジック値、console.logs
   • var の使用、非推奨のパターン
   • エラーの握りつぶし（空の catch、未処理の Promise）→ /code:hidden-failures --track errors に委任します

2. 非同期処理／Promise のパターン

   • ネストされたコールバック、Promise コンストラクターのアンチパターン
   • エラー処理の網羅性（未処理／未待機の Promise）→ /code:hidden-failures --track errors に委任します

3. フレームワーク固有の項目（検出された場合）

   • Vue 3：Props の変更、リアクティビティの問題、Options API と Composition API の混在
   • React：フックの依存配列の不足、インライン関数、Props のバケツリレー

4. TypeScript の品質（.ts ファイルがある場合）

   • 過剰な any 型、非 null アサーション、型安全性の問題

5. コードの複雑さ

   • 長い関数（50 行超）、深いネスト（4 レベル超）、大きなパラメーターリスト

6. セキュリティ上の懸念

   • eval の使用、innerHTML による XSS、ハードコードされたシークレット、インジェクションのリスク

7. メモリとパフォーマンス

   • クリーンアップされないイベントリスナー、setInterval のリーク、非効率なパターン

8. Python のアンチパターン（検出された場合）

   • 可変なデフォルト引数、グローバル変数
   • bare except と抑制パターン → /code:hidden-failures --track errors に委任します

委任されるカテゴリ：エラーの握りつぶし

ここでは、空の catch／bare except／未待機の Promise の検出を再実装しないでください。 SlashCommand ツール経由で /code:hidden-failures --track errors を、同じ PATH と重大度フィルターを指定して呼び出し、その結果を「エラーの握りつぶし」という専用セクションの下に統合レポートへ反映してください。

理由：信頼できる情報源を一本化することで、重大度モデル、アプリケーションコンテキストに応じた提示の推奨事項、プライバシー保護のためのマスキングポリシーに不一致が生じるのを防げます。code-quality-plugin/skills/code-hidden-failures/SKILL.md を参照してください。

ルールプロジェクトが対象としない項目（エージェントによる判断）

カタログに含まれる懸念事項のうち、構造上の単一ノードに一致しない 2 つは、ルールではなく、コードに対するエージェントによる判断で確認します。

• 深いネスト／長い関数／循環的複雑度 — 関数本体に対するメトリクスであり、パターンではありません。/code:complexity を使用するか、フラグが付いたファイルを読んでください。
• 未待機の Promise — リポジトリ独自のツールチェーンを信頼してください。すべての呼び出しにフラグを付ける広範な構造ルールではなく、tsc と no-floating-promises ESLint ルール、または /code:hidden-failures --track errors に委ねてください。

出力形式

結果を次の構成にまとめます。

## Anti-pattern Analysis Report

### Summary
- Total issues: X
- Critical: X | High: X | Medium: X | Low: X
- Categories with most issues: [list]

### Critical Issues (Fix Immediately)
| File | Line | Issue | Category |
|------|------|-------|----------|
| ... | ... | ... | ... |

### High Priority Issues
| File | Line | Issue | Category |
|------|------|-------|----------|
| ... | ... | ... | ... |

### Medium Priority Issues
[Similar table]

### Low Priority / Style Issues
[Similar table or summary count]

### Recommendations
1. [Prioritized fix recommendations]
2. [...]

### Category Breakdown
- **Security**: X issues (details)
- **Async/Promises**: X issues (details)
- **Code Complexity**: X issues (details)
- [...]

オプションのフラグ

• --focus <category>：特定のカテゴリ（security、async、complexity、framework）に絞り込みます
• --severity <level>：報告する最低重大度（critical、high、medium、low）を指定します
• --fix：安全な場合、自動修正を試みます

分析後

結果をまとめた後、次のことを行います。

1. 影響度と作業量に基づいて問題に優先順位を付ける
2. ast-grep で自動修正できる問題を提案する
3. システム全体に及ぶ問題を示すパターンを特定する
4. プロセスの改善策（lint ルール、コミット前フック）を推奨する

関連項目

• ルールプロジェクト：rules/ — 実行可能な ast-grep カタログ（sgconfig.yml + rules/lib/*.yml + rules/tests/*-test.yml）。ast-grep test -c rules/sgconfig.yml --skip-snapshot-tests を実行して、すべてのルールを対応するフィクスチャに対して検証します
• リファレンス：REFERENCE.md — 各パターンとルールファイルを関連付けた解説付きカタログ
• スキル：ast-grep-search — ast-grep の使用方法に関するリファレンス
• コマンド：/code:review — 包括的なコードレビュー
• エージェント：security-audit — 詳細なセキュリティ分析
• エージェント：code-refactoring — 自動リファクタリング

関連する設定スキル

• lint が設定されていない場合 → 自動適用のために /configure:linting を使用します
• セキュリティスキャンが設定されていない場合 → CI との統合のために /configure:security を使用します