Menu
コードの品質問題、アンチパターン、可読性を検査。機能実装、コードレビュー、リファクタリング時に使用。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
PRD、ADR、Design Doc、UI Spec、作業計画書の作成を支援。技術ドキュメントの作成・レビュー時、または「UI Spec/画面設計/コンポーネント分解」が言及された時に使用。
入力・出力・成功基準・決定事項・未解決条件を明確化し、下流エージェントが推測せず実行できるようにする。LLM向けのプロンプト・ハンドオフ・計画成果物・レビュー・レポート・生成指示を記述または改訂する時に使用。
タスクの本質を分析し適切なスキルを選択。規模見積もりとメタデータを返却。タスク開始時、スキル選択時に使用。
Guides PRD, ADR, Design Doc, UI Spec, and Work Plan creation. Use when creating or reviewing technical documents, or when "UI spec/screen design/component decomposition" is mentioned.
Clarifies inputs, outputs, success criteria, decisions, and unresolved conditions so downstream agents can execute without guessing. Use when writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions.
Analyzes task essence and selects appropriate skills. Returns scale estimates and metadata. Use when starting tasks or selecting skills.
| name | coding-standards |
| description | コードの品質問題、アンチパターン、可読性を検査。機能実装、コードレビュー、リファクタリング時に使用。 |
以下のパターンを検出したら即座に停止し、設計を見直すこと：
エラー時は速やかに失敗させ、不正な状態での処理継続を防ぐ。エラーの握りつぶしは禁止。
詳細な実装方法（Result型、カスタムエラークラス、層別エラー処理など）は各言語・フレームワークのルールを参照。
Martin Fowler「Refactoring」に基づく重複コードの扱い方：
| 重複回数 | 対応 | 理由 |
|---|---|---|
| 1回目 | インライン実装 | 将来の変化が予測できない |
| 2回目 | 将来の統合を意識 | パターンが見え始める |
| 3回目 | 共通化実施 | パターンが確立された |
共通化すべきケース
共通化を避けるべきケース
失敗パターン: 近隣2-3ファイルのパターンや依存バージョンをリポジトリ全体での使用状況を確認せずに採用すると、古いパターン、バージョン不一致、アーキテクチャ不整合が発生する。
既存コードからパターン、API、依存を採用する場合:
近隣コードは調査の起点。採用の根拠にするにはリポジトリ全体での使用状況（異なるディレクトリの3ファイル以上）を確認すること。
症状: エラーを修正すると新しいエラーが発生 原因: 根本原因を理解せずに表面的な修正 回避方法: 5 Whysで根本原因を特定してから修正
症状: any型やasの多用 原因: 型エラーを回避したい衝動 回避方法: unknown型と型ガードで安全に処理
症状: 実装後にバグ多発 原因: Red-Green-Refactorプロセスの無視 回避方法: 必ず失敗するテストから開始
症状: 新技術導入時の想定外エラー多発 原因: 事前調査なしで「公式ドキュメント通りなら動くはず」 回避方法:
症状: 重複実装、アーキテクチャ不整合、結合時の障害、古いパターンの採用 原因: 実装前の既存コード理解不足、近隣ファイルのみ参照し代表性を確認していない 回避方法:
症状: TypeScriptのビルドエラー
Why1: 型定義が一致しない → Why2: インターフェースが更新された
Why3: 依存関係の変更 → Why4: パッケージ更新の影響
Why5: 破壊的変更を含むメジャーバージョンアップ
根本原因: package.jsonでのバージョン指定が不適切
問題を切り分けるため、最小限のコードで再現を試みる：
型安全の原則: unknown型と型ガードを使用する。any型は型チェックを無効化し、実行時エラーの原因となる。
any型の代替手段（優先順位順）
型ガードの実装パターン
function isUser(value: unknown): value is User {
return typeof value === 'object' && value !== null && 'id' in value && 'name' in value
}
型の複雑性管理
基本方針
実施手順: 現状把握 → 段階的変更 → 動作確認 → 最終検証
優先順位: 重複コード削除 > 長大な関数分割 > 複雑な条件分岐簡素化 > 型安全性向上
完了定義: 以下3段階すべての完了
Grep -n "TargetClass\|TargetMethod" -o content
Grep -n "DependencyClass" -o content
Grep -n "targetData\|SetData\|UpdateData" -o content
必須: 発見した全ファイルを読み込み、作業に必要な部分をコンテキストに含める：
影響範囲の構造化報告（必須）：
## 影響範囲分析
### 直接影響: ClassA、ClassB（理由明記）
### 間接影響: SystemX、PrefabY（連携経路明記）
### 処理フロー: 入力→処理1→処理2→出力
重要: 検索のみで完了とせず、3段階すべてを実行すること
未使用コード検出時 → 使用予定？
対象: コード・ドキュメント・設定ファイル
推奨原則: コード変更は必ずテストから始める
開発ステップ:
NGケース（テストファースト不要）:
推奨: 単体テストでの外部依存モック化
避けるべき: 単体テストでの実際の外部接続
テストを修正: 間違った期待値、存在しない機能参照、実装詳細への依存、テストのためだけの実装 実装を修正: 妥当な仕様、ビジネスロジック、重要なエッジケース 判断に迷ったら: ユーザーに確認
テスト対象：公開API、戻り値、例外、外部呼び出し、永続化された状態 テスト対象外：privateメソッド、内部状態、アルゴリズム詳細
references/security-checks.mdを参照