Menu
コードの品質問題、アンチパターン、可読性を検査。機能実装、コードレビュー、リファクタリング時に使用。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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を参照