本文へ移動
cccskills
無料GitHub で公開

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

まずユーザーに確認する:

  1. スコープ: グローバル(全ファイル)or パス指定(特定ファイルタイプ)?
  2. 配置場所: .claude/rules/(プロジェクト用)or ~/.claude/rules/(個人用)?
  3. カテゴリ: コードスタイル、テスト、セキュリティ、API、その他?
  4. 対象言語/フレームワーク(該当する場合)?

次に既存ルールを確認する:

# プロジェクトのルールを確認
ls -la .claude/rules/

# 個人のルールを確認
ls -la ~/.claude/rules/

重複がないことを確認してからルールを作成する。

ルールファイルを作成:

---
paths: src/**/*.ts
---

# TypeScript Guidelines

- strict モードを使用する
- オブジェクト形状には type より interface を優先
- エクスポートされる関数には明示的な戻り値型を指定

作成前チェック

ルールを作成する前に必ず確認:

  1. 既存ルールの確認

    ls .claude/rules/
    
    • 同じトピックのルールが存在しないか?
    • 既存ルールに追記すべき内容ではないか?
  2. CLAUDE.md との重複確認

    • CLAUDE.md に同様の内容がないか?
    • プロジェクト概要 → CLAUDE.md
    • 具体的なコーディング規約 → rules/
  3. スコープの適切性

    • グローバルルールにすべきか、パス指定すべきか?
    • 既存のパス指定ルールと競合しないか?

ルールファイル構造

グローバルルール(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}/**/*.tssrc/ または 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.mdRules
用途プロジェクト概要具体的なコーディング規約
スコープ全体条件付き(パス指定可)
内容ビルドコマンド、アーキテクチャファイルタイプ別ガイドライン
構成単一ファイルモジュール化された複数ファイル

Rules を使う場合:

  • ガイドラインが特定のファイルタイプやパスに適用される
  • 単一トピックに焦点を当てた内容
  • チームがモジュール化された整理を望む

CLAUDE.md を使う場合:

  • 一般的なプロジェクト情報が全ファイルに適用される
  • ビルド/テスト/lint コマンドが頻繁に必要
  • アーキテクチャ概要が必要

最終チェックリスト

ルール作成前:

  • 既存ルールを確認した(重複なし)
  • CLAUDE.md との重複を確認した
  • 明確で焦点を絞ったトピックを特定した
  • 適切なスコープを選択した(グローバル or パス指定)
  • 説明的なファイル名を使用した
  • 内容を具体的かつ実行可能にした
  • パス指定の場合、glob パターンをテストした

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

aggregate-design

無料日本語概要

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、集約の分割、真の不変条件

j5ik2o/okite-ai802026年4月25日 更新

aggregate-transaction-boundary

無料日本語概要

集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存(Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて)。 トリガー:「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」 「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」 「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」 といったトランザクション境界関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

backward-compat-governance

無料日本語概要

後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル(deprecation cycle)の 制度化、互換層の局所化(Adapter/Strangler Fig)、契約テスト(CDC)による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存(Java, TypeScript, Go, Python, Rust等すべて)。 トリガー:「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

breach-encapsulation-naming

無料日本語概要

getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合(永続化、JSON変換など)に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。 これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。 コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。 トリガー:「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」 「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

clean-architecture

無料日本語概要

クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造(ドメイン層、 ユースケース層、インターフェースアダプタ層、インフラストラクチャ層)に基づく。特にインフラ層は 横断的関心事(ロギング、設定管理)のみ、永続化やRPCはインターフェースアダプタ層に配置すべき という原則を適用する。トリガー:「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。

j5ik2o/okite-ai802026年4月25日 更新

cqrs-aggregate-modeling

無料日本語概要

CQRS/ESが集約の境界定義とモデリングに与える影響を解説する。CQRSを導入すると集約は コマンド実行に必要な最小限の状態のみ保持すればよくなり、読み取り責務はリードモデルに 委譲できる。大きすぎる集約の軽量化、集約境界の再定義、イベントによる状態管理を支援する。 集約設計、CQRS導入時のモデリング見直し、パフォーマンス問題の解決時に使用。 対象言語: 言語非依存。 トリガー:「CQRSで集約が変わる」「集約が大きすぎる」「集約にメッセージ1000件」 「集約の更新が重い」「CQRS導入で集約を見直す」「集約を軽量化したい」 「集約にクエリ用データが混ざっている」「集約の境界を再定義」 といったCQRS/モデリング関連リクエストで起動。

j5ik2o/okite-ai802026年4月25日 更新

j5ik2o のスキルをすべて見る

このスキルの問題を報告する