メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | creating-rules |
| description | 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. |
.claude/rules/ ディレクトリにモジュール化された、焦点を絞ったルールを作成する。
まずユーザーに確認する:
.claude/rules/（プロジェクト用）or ~/.claude/rules/（個人用）？次に既存ルールを確認する:
# プロジェクトのルールを確認
ls -la .claude/rules/
# 個人のルールを確認
ls -la ~/.claude/rules/
重複がないことを確認してからルールを作成する。
ルールファイルを作成:
---
paths: src/**/*.ts
---
# TypeScript Guidelines
- strict モードを使用する
- オブジェクト形状には type より interface を優先
- エクスポートされる関数には明示的な戻り値型を指定
ルールを作成する前に必ず確認：
既存ルールの確認
ls .claude/rules/
CLAUDE.md との重複確認
スコープの適切性
全ファイルに適用：
# Code Style
- 2スペースインデントを使用
- let より const を優先
- 未使用変数を残さない
Claude が一致するファイルを扱う時のみ適用：
---
paths: src/api/**/*.ts
---
# API Development Rules
- 全エンドポイントに入力バリデーションを含める
- 標準エラーレスポンス形式を使用
- OpenAPI ドキュメントコメントを含める
paths フィールド単一パターン：
paths: src/**/*.ts
ブレース展開による複数パターン：
paths: src/**/*.{ts,tsx}
カンマ区切りパターン：
paths: {src,lib}/**/*.ts, tests/**/*.test.ts
| パターン | マッチ対象 |
|---|---|
**/*.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
api-validation.md、rules1.md ではない）全部入りファイルの作成
# ✗ Bad - rules.md に全部入れる
# All Rules
## Coding
## Testing
## Deployment
## Security
CLAUDE.md との重複
時間依存の情報
# ✗ Bad
- 2025年1月現在、React 19 の機能を使用
曖昧な記述
# ✗ Bad
- 適切にフォーマットする
- 良い命名を使う
詳細な例は examples.md を参照。
# Code Style
- ESLint/Prettier 設定を使用
- 本番コードに console.log を残さない
- 名前付きエクスポートを優先
- @/ プレフィックスで絶対インポートを使用
---
paths: **/*.test.{ts,tsx}
---
# Testing Standards
- Arrange-Act-Assert パターン
- 外部依存関係をモック
- エッジケースを明示的にテスト
- 新規コードは 80%+ カバレッジを目指す
---
paths: src/api/**/*.ts
---
# API Guidelines
- zod で全入力をバリデーション
- 一貫したエラーフォーマットを返す: { error: string, code: string }
- 全 5xx エラーをログ
- レスポンスにリクエスト ID を含める
# Security Requirements
- 機密データ（パスワード、トークン、PII）をログに残さない
- データベースクエリ前にユーザー入力をサニタイズ
- パラメータ化クエリのみを使用
- ファイルアップロードを検証: タイプ、サイズ、内容
---
paths: src/components/**/*.tsx
---
# React Component Guidelines
- 関数コンポーネント + hooks を優先
- 複雑なロジックはカスタム hooks に抽出
- コストの高いレンダリングには React.memo を使用
- Props インターフェース名: ComponentNameProps
| 項目 | CLAUDE.md | Rules |
|---|---|---|
| 用途 | プロジェクト概要 | 具体的なコーディング規約 |
| スコープ | 全体 | 条件付き（パス指定可） |
| 内容 | ビルドコマンド、アーキテクチャ | ファイルタイプ別ガイドライン |
| 構成 | 単一ファイル | モジュール化された複数ファイル |
Rules を使う場合:
CLAUDE.md を使う場合:
ルール作成前：
Pull Request をグリーンにするスキル。CI チェックの失敗解消と、PR に紐づく Issue の 修正・クローズを一括で実行する。GitHub Actions の CI ログ分析、ローカル CI （`./scripts/ci-check.sh`）の実行、エラーの根本原因特定と修正、PR コメントや リンクされた Issue の解消を含む。解消した Issue は確認後にクローズする。 ループモード（`/loop 5 /pr-green`）にも対応し、自律的に CI 監視・修正・プッシュを繰り返す。 トリガー：「PR をグリーンにして」「CI を通して」「CI エラーを直して」 「PR の issue を解消して」「PR を修正して」「CI が落ちている」「テストが失敗している」 「PR のレビュー指摘を直して」「PR を mergeable にして」 といった PR 修正・CI 解消関連リクエストで起動。PR 番号が指定されなくても、 現在のブランチから自動検出して対応する。
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、集約の分割、真の不変条件
集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存（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はインターフェースアダプタ層に配置すべき という原則を適用する。トリガー：「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。