القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/shinpr/ai-coding-project-boilerplate --skill coding-standardsيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
Detects code smells, anti-patterns, and readability issues. Use when implementing features, reviewing code, or refactoring.
Determines which PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires and where each is stored. Use when deciding documentation scope or creating or reviewing a technical document.
Selects implementation strategy (vertical slice, horizontal, or hybrid) with risk assessment. Use when planning feature implementation.
| name | coding-standards |
| description | コードの品質問題、アンチパターン、可読性を検査。機能実装、コードレビュー、リファクタリング時に使用。 |
以下のパターンを検出したら実装を一時停止し、該当パターン、影響を受ける現行要件、準拠できる最小の代替案、再開に必要な検証を記録する。代替案によってパターンが解消された場合、または文書化された要件によって維持する根拠を示せた場合に再開する。
ユーザー・運用者・保守者に必要な価値を届けつつ、システムの正しさと保守性を保てる、総合的な複雑性が最も低い解をエビデンスから選べる範囲まで調査する。
総合的な複雑性は、この設計で増えるユーザーの判断・設定・モード・概念・出力・永続状態・実装経路と、それらに伴うUX・実行時・実装・テスト・文書・保守のコストで判断する。成立する案の間で実際に異なる観点だけを比較する。同じ確認済みの価値と証明をより低い複雑性で届けられる場合は、既存機能の再利用または新しい仕組みを追加しない案を選ぶ。
エラー時は速やかに失敗させ、不正な状態での処理継続を防ぐ。元の診断情報を保持したまま失敗を伝播するか、明示的な型付きエラーを返す。
詳細な実装方法（Result型、カスタムエラークラス、層別エラー処理など）は各言語・フレームワークのルールを参照。
Martin Fowler「Refactoring」に基づく重複コードの扱い方：
| 重複回数 | 対応 | 理由 |
|---|---|---|
| 1回目 | インライン実装 | 将来の変化が予測できない |
| 2回目 | 将来の統合を意識 | パターンが見え始める |
| 3回目 | 共通化実施 | パターンが確立された |
共通化すべきケース
分離したままにするケース
プロンプトで示されたパスは調査の起点である。別のリポジトリファイルが、受け入れ済みの成果を実装している、必要な依存または配線経路である、あるいは今回影響を受ける契約を保つために変更を要するとエビデンスが示す場合は、そのファイルも変更対象に含める。呼び出し元、利用側、テスト、設定、import、データフローは判断材料であり、必ずすべてを確認するチェックリストではない。
パターン、API、依存を採用する際は、対象機能と、同じ責務・現行契約を共有するリポジトリ内の利用箇所を調べる。その責務で互換性を保っている実装を優先する。使用頻度は候補の発見には役立つが、パターンの正当性を決めるものではない。複数の方式が共存する場合は、呼び出し元、ライフサイクル、互換性から、現行パターンとレガシーまたは無関係な方式を区別する。
外部依存のバージョンは、マニフェスト、ロックファイル、互換性のある利用側から確定する。それらの情報でも互換性またはアーキテクチャに関わる選択を確定できない場合にのみエスカレーションする。
症状: エラーを修正すると新しいエラーが発生 原因: 根本原因を理解せずに表面的な修正 回避方法: 5 Whysで根本原因を特定してから修正
症状: any型やasの多用 原因: 型エラーを回避したい衝動 回避方法: unknown型と型ガードで安全に処理
症状: 実装後にバグ多発 原因: Red-Green-Refactorプロセスの無視 回避方法: 必要な結果が未実装であるため失敗するテストから開始
症状: 新技術導入時の想定外エラー多発 原因: 事前調査なしで「公式ドキュメント通りなら動くはず」 回避方法:
症状: 重複実装、アーキテクチャ不整合、結合時の障害、古いパターンの採用 原因: 実装前の既存コード理解不足、近隣ファイルのみ参照し代表性を確認していない 回避方法:
各回答を観測済みの根拠に結び付け、修正によって元の失敗を防げる原因に到達するまで掘り下げる。各質問、根拠、最終的な因果関係を記録する。次の回答が推測になる時点で止め、必要な根拠を明記する。
型安全の原則: 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段階すべてで必要な証跡を揃える。
未使用コードを検出したら、タスク完了までに現行要件と到達可能な呼び出し経路で使用されるかを確認する。
対象: コード・ドキュメント・設定ファイル
推奨原則: 振る舞いの変更は、必要な理由で失敗するテストから始める
開発ステップ:
直接検証するケース:
推奨: 単体テストでの外部依存モック化
Unit testの境界: 外部接続には決定的な代替を使用する。実際の外部境界は、その契約を対象として選定したIntegration testまたはE2E testで検証する
テストを修正: 間違った期待値、存在しない機能参照、実装詳細への依存、テストのためだけの実装 実装を修正: 妥当な仕様、ビジネスロジック、重要なエッジケース どちらの解釈も入手可能な要件と両立する場合: 未解決の振る舞い判断として差し戻す — 2つの候補となる振る舞い、どちらが正しいかを決める出所、および一方を選ばず停止する条件を示す
観測可能な境界を通じてテストする：公開API、戻り値、例外、外部呼び出し、永続化された状態を検証する。privateメソッド、内部状態、アルゴリズムの詳細は、これらの観測可能な境界を通じてのみ到達する。
references/security-checks.mdを参照