CLAUDE.md の中身、全部見せます

# モデル運用方針（個人・全プロジェクト共通）

クレジット消費を抑えつつ品質を確保するため、タスクの性質に応じて
モデルとワークフローを使い分ける。Claude Fable 5 は「真価を発揮する場面」に
限定し、軽量・定型的な作業は Sonnet 5、それ以外の日常的な作業は Opus 4.8
を既定とする。

## 既定モデル
- 既定は **Opus 4.8**。
- 判断が必要な通常タスク、軽微でも判断に迷う作業は Opus 4.8 で処理する。

## 軽量・定型タスク（Sonnet 5）
- 明確に軽量・定型的な作業は **Sonnet 5**（`claude-sonnet-5`）を使い、
  クレジット消費を抑える。
- すぐ結果が欲しい質問、CRUD 実装、軽微な修正、単純な置換などが該当する。

## Fable 5 を使う場面（重いタスク限定）
以下に該当する「重いタスク」のときだけ Fable 5 を使う。
- アーキテクチャ設計・大規模な設計判断
- コードベース全体の監査／大規模移行・modernization
- 複雑なバグの根本原因調査
- 長時間の自走を要する作業

上記に該当しないタスクで Fable 5 を起動しない。

## ultracode（動的ワークフロー）の方針
- セッション全体を ultracode にはしない（全タスクにワークフロー層が
  適用され消費が膨らむため）。
- 動的ワークフローが本当に有効な単発タスクのときだけ、
  プロンプトに `ultracode` キーワードを付けて起動する。
- ワークフロー完了後は通常作業に戻す。

## 委譲ルール
- 「重いタスク」に該当する作業は、専用サブエージェント `heavy-task`
  （model: claude-fable-5）に委譲してから実行する。
- メインセッションは **Opus 4.8 のまま維持**し、Fable 5 は必要時のみ呼び出す。

# 開発方針: ハーネスエンジニアリング（全プロジェクト共通の原則）

「モデルの記憶や注意力」ではなく「環境と仕組み」に品質を担保させる。
コードを書く前に、フィードバックが自動で返ってくる状態を先に作る。

- 新規プロジェクトや新機能の着手時は、実装より先に検証ループ
  （テスト・リンタ・型チェック・ビルド・起動確認の手順）を整備する。
  検証手段がないまま実装を積み上げない。
- セッション内で同じ指示・訂正が繰り返されていると気づいたら、
  その場で従うだけでなく、CLAUDE.md／スキル／hooks／settings への
  恒久化を提案する。
- 環境の摩擦（曖昧な手順、壊れたビルド、毎回出る権限プロンプト、
  手作業前提のフロー）を見つけたら、回避せず環境側の修正を優先する。

## プラン立案時の必須ルール（plan mode／要件定義時）

プランを作成するときは、機能実装のステップに加えて、必ず以下を
独立したステップとしてプランに含める。

1. ハーネス整備フェーズ（実装より前に置く）
   - 検証ループの構築: テスト・リンタ・型チェック・起動確認の
     コマンドを決め、動く状態にする。
   - `.claude/settings.json` の作成・更新: 権限 allowlist、
     必要な hooks（例: 編集後の自動リンタ／テスト実行）を設定する。
   - CLAUDE.md の作成・更新: 検証コマンドと規約を記録する。
2. ループ設計フェーズ（運用があるプロジェクトの場合）
   - デプロイ・動作確認・ログ観測の手順を定義し、繰り返し作業は
     自動化（hooks／cron／スクリプト）の対象として明記する。

# 運用方針: ループエンジニアリング（運用・改善タスク共通の原則）

運用・改善の作業は「実行 → 観測 → 修正」のループとして設計する。
1回きりの修正で完結させない。

- 修正や変更を入れるときは、その効果を観測する手段（ログ、メトリクス、
  検証コマンド、確認手順）をセットで用意・明記する。
- 同じ形の作業が繰り返されるなら、自動化（hooks、cron／スケジュール
  実行、/loop、スクリプト化）への昇格を検討し、提案する。
- 失敗や手戻りが起きたら、個別対処に加えて「ループのどこが欠けていたか
  （観測不足か、検証不足か、手順の曖昧さか）」を一言添える。