---
name: my-rules-creator
license: MIT
description: |
  Claude Code のルールファイル（.claude/rules/*.md）を生成・一覧・編集・削除するスキル。
  ユーザーのコーディング規約・命名規則・テスト方針・セキュリティポリシー・行動ガイドラインなどを受け取り、
  グローバルまたはパス固有（paths frontmatter）のルールファイルとして構造化する。
  「ルールを作って」「コーディング規約を追加」「この方針をルールにして」「セキュリティルール」など、
  .claude/rules/ への作成・管理依頼があったときに使う。
  会話の中で繰り返し出てくるコーディング方針や修正指示も「ルールにしますか？」と提案してよい。
compatibility: |
  - ファイルシステム操作（Read / Write / Edit / Glob / Grep）
  - 特別な外部依存なし
---

# Rules Creator — .claude/rules/ のルール生成・管理

## Overview

`.claude/rules/` に置くルールファイルは、Claude Code が毎セッション読み込む行動指示である。
このスキルは、ユーザーの要望を構造化されたルールファイルに変換し、適切なスコープで配置する。

ルールには2種類ある:

| 種類           | frontmatter             | 読み込みタイミング                   |
| -------------- | ----------------------- | ------------------------------------ |
| **グローバル** | なし、または paths なし | セッション開始時に常に読み込まれる   |
| **パス固有**   | `paths` フィールドあり  | 該当パターンのファイル操作時のみ適用 |

パス固有ルールは、Claude がそのパターンに一致するファイルを読み書きするときだけコンテキストに入るため、
無関係な作業のノイズにならない。対象が明確なルールはパス固有にする方がコンテキスト効率がよい。

## 入力パラメータ

- **`$1`**: 操作（`create` / `list` / `edit` / `delete`）— 省略時は会話から推定
- **`$2`**: ルール名またはファイル名 — 編集・削除時に使う

## Workflow

### Step 1: 操作を判定する

| ユーザーの意図                 | 操作     |
| ------------------------------ | -------- |
| 新しいルールを追加・作成したい | `create` |
| 既存ルールの一覧を見たい       | `list`   |
| 既存ルールを修正・更新したい   | `edit`   |
| 不要なルールを削除したい       | `delete` |

曖昧な場合はユーザーに確認する。「ルールにして」「ルール追加」は `create` と判定してよい。

### Step 2: 操作ごとのフロー

---

#### create: ルールを新規作成する

##### 2a. 要件をヒアリングする

以下を把握する。足りなければ質問する。

1. **何についてのルールか** — コーディング規約、命名規則、テスト方針、セキュリティ、ワークフローなど
2. **対象スコープ** — プロジェクト全体か、特定のディレクトリ・ファイルタイプか
3. **具体的な指示内容** — やること / やらないこと / 判断基準

##### 2b. スコープを決定する

| 条件                                                     | スコープ               |
| -------------------------------------------------------- | ---------------------- |
| プロジェクト全体に適用する汎用的なルール                 | グローバル             |
| ユーザーが明示的にディレクトリやファイルタイプを指定した | パス固有               |
| **上記のどちらか判断がつかない場合**                     | **ユーザーに確認する** |

スコープ判断で重要なこと: ユーザーが「〇〇のルール」とだけ言った場合、それがプロジェクト全体の方針なのか特定ファイルだけの話なのかは分からない。**自分で推測してパス固有にせず、必ずユーザーに聞く。** 「プロジェクト全体に適用しますか？ それとも特定のファイル（例: `**/*.test.ts`）だけに限定しますか？」のように選択肢を提示する。

パス固有の場合、`paths` の glob パターンを決める。よく使うパターン:

| パターン例                  | 意味                             |
| --------------------------- | -------------------------------- |
| `"src/**/*.ts"`             | src 配下の全 TypeScript ファイル |
| `"src/**/*.{ts,tsx}"`       | TypeScript + TSX                 |
| `"tests/**/*.test.*"`       | テストファイル全般               |
| `"src/api/**/*"`            | API ディレクトリ配下すべて       |
| `"*.md"`                    | ルート直下の Markdown            |
| `"**/*.md"`                 | 全階層の Markdown                |
| `"src/components/**/*.tsx"` | コンポーネントディレクトリの TSX |

ブレース展開（`{ts,tsx}`）で複数拡張子をまとめられる。

##### 2c. ファイル名を決める

命名規則: `<topic>.md`（kebab-case）

例: `code-style.md`, `testing.md`, `security.md`, `api-conventions.md`, `react-components.md`

既存ファイルとの重複を Glob で確認してから決める。

##### 2d. ルールファイルを生成する

**グローバルルールのテンプレート:**

```markdown
# <ルールタイトル>

<指示内容を簡潔に記述>
```

**パス固有ルールのテンプレート:**

```markdown
---
paths:
  - '<glob パターン>'
---

# <ルールタイトル>

<指示内容を簡潔に記述>
```

##### ルールの書き方ガイド

効果的なルールを書くためのポイント:

- **簡潔に書く** — 1ルールファイルあたり50行以下を目安にする。長すぎるとコンテキストを圧迫する
- **具体的に書く** — 「きれいなコードを書く」ではなく「関数は30行以下にする」のように定量化する
- **理由を添える** — なぜそのルールが必要かを1行で書くと、Claude が意図を汲んで柔軟に適用できる
- **DO / DON'T 形式** — 「やること」と「やらないこと」を明示すると判断しやすい
- **例を入れる** — 良い例・悪い例があると精度が上がる。短くてよい
- **命令形で書く** — 「〜してください」より「〜する」「〜を使う」の方が指示として明確

**良いルールの例:**

```markdown
# テスト規約

- テストファイルは対象ファイルと同じディレクトリに `*.test.ts` で置く
- describe ブロックはクラス名またはモジュール名で始める
- モックは最小限にし、外部 API 呼び出しのみモックする（DB はテスト用インスタンスを使う）
- テスト名は「何をしたら何が起きるか」の形式にする（例: "returns 404 when user not found"）
```

##### 2e. 確認して保存する

生成したルールの内容をユーザーに提示し、確認を得てから `.claude/rules/<filename>.md` に保存する。

---

#### list: 既存ルールを一覧表示する

`.claude/rules/` 内のファイルを Glob で取得し、以下の形式で表示する:

| ファイル名      | スコープ     | 概要（先頭数行）     |
| --------------- | ------------ | -------------------- |
| `code-style.md` | グローバル   | コードスタイルガイド |
| `api-rules.md`  | `src/api/**` | API 開発ルール       |

frontmatter の `paths` フィールドの有無でスコープを判定する。

---

#### edit: 既存ルールを編集する

1. 対象ファイルを特定する（名前指定 or 一覧から選択）
2. 現在の内容を Read で読む
3. ユーザーの修正要望を聞く
4. Edit ツールで変更を適用する
5. 変更後の内容を提示して確認する

---

#### delete: ルールを削除する

1. 対象ファイルを特定する
2. 内容を表示して確認を求める
3. 確認後、Bash で `rm` する

削除は取り消せないため、必ず確認を取る。

---

## 会話中のルール提案

会話の中でユーザーが繰り返し同じコーディング方針や修正指示を出している場合、
「この方針をルールとして `.claude/rules/` に保存しますか？」と提案してよい。
これにより、次回以降のセッションで Claude が自動的にその方針に従うようになる。

提案する場面の例:

- 「テストは必ず書いて」と複数回言っている
- 特定のライブラリの使い方を毎回指示している
- コードスタイルの修正を繰り返している

## Error handling

- 同名ファイルが既に存在する → 上書きか別名かをユーザーに確認
- paths の glob パターンが不正 → 正しいパターン例を提示して修正
- `.claude/rules/` ディレクトリが存在しない → 作成してから進める
- ルールの内容が長すぎる（50行超） → 分割を提案する

## Tips

- 1つのルールファイルに1つのテーマ。「全部入り」にしない
- ルールの効果は次のセッションから反映される（現セッションでも paths なしルールは即座に読み込まれる可能性がある）
- シンボリックリンクで他プロジェクトとルールを共有できる
- ルールは CLAUDE.md と同じ優先度で読み込まれる。矛盾がないよう注意する

## References

- ルールの配置先: `.claude/skills/paths.md` の `RULES` キー
- Claude Code ドキュメント: ルールの仕組みと paths frontmatter の詳細