best-practices
このスキルは、ユーザーが「TDD」「テスト駆動開発」「FSD」「Feature-Sliced Design」「Clean Architecture」「DDD」「ドメイン駆動設計」「リファクタリング」「
by tadokoro-ryusuke|Open Source
Dev Core Best Practices
全エージェントの共通基盤。コーディング規約・原則・パターンの Single Source of Truth。
このファイルにはコア原則のみを置く。詳細が必要になったら、該当する references/ のファイルを読むこと。不要な参照ファイルを先読みしない。
| 参照ファイル | 内容 | 読むタイミング |
|---|---|---|
| references/coding-standards.md | 命名規約、コードスタイル、TypeScript 規約、Git 規約、リファクタリング技法 | コードを書く・直す・コミットする前 |
| references/architecture.md | FSD レイヤー構造、Clean Architecture、DDD（エンティティ/VO/集約） | 設計判断・ファイル配置・ドメインモデリング時 |
| references/security.md | OWASP Top 10 チェックリスト、入力検証、機密情報保護、金融システム要件 | セキュリティレビュー・API/認証実装時 |
1. TDD サイクル（t-wada 式）— Red→Green→Refactor→Evidence
- Red 🔴: 単一機能の失敗するテストを1つ作成。実装は存在しないため必ず失敗する
- Green 🟢: テストをパスさせる最小限のコードを記述。余分な機能は追加しない
- Refactor 🔨: テストをグリーンに保ちながら品質向上。重複排除、命名改善、複雑さの解消
- Evidence ✅: focused verification を実行して結果を記録。commit はユーザーまたは delivery workflow が明示的に許可した場合だけ、意味のある単位で行う
Iron Law: テストなしのプロダクションコードは存在してはならない。 検証コマンドを実行せずに「パス」を宣言することも禁止（証拠ベース完了判定の詳細は verify スキル参照）。
2. SOLID 原則
- SRP: 1モジュール/クラス/関数 = 1つの責任。変更理由は1つだけ
- OCP: 拡張に開き、修正に閉じる。新機能は既存コード変更なしで追加
- LSP: 派生型は基底型と置換可能
- ISP: 使わないメソッドへの依存を強制しない
- DIP: 高レベルモジュールは低レベルに依存しない。抽象に依存する
3. 普遍のコア規約
- ハードコーディング禁止: マジックナンバーは定数化、設定値は環境変数/設定ファイル、UI 文字列は定数/言語ファイル
- DRY: コード重複は即座に排除
- 早期リターン/ガード節: 深いネストを避ける
- イミュータビリティ: 直接変更ではなくコピーで更新
- サイズ上限: ファイル 200-400 行推奨（500 行超で分割検討）、関数 50 行以下
4. プロジェクト固有設定
技術スタック・コマンド・閾値（カバレッジ等）はプロジェクトの .claude/dev-core.local.md を正とする。このスキルの原則と矛盾する場合はプロジェクト設定が優先。