tuning

Tuning

ユーザーの要望を適切な設定ファイルに反映し、Claude の振る舞いを調整する。

ワークフロー

1. フィードバックを理解する

ユーザーの要望を「何が」「どう変わるべきか」として言語化する。

• 曖昧なフィードバックは具体的なシナリオで確認する
• 「いつ」「どの場面で」その振る舞いを期待するか特定する
• 既に同じ問題を別の言い方で伝えていないか文脈を確認する

2. 現状を調査する

変更に関連する既存設定を網羅的に確認する。

調査対象（ユーザーレベル）:
├── ~/.claude/CLAUDE.md
├── ~/.claude/rules/*.md
└── ~/.claude/skills/*/SKILL.md

調査対象（プロジェクトレベル）:
├── <project>/CLAUDE.md
├── <project>/.claude/rules/*.md
└── <project>/.claude/skills/*/SKILL.md

確認ポイント:

• 同じ内容が既にカバーされていないか（重複防止）
• 矛盾する既存設定がないか（整合性）
• 関連する設定が分散していないか（統合の機会）
• nix 管理の symlink ファイルでないか（直接編集不可）

既に存在する場合: 新規作成ではなく既存設定の更新・強化を検討する。

3. 変更先を決定する

フィードバックの性質	変更先	例
特定ファイル種別への規約	.claude/rules/	「TS では any 禁止」
プロジェクト固有の方針	プロジェクト CLAUDE.md	「pnpm を使う」
全プロジェクト共通の方針	ユーザー ~/.claude/CLAUDE.md	「コミットは日本語で」
複数ステップの手順	.claude/skills/	「デプロイ手順」
既存設定の改善	該当ファイル	「TDD ルールを緩和」
設定の肥大化・散在	複数ファイル	整理統合

迷った場合は references/config-hierarchy.md の詳細ガイドを参照。

4. 多角的に検討する

変更案を作成する前に、以下の視点で批判的に検討する。

• ユーザーの意図: 表面的な要望の背後にある本質的な目的は何か？
• 既存設定との整合性: 他のルール・スキルと矛盾や重複がないか？
• スコープの適切さ: ユーザーレベルかプロジェクトレベルか？広すぎないか？
• 保守性: 設定が複雑になりすぎないか？既存設定の更新で済まないか？
• 副作用: 意図しない振る舞いの変化が起きないか？他の作業フローに影響しないか？
• 可逆性: 問題があった場合に簡単に戻せるか？

重要: フィードバックを鵜呑みにしない。ユーザーの要望が既存の良い慣行と矛盾する場合、その旨を率直に伝え、代替案を提示する。

5. 変更案を提示する

変更を適用する前に、必ず以下のフォーマットで提示する。

## 変更案

**対象**: <ファイルパス>
**操作**: 新規作成 / 更新 / 削除
**理由**: なぜこの変更先を選んだか

### Before（変更前）
<現在の状態。新規作成の場合は「なし」>

### After（変更後）
<変更後の状態>

### 検討した代替案（あれば）
<他の選択肢と採用しなかった理由>

複数箇所を変更する場合は関連する変更をグループ化して提示する。

6. 適用と確認

ユーザーの承認後:

• 新規ファイルは Write ツールで作成
• 既存ファイルは Edit ツールで最小限の変更を適用
• 変更後、関連する他の設定との整合性を再確認
• nix 管理ファイルの場合は nix 設定の変更方法を案内

設定のリファクタリング

フィードバック対応だけでなく、設定の健全性維持も担う。

• 重複の統合: 複数ファイルに散在する類似ルールをまとめる
• 肥大化の分割: 大きくなりすぎた設定ファイルを分割する（rules: 500行超、skills: 500行超）
• 陳腐化の除去: 使われなくなったルールやスキルの削除を提案する
• 階層の最適化: プロジェクト固有の設定がユーザーレベルにある場合の移動を提案する

連携するスキル

• claude-code-rules: ルールファイルの詳細フォーマット・作成手順
• skill-creator: スキルの詳細な作成・パッケージング手順

新規ルール作成時は claude-code-rules を、新規スキル作成時は skill-creator を併用する。