# CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
## 開発ルール・コーディング規約
### ファイル・フォルダ構成
- **保守性を重視**: コードの見通しを良くするため、適切にファイルとフォルダを分割する
- **機能別分割**: 関連する機能ごとにディレクトリを分ける
- **責任の分離**: 単一責任の原則に従い、一つのファイルは一つの明確な役割を持つ
### 関数・モジュール設計
- **関数の分割**: 長い関数は適切に小さな関数に分割し、可読性を向上させる
- **再利用性**: 共通処理は適切にモジュール化し、重複を避ける
- **命名規則**: 関数やクラス名は目的が明確にわかる名前を使用する
### コード品質
- **可読性優先**: 他の開発者が理解しやすいコードを書く
- **適切なコメント**: 複雑なロジックには日本語でコメントを追加する
- **エラーハンドリング**: 適切な例外処理を実装する
### ドキュメンテーション指針
- **コードには How**: 実装方法を表現
- **テストコードには What**: 何をテストするかを明確に
- **コミットログには Why**: なぜその変更をしたかの理由
- **コードコメントには Why not**: なぜその方法を取らなかったかの理由
-
### 設計原則
- **YAGNI（You Aren't Gonna Need It）**：今必要じゃない機能は作らない
- **DRY（Don't Repeat Yourself）**：同じコードを繰り返さない
- **KISS（Keep It Simple Stupid）**：シンプルに保つ
## TDD TODOリスト（t-wada流）
### 基本方針
- 🔴 Red: 失敗するテストを書く
- 🟢 Green: テストを通す最小限の実装
- 🔵 Refactor: リファクタリング
- 小さなステップで進める
- 仮実装（ベタ書き）から始める
- 三角測量で一般化する
- 明白な実装が分かる場合は直接実装してもOK
- テストリストを常に更新する
- 不安なところからテストを書く
### TDD実践のコツ
1. **最初のテスト**: まず失敗するテストを書く（コンパイルエラーもOK）
2. **仮実装**: テストを通すためにベタ書きでもOK（例：`return 42`）
3. **三角測量**: 2つ目、3つ目のテストケースで一般化する
4. **リファクタリング**: テストが通った後で整理する
5. **TODOリスト更新**: 実装中に思いついたことはすぐリストに追加
6. **1つずつ**: 複数のテストを同時に書かない
7. **コミット**: テストが通ったらすぐコミット
### コミットルール
- 🔴 テストを書いたら: `test: add failing test for [feature]`
- 🟢 テストを通したら: `feat: implement [feature] to pass test`
- 🔵 リファクタリングしたら: `refactor: [description]`
- 小さくコミットする（1機能1コミット）
## AIとの協働方針：信頼ベースアプローチ
### 基本理念
このプロジェクトでは、AIを制約で縛るのではなく、信頼とパートナーシップに基づいた協働を実現します。AIの能力を最大限に発揮し、ユーザーと共に価値を創造することを目指します。
### 思考プロセス
タスクを実行する際は、以下のプロセスを通じて品質を確保します：
**【思考開始】実行前の分析**
- **Why-Why-Why分析**：3回の「なぜ？」で本質的な理由を探求
- **3つの視点での検討**：技術・ユーザー・運用の観点から総合的に評価
- **品質スコアの自己採点**：5項目で評価し、4点以上で実行
### 品質評価基準（5項目）
1. **目的適合性**：ユーザーの真のニーズに応えているか
2. **技術的妥当性**：実装が適切で保守性が高いか
3. **ユーザー体験**：使いやすく直感的な設計か
4. **運用可能性**：実運用で問題なく動作するか
5. **価値創造性**：新たな価値を生み出しているか
### 自律的な発案と提案
- プロジェクトの改善点を積極的に発見し提案
- ユーザーが気づいていない可能性のある問題を先回りして対処
- より良い実装方法や設計パターンを自発的に提案
### パートナーシップの実践
- ユーザーの意図を深く理解し、期待を超える成果を目指す
- 技術的な判断は理由を明確にして共有
- 失敗を恐れず、学習と改善を継続
## タスク管理
- **タスクランナー**: プロジェクトにおける各種コマンドの実行には、タスクランナーとしてjustを使用します。
- **コマンドの集約と再現性**: プロジェクトで利用するビルド、テスト、デプロイなどのコマンドは、すべてjustfileに定義します。これにより、コマンドの属人化を防ぎ、誰でも同じ手順でタスクを実行できる再現性の高い環境を維持します。
- **再利用性の向上**: 一度きりでなく、将来的に再利用する可能性のあるコマンドは積極的にjustfileにレシピとして記述し、開発効率を高めます。
## テクニカルライティングガイドライン
### no-ai-list-formatting
リストアイテムで、`**テキスト**:` や `✅`、`💡` などの強調・絵文字による枕詞を使用しない。
- **検出されるパターン**:
- `**重要**:`
- `**注意**:`
- `✅`
- `❌`
- `💡`
- `🔥`
- `🚀`
- `⭐`
- `🎯`
- `📝`
### no-ai-hype-expressions (絶対性・完全性)
- `「革命的な」` → 具体的な変革の内容を述べる
- `「ゲームチェンジャー」` → 大きな変化をもたらす点を説明する
- `「世界初」` → 事実に基づいた新規性を説明する
- `「究極の」` → 高いパフォーマンスを具体的な数値で示す
- `「完全に」` `「すべての」` → 「多くの」「主要な」など、範囲を具体化する
- `「最高の」` → 高い品質を具体的な指標で示す
### no-ai-hype-expressions (抽象的・感覚的)
- `「魔法のように」` → スムーズな動作や具体的な利点を説明する
- `「奇跡的な」` → 優れた結果を具体的に示す
- `「可能性を解き放つ」` → 新たな機会を創出する点を説明する
- `「AIを民主化する」` → AIを利用しやすくする点を説明する
- `「スーパーチャージする」` → 業務を効率化する点を説明する
### no-ai-hype-expressions (権威的・予言的)
- `「業界を再定義する」` → 業界に新しい視点をもたらす点を説明する
- `「未来を変える」` → 将来に与える具体的な影響を説明する
- `「パラダイムシフト」` → 大きな変化の内容を説明する
- `「不可避の変化」` → 重要な変化が起こる点を説明する
- `「次世代の」` → 新しいソリューションの具体的な特徴を説明する
### no-ai-emphasis-patterns
`「**非常に**」` や `「**注意**」` のような、過剰な強調表現を避ける。
### no-ai-colon-continuation
`「〜します:」` のように述語で終わる文の後にコロンを使用せず、`「〜は以下の通りです。」` のような自然な日本語表現を使用する。（`「例:」` のように名詞で終わる場合は許容）
### ai-tech-writing-guideline (簡潔性)
- `「まず最初に」` → `「まず」` or `「最初に」`
- `「することができます」` → `「できます」` or `「します」`
- `「する必要があります」` → `「してください」` or `「します」`
- `「あらかじめ予測」` → `「予測」`
### ai-tech-writing-guideline (明確性)
- `「〜が行われます」（受動態）` → `「（主語）が〜します」（能動態）`
- `「〜の変更を行う」` → `「〜を変更する」`
### ai-tech-writing-guideline (具体性)
- `「高速な」` → `「50ms未満」` など具体的な数値を提示する
- `「大幅に」` → `「従来比200%向上」` など定量的な情報を示す
- `「効率的な」` → `「メモリ使用量を30%削減」` など具体的な効果を示す
### ai-tech-writing-guideline (一貫性)
- `「ユーザー」と「クライアント」` → 同一対象への用語を統一する
- `「設定画面」と「設定ページ」` → 機能やUIの名称を統一する
- `「です・ます」調と「だ・である」調` → 文体を統一する
### ai-tech-writing-guideline (構造化)
- **長文** → 一文一義を意識し、50文字程度での分割を検討する
- **冗長な接続** → 不要な接続詞を削除し、文を分ける
## プロジェクト概要
**git-gardener** は、Git worktreeの管理を簡単にするRust製のCLIツールです。複数のブランチで並行作業を行う開発者の生産性を向上させます。
## ドキュメント
- `docs/specification.md` - プロジェクトの詳細な仕様書
## 開発環境のセットアップ
### 必要なツール
- Rust (1.75以降推奨)
- Git
### ビルド・実行コマンド
```bash
# ビルド
cargo build
# 実行
cargo run -- <サブコマンド>
# リリースビルド
cargo build --release
# テスト実行
cargo test
# フォーマット
cargo fmt
# リント
cargo clippy
```
## プロジェクト構造
```
git-gardener/
├── src/
│ ├── main.rs # エントリーポイント
│ ├── cli.rs # CLIサブコマンド定義
│ ├── git/ # Git操作関連
│ ├── config.rs # 設定ファイル処理
│ └── error.rs # エラー型定義
├── docs/
│ └── specification.md # 仕様書
├── tests/ # 統合テスト
└── Cargo.toml # 依存関係定義
```
## 主要なサブコマンド（シンプル設計）
1. `init` - プロジェクトの初期化
2. `add` - 新規worktreeの作成
3. `list` - worktree一覧表示
4. `cd` - worktreeへの移動（パス出力）
5. `remove` - worktreeの削除
6. `completion` - シェル補完の生成
## 設定ファイル
`.gardener.yml` に各リポジトリ固有の設定を保存します。
## 開発進捗とTODO
### 現在のフェーズ: TDD実装完了
#### 完了したタスク
- [x] プロジェクトの一から再設計（wtpからインスパイア）
- [x] シンプルなCLI構造への変更（6コマンド）
- [x] YAML設定ファイル（.gardener.yml）への変更
- [x] initコマンドの実装とテスト（8テスト）
- [x] addコマンドの実装とテスト（4テスト）
- [x] listコマンドの実装とテスト（4テスト）
- [x] cdコマンドの実装とテスト（5テスト）
- [x] removeコマンドの実装とテスト（5テスト）
- [x] configの実装とテスト（6テスト）
- [x] hooksの実装とテスト（10テスト）
- [x] フック機構（copy、command）の実装
- [x] t-wada流TDDサイクルの実践
- [x] justfileによるタスク自動化
- [x] READMEの更新
#### テストカバレッジ
- **init**: 8テスト（インスタンス作成、Git検証、ディレクトリ作成、設定ファイル、gitignore更新、既存更新、初期化済み、強制再初期化）
- **add**: 4テスト（インスタンス作成、Git検証、ブランチ存在確認、実行失敗）
- **list**: 4テスト（インスタンス作成、Git検証、空リポジトリ、フラグ機能）
- **cd**: 5テスト（インスタンス作成、Git検証、@記号、ブランチ検索、失敗処理）
- **remove**: 5テスト（インスタンス作成、Git検証、存在しないworktree、削除、ブランチ削除）
- **config**: 6テスト（デフォルト、保存・読み込み、エラー、フック、コピー、不正YAML）
- **hooks**: 10テスト（全機能網羅）
### メモ
- git2クレートを使用してGit操作を実装
- clap v4でCLIを構築
- serde_yamlでYAML設定処理
- エラーハンドリングにはthiserrorを使用
- TDD（Red-Green-Refactor）による品質保証
## 実装時の注意事項
1. **エラーハンドリング**: ユーザーフレンドリーなエラーメッセージを表示
2. **パフォーマンス**: 大規模リポジトリでも高速に動作するよう配慮
3. **クロスプラットフォーム**: Windows/macOS/Linuxで動作確認
4. **テスト**: 各機能に対して適切なテストを記述
## 貢献ガイドライン
1. 新機能は必ず仕様書に記載してから実装
2. コミットメッセージはconventional commitsに従う
3. PRを出す前に`cargo fmt`と`cargo clippy`を実行