DDDの集約(Aggregate)設計ルールに基づくコードレビュー・設計支援・リファクタリングを行う。 Evans Rules、Vernon's 4 Rules、Design by Contractに基づき、集約の境界定義、不変条件の検証、 不変(Immutable)設計、ID参照、結果整合性、ドメインイベント連携を包括的にガイドする。 以下のいずれかに該当する場合は必ずこのスキルを使用すること: - 集約(Aggregate)の新規設計・実装・リファクタリング(どの言語でも) - 既存の集約やエンティティクラスのDDD観点でのコードレビュー - 集約の境界決定(「AとBは同じ集約にすべきか?」「この集約は大きすぎるか?」) - 集約内の不変条件・整合性境界の設計 - 集約間の連携方式の判断(ドメインイベント、結果整合性、Sagaパターン) - 可変(Mutable)な集約コードを不変(Immutable)設計にリファクタリングする - publicフィールド、直接参照、push/appendなどカプセル化違反の検出・修正 キーワード例:集約、Aggregate、aggregate boundary、集約ルート、AggregateRoot、 エンティティ設計、DDD実装、Vernon Rules、Evans Rules、集約の分割、真の不変条件
creating-rules
Creates Claude Code rules (.claude/rules/*.md) with YAML frontmatter and path-specific scoping. Use when creating project rules, coding standards, or conditional guidelines for specific file types.
含まれるファイル(3)
- SKILL.md8.0 KB
- .skillfish.json196 B
- references/examples.md5.2 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Creating Claude Code Rules
.claude/rules/ ディレクトリにモジュール化された、焦点を絞ったルールを作成する。
Quick Start
まずユーザーに確認する:
- スコープ: グローバル(全ファイル)or パス指定(特定ファイルタイプ)?
- 配置場所:
.claude/rules/(プロジェクト用)or~/.claude/rules/(個人用)? - カテゴリ: コードスタイル、テスト、セキュリティ、API、その他?
- 対象言語/フレームワーク(該当する場合)?
次に既存ルールを確認する:
# プロジェクトのルールを確認
ls -la .claude/rules/
# 個人のルールを確認
ls -la ~/.claude/rules/
重複がないことを確認してからルールを作成する。
ルールファイルを作成:
---
paths: src/**/*.ts
---
# TypeScript Guidelines
- strict モードを使用する
- オブジェクト形状には type より interface を優先
- エクスポートされる関数には明示的な戻り値型を指定
作成前チェック
ルールを作成する前に必ず確認:
-
既存ルールの確認
ls .claude/rules/- 同じトピックのルールが存在しないか?
- 既存ルールに追記すべき内容ではないか?
-
CLAUDE.md との重複確認
- CLAUDE.md に同様の内容がないか?
- プロジェクト概要 → CLAUDE.md
- 具体的なコーディング規約 → rules/
-
スコープの適切性
- グローバルルールにすべきか、パス指定すべきか?
- 既存のパス指定ルールと競合しないか?
ルールファイル構造
グローバルルール(Frontmatter なし)
全ファイルに適用:
# Code Style
- 2スペースインデントを使用
- let より const を優先
- 未使用変数を残さない
パス指定ルール(Frontmatter あり)
Claude が一致するファイルを扱う時のみ適用:
---
paths: src/api/**/*.ts
---
# API Development Rules
- 全エンドポイントに入力バリデーションを含める
- 標準エラーレスポンス形式を使用
- OpenAPI ドキュメントコメントを含める
YAML Frontmatter
paths フィールド
単一パターン:
paths: src/**/*.ts
ブレース展開による複数パターン:
paths: src/**/*.{ts,tsx}
カンマ区切りパターン:
paths: {src,lib}/**/*.ts, tests/**/*.test.ts
Glob パターンリファレンス
| パターン | マッチ対象 |
|---|---|
**/*.ts | 任意の場所の全 TypeScript ファイル |
src/**/* | src/ 配下の全ファイル |
*.md | プロジェクトルート直下の Markdown ファイルのみ |
src/components/*.tsx | 特定ディレクトリ内の React コンポーネント |
**/*.{ts,tsx} | TypeScript と TSX ファイル |
{src,lib}/**/*.ts | src/ または lib/ 内の TypeScript |
ディレクトリ構成
基本構成
.claude/rules/
├── code-style.md # 一般的なコーディング規約
├── testing.md # テスト規約
└── security.md # セキュリティ要件
サブディレクトリあり
.claude/rules/
├── frontend/
│ ├── react.md
│ └── styles.md
├── backend/
│ ├── api.md
│ └── database.md
└── general.md
全 .md ファイルは再帰的に検出される。
シンボリックリンクによる共有ルール
# 共有ルールディレクトリをシンボリックリンク
ln -s ~/shared-claude-rules .claude/rules/shared
# 個別ファイルをシンボリックリンク
ln -s ~/company-standards/security.md .claude/rules/security.md
ベストプラクティス
MUST(必須)
- 1トピック1ファイルで焦点を絞る
- 説明的なファイル名を使用(
api-validation.md、rules1.mdではない) - 具体的に記述する(「適切にフォーマット」ではなく「2スペースインデント」)
- 既存ルールを確認してから新規作成
ALLOWED(許可)
- サブディレクトリによる整理
- シンボリックリンクによる共有ルールの参照
- 複数の paths パターンの指定
MUST NOT(禁止)
-
全部入りファイルの作成
# ✗ Bad - rules.md に全部入れる # All Rules ## Coding ## Testing ## Deployment ## Security -
CLAUDE.md との重複
- CLAUDE.md: プロジェクト概要、共通コマンド、アーキテクチャ
- Rules: 特定のコーディングガイドライン
-
時間依存の情報
# ✗ Bad - 2025年1月現在、React 19 の機能を使用 -
曖昧な記述
# ✗ Bad - 適切にフォーマットする - 良い命名を使う
一般的なルールカテゴリ
詳細な例は examples.md を参照。
コードスタイル
# Code Style
- ESLint/Prettier 設定を使用
- 本番コードに console.log を残さない
- 名前付きエクスポートを優先
- @/ プレフィックスで絶対インポートを使用
テスト
---
paths: **/*.test.{ts,tsx}
---
# Testing Standards
- Arrange-Act-Assert パターン
- 外部依存関係をモック
- エッジケースを明示的にテスト
- 新規コードは 80%+ カバレッジを目指す
API 開発
---
paths: src/api/**/*.ts
---
# API Guidelines
- zod で全入力をバリデーション
- 一貫したエラーフォーマットを返す: { error: string, code: string }
- 全 5xx エラーをログ
- レスポンスにリクエスト ID を含める
セキュリティ
# Security Requirements
- 機密データ(パスワード、トークン、PII)をログに残さない
- データベースクエリ前にユーザー入力をサニタイズ
- パラメータ化クエリのみを使用
- ファイルアップロードを検証: タイプ、サイズ、内容
React/Frontend
---
paths: src/components/**/*.tsx
---
# React Component Guidelines
- 関数コンポーネント + hooks を優先
- 複雑なロジックはカスタム hooks に抽出
- コストの高いレンダリングには React.memo を使用
- Props インターフェース名: ComponentNameProps
Rules vs CLAUDE.md
| 項目 | CLAUDE.md | Rules |
|---|---|---|
| 用途 | プロジェクト概要 | 具体的なコーディング規約 |
| スコープ | 全体 | 条件付き(パス指定可) |
| 内容 | ビルドコマンド、アーキテクチャ | ファイルタイプ別ガイドライン |
| 構成 | 単一ファイル | モジュール化された複数ファイル |
Rules を使う場合:
- ガイドラインが特定のファイルタイプやパスに適用される
- 単一トピックに焦点を当てた内容
- チームがモジュール化された整理を望む
CLAUDE.md を使う場合:
- 一般的なプロジェクト情報が全ファイルに適用される
- ビルド/テスト/lint コマンドが頻繁に必要
- アーキテクチャ概要が必要
最終チェックリスト
ルール作成前:
- 既存ルールを確認した(重複なし)
- CLAUDE.md との重複を確認した
- 明確で焦点を絞ったトピックを特定した
- 適切なスコープを選択した(グローバル or パス指定)
- 説明的なファイル名を使用した
- 内容を具体的かつ実行可能にした
- パス指定の場合、glob パターンをテストした
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存(Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて)。 トリガー:「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」 「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」 「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」 といったトランザクション境界関連リクエストで起動。
後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル(deprecation cycle)の 制度化、互換層の局所化(Adapter/Strangler Fig)、契約テスト(CDC)による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存(Java, TypeScript, Go, Python, Rust等すべて)。 トリガー:「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。
getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合(永続化、JSON変換など)に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。 これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。 コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。 トリガー:「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」 「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。
クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造(ドメイン層、 ユースケース層、インターフェースアダプタ層、インフラストラクチャ層)に基づく。特にインフラ層は 横断的関心事(ロギング、設定管理)のみ、永続化やRPCはインターフェースアダプタ層に配置すべき という原則を適用する。トリガー:「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。
CQRS/ESが集約の境界定義とモデリングに与える影響を解説する。CQRSを導入すると集約は コマンド実行に必要な最小限の状態のみ保持すればよくなり、読み取り責務はリードモデルに 委譲できる。大きすぎる集約の軽量化、集約境界の再定義、イベントによる状態管理を支援する。 集約設計、CQRS導入時のモデリング見直し、パフォーマンス問題の解決時に使用。 対象言語: 言語非依存。 トリガー:「CQRSで集約が変わる」「集約が大きすぎる」「集約にメッセージ1000件」 「集約の更新が重い」「CQRS導入で集約を見直す」「集約を軽量化したい」 「集約にクエリ用データが混ざっている」「集約の境界を再定義」 といったCQRS/モデリング関連リクエストで起動。