.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

# projectのアーキテクチャ

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

# テストの書き方

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

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

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

# 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を作成する(ghコマンドを使用)

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

## PRテンプレート

### タイトル形式

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

### 説明テンプレート

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

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

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

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

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

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

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

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

# doc/refactoring-guideline.md

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

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

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

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

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

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

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

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

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

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

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

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

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

### doc/tdd.md

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