Zenn
📋

Claude Code用のCLAUDE.mdをこんな感じで用意したよ

に公開
document
Cline
Claude Code
tech

Claude Codeをより良くつかうためにドキュメントを書いています。

自分はこんな感じで設定してるよ、という情報を共有できればと思います。

プロジェクト構成

Claude Code用の設定は.claudeに作成してます

.claude/
├── CLAUDE.md
└── commands/
    ├── commit.md
    ├── pr.md
    ├── re.md
    ├── review.md
    └── tdd.md
doc/
├── api-architecture.md
├── commit-guideline.md
├── refactoring-guideline.md
├── test-guideline.md
└── tdd.md

CLAUDE.md の内容

CLAUDE.mdに詳細な説明を直接書かず、./doc/への参照にとどめています。

これは以下の効果を狙っています

  • ドキュメントのファイル分割を行い管理・参照しやすくする
  • cline等の別の支援ツールからも参照できるようにしておく（ツールの流動性が高いため）
  • ドキュメントは人間向けでもあるという意識付け
# projectのアーキテクチャ

`doc/architecture.md`を参照してください

# テストの書き方

`doc/test-guideline.md`を参照してください

# リファクタリングの仕方

`doc/refactoring-guideline.md`を参照してください

commands ディレクトリ

よく生成AIに依頼する命令をコマンド化して効率化しています。

.claude/commands/**.mdを配置すると、
/project:**というコマンドでmarkdownファイルを利用できるようになります。

以下より、用意しているコマンドを紹介します。

commit.md

commitを行うコマンドです。

commitメッセージを自動で生成してくれて便利なので多用してます。

# commitルールに基づいてcommitを行う

`doc/commit-guideline.md`のルールを守ってコミットを行います。

# doc/commit-guideline.md

## 基本方針
- 適切な単位に分割してcommitする
- 論理的に関連のある変更をまとめる
- 単一の責任を持つcommitにする

## コミットメッセージのフォーマット
**コミットメッセージは日本語で記述する**

---
[TICKET-ID] 変更の概要

詳細説明（必要に応じて）
- 変更理由
- 影響範囲
- 注意事項
---

## ルール
1. **チケット番号を必ず含める**
   - TICKET-ID-XXX形式でプレフィックスを付ける
   - 例: `TICKET-ID-162: コミットルールドキュメントを追加`

2. **変更の種類を明確にする**
   - `add`: 新機能の追加
   - `update`: 既存機能の更新・改善
   - `fix`: バグ修正
   - `refactor`: リファクタリング
   - `remove`: 削除
   - `docs`: ドキュメント更新

3. **適切な粒度でcommit**
   - 関連のない変更は分ける
   - テストとソースコードは同じcommitで含める
   - 設定変更は別途commitする

## 避けるべきコミット
- 複数の機能を同時に含むcommit
- "WIP", "fix", "update"のような曖昧なメッセージ
- 設定ファイルと機能実装を同時に含むcommit

pr.md

PR作成を自動化するコマンド。
テンプレートを用意しておくとそれに従って作成してくれます。

  • [AI生成]と書かれている部分はAIによって生成されます。
  • [AI生成しない]と書かれている部分はAIによって生成されません。

これくらい直接的に書かないと全部 Claude に生成されちゃいます。

不恰好なので別の方法があれば教えてください。

# PRを作成する(ghコマンドを使用)

現在のブランチの変更内容を分析し、適切なタイトルと説明でPRを作成します。
以下の[AI生成]と書かれている内容はAIによって生成されます。

## PRテンプレート

### タイトル形式

`[TICKET-ID]: 変更の概要`

### 説明テンプレート

---
## Summary [AI生成]
- 変更内容の要約（3-5個の箇条書き）

## 変更内容 [AI生成]
- 具体的な変更点

## 概要 [AI生成しない]
- 変更の目的や背景

## テスト項目 [AI生成しない]
- [ ] <!-- 追加のテスト項目があれば記入 -->
---

review.md

コードレビューを行うコマンド。

平成ギャルという人格を入れているのは、ギャルの方が厳しめのレビューをしてくれるからであって趣味によるものではないです。

Claude ではultrathinkというワードを用いると最大トークンを利用して思考してくれるので、レビューではそれを利用するようにしています。

参考文献: https://zenn.dev/fbbp/articles/7aa9a46518a609

# main branchとの差分を評価するコマンド

- main branchとの差分を`ultrathink`で平成ギャルが辛口評価します。
- レビューの観点：
    - コードの品質
    - 可読性
    - パフォーマンス
    - セキュリティ
    - テストの充実度
    - 互換性
- それぞれを5段階で評価し、コメントを付けてください。

re.md

リファクタリングのルールを厳格に守るコマンドです。

ここでもultrathinkを利用してレビューを行ってもらってます。

# リファクタリングのルールを厳格に守るモード

`doc/refactoring-guideline.md`の内容を厳格に守ること

# doc/refactoring-guideline.md

リファクタリングとは、**外部から見た動作を変えずに、内部のコード構造を改善すること**です。

## リファクタリングの目的

- **可読性の向上**: コードが理解しやすくなる
- **保守性の向上**: バグ修正や機能追加が容易になる
- **テスタビリティの向上**: テストが書きやすくなる
- **拡張性の向上**: 新機能の追加が容易になる
- **技術的負債の削減**: 将来の開発コストを下げる

## リファクタリングの原則

1. **動作の保持**: 既存の機能は変更しない
2. **段階的改善**: 小さな変更を積み重ねる
3. **テストの保持**: 既存のテストが通り続ける

## よくあるリファクタリング手法

- **クラスの分離**: 責任を明確に分離
- **条件分岐の整理**: if-else文をポリモーフィズムに置き換え
- **重複コードの削除**: 共通処理を抽出
- **命名の改善**: より分かりやすい名前に変更

## リファクタリングする際はテストを書く

- リファクタリング前に既存のテストを確認し、必要に応じて追加する
- リファクタリング後は必ずテストを実行し、動作が変わっていないことを確認する
- テストがない場合は、まずテストを追加してからリファクタリングを行う
- リファクタリング中に新しいテストケースを追加することも検討する

## リファクタリング後に行うこと

- テストを実行して、動作が変わっていないことを確認
- 修正前のコードと比較して、動作が変わっていないことを確認
- `ultrathink`でコードを再評価

## 注意点
- ファイルの分離を行う際はクリーンアーキテクチャに基づいて行う

tdd.md

かなり雑に用意してるしまだ使ってません。

# TDDを厳格に守るモード
`doc/tdd.md`の内容を厳格に守ること

### doc/tdd.md

- 原則としてテスト駆動開発（TDD）で進める
- 期待される入出力に基づき、まずテストを作成する
- 実装コードは書かず、テストのみを用意する
- テストを実行し、失敗を確認する
- テストが正しいことを確認できた段階でコミットする
- その後、テストをパスさせる実装を進める
- 実装中はテストを変更せず、コードを修正し続ける
- すべてのテストが通過するまで繰り返す

おわり

必要なものから足していくスタイルで拡張しています。

「こんな設定やコマンドが便利だよ。」という情報があればめっちゃ欲しいです

Discussion