--- name: init-memory description: 新しいプロジェクトに記憶管理システム（AGENTS.md + CLAUDE.md + .agent/ + .claude/agents/ + .spec/）を初期化する --- # init-memory - 記憶管理システム初期化スキル 対話的にプロジェクト情報を収集し、記憶管理システム＋サブエージェント環境を自動生成する。 ## 実行手順 ### ステップ1: プロジェクト情報の収集 ユーザーに以下を質問する（AskUserQuestionで一度に聞く）: - プロジェクト名（英語 + 日本語表記） - 種別（SaaS / モバイルアプリ / Webサイト / CLI 等） - 技術スタック（例: React + Firebase, Next.js + Supabase 等） - 対象ユーザー（誰向けのアプリか） - 参照元プロジェクトがあるか（旧リポジトリからの移行の場合、パスを聞く） - 特記すべきコーディング規約があるか ### ステップ1.5: ECC 導入状況の確認 ECC（everything-claude-code）のグローバルセットアップ状況を確認する: 1. `~/.ecc/everything-claude-code` が存在するか確認 2. `~/.ecc/ecc-state.json` を読み、最終 pull からの経過日数を確認 - 30日以上経過 → `/ecc-setup` による更新を推奨 - `ecc-state.json` が無い → `/ecc-setup` 未実行と判断 3. `~/.claude/agents/ecc-*.md` にシンボリックリンクが存在するか確認 4. 存在する場合 → CLAUDE.md に「ECC コンポーネント自動利用ルール」セクションを含める 5. 存在しない場合 → ユーザーに `/ecc-setup` の実行を提案する（必須ではない） ### ステップ2: ディレクトリ構成の自動検出 プロジェクトルートに既存ファイルがあれば構成を調査: - `package.json`, `tsconfig.json`, `app.json` 等の存在確認 - `src/`, `mobile/`, `functions/` 等のフォルダ構成 - 既にAGENTS.md / CLAUDE.md がある場合は上書きせず、マージを提案する ### ステップ3: ファイル・フォルダ作成 以下を作成する。既存ファイルがある場合はスキップ or マージ。 --- #### AGENTS.md（不変ルール — 人間が管理） ```markdown # AGENTS.md - プロジェクト規約（不変ルール） # 全AI（Claude Code・Gemini CLI・Codex 等）が参照する唯一の仕様書。 # このファイルは人間が管理する。AIは読み取り専用。絶対に変更しないこと。 --- ## プロジェクト概要 | 項目 | 内容 | |---|---| | アプリ名 | （収集した情報） | | 種別 | （収集した情報） | | バックエンド | （収集した情報） | | 主要言語 | （収集した情報） | | 対象ユーザー | （収集した情報） | --- ## 技術スタック （収集した技術スタックを一覧で記載。バージョン番号も可能な限り明記） --- ## ファイル構成 （プロジェクトの実際の構成を調査してツリー形式で記載） --- ## 命名規則 - コレクション名: snake_case - 関数名・変数名: camelCase - コンポーネント・クラス名: PascalCase - 型・インターフェース: PascalCase - ファイル名: コンポーネントは PascalCase.tsx、その他は camelCase.ts --- ## コーディング規約 （技術スタックに応じた規約。TypeScript の場合:） - 型安全を維持する。`any` の使用は極力避ける - 型定義は集約ファイルに記述する - 関数コンポーネント + React Hooks のみ使用する --- ## AI作業ルール（全AI共通） 1. コードを書く前に前提・用語・影響範囲を確認する 2. ライブラリを使う場合はバージョンを必ず明記する 3. 型定義は集約ファイルに記述する --- ## AIごとの担当領域 | 担当AI | 得意な領域 | |---|---| | Claude Code | 全体設計・DB設計・実装統括 | | Gemini | Google系API・Android実装・Firebase固有の問題 | | Codex | コード補完・リファクタリング・テスト生成 | --- ## Git運用 - コミットメッセージ: 日本語または英語、変更内容を簡潔に記述 - ブランチ: 機能追加は `feature/`、バグ修正は `fix/` --- ## 未解決・要確認事項 （プロジェクト固有の未決事項をここに記載） --- _最終更新：（今日の日付）_ ``` --- #### CLAUDE.md（Claude Code 固有設定） ```markdown # CLAUDE.md - Claude Code 固有設定 > 共通ルール・仕様は `AGENTS.md` を参照してください。 > このファイルは Claude Code 固有の差分のみ記載します。 --- ## セッション開始時のチェックリスト 1. `AGENTS.md` を読む（プロジェクト規約・仕様の唯一のソース） 2. `.agent/handoff/HANDOFF.md` を読む（前回の引き継ぎ） 3. `.agent/memory/MEMORY.md` を読む（蓄積された知見） 4. `.spec/` を確認（進行中の仕様があれば） 読み込んだことを最初に報告すること。 --- ## Claude Code 固有のルール ### 基本姿勢 - 日本語で応答する - コードを書く前に前提・用語・影響範囲を確認する - ライブラリを使う場合はバージョンを必ず明記する ### エスカレーション手順（詰まったとき） Step 1: 自分で3回アプローチを変えて試みる Step 2: 解決できない場合、以下のフォーマットで出力する \``` 【Geminiへの質問】 - 問題の概要： - 試したこと（3案）： - 環境（OS・言語・ライブラリ・バージョン）： - 期待する動作： - 実際の動作（エラーメッセージ全文）： - 関連コード（最小再現コード）： \``` ### 記憶管理ルール - セッション中に得た重要な知見は `.agent/memory/MEMORY.md` に記録 - MEMORY.md は200行以内を維持（超過時はアーカイブ） - AGENTS.md と重複する内容は MEMORY.md に書かない - セッション終了時は `/handoff` コマンドで HANDOFF.md を更新 --- ## ECC コンポーネント自動利用ルール `~/.claude/agents/` または `.claude/agents/` に `ecc-*.md` エージェントが存在する場合、 以下の状況を検知したら自律的にサブエージェントとして起動する。 ユーザーへの確認は不要（通常のサブエージェント委譲と同じ扱い）。 ### 設計・方針判断が必要な状況 | 状況 | 使うエージェント | |---|---| | 新機能の設計・大きな方針転換が発生 | ecc-planner | | アーキテクチャ上の判断が必要（DB選定、サービス分割等） | ecc-architect | | 技術的に深い調査が必要 | ecc-deep-research（スキル） | ### 実装中の品質担保 | 状況 | 使うエージェント | |---|---| | DB スキーマの新規作成・変更 | ecc-database-reviewer | | ビルドエラーが自力で3回解消しない | ecc-build-error-resolver | | テストを書く方針が決まった後の実装 | ecc-tdd-guide | ### レビュー・検証 | 状況 | 使うエージェント | |---|---| | 機能実装が完了し、マージ前のレビュー | ecc-code-reviewer | | 認証・認可・入力検証・SQL 等セキュリティに関わる変更 | ecc-security-reviewer | | デッドコードやリファクタ対象の特定 | ecc-refactor-cleaner | | ドキュメントとコードの乖離を検知 | ecc-doc-updater | ### 使わない判断 - 上記に該当しない通常の実装作業では ECC エージェントを起動しない - プロジェクト固有のサブエージェント（batch-apply, component-builder 等）が適切な場合はそちらを優先 - ECC エージェントのファイルが存在しない場合は無視する（エラーにしない） --- ## サブエージェント自動委譲ルール Opus（メインセッション）は以下のルールに従い、ユーザーに確認せず自律的にサブエージェントへ委譲する。 ### 判断フロー \``` タスクを受け取る ↓ [1] Opus が設計・調査・方針決定を行う（1ファイルで手本を作る等） ↓ [2] 横展開が必要か？（同じパターンを3ファイル以上に適用） → YES → batch-apply (Sonnet) を並列起動 → NO → 次へ ↓ [3] UI実装タスクか？（コンポーネント作成・スタイル修正） → YES → component-builder (Sonnet) に委譲 → NO → 次へ ↓ [4] Opus が直接実行（設計判断・デバッグ・アーキテクチャ変更） \``` ### 各エージェントの自動起動条件 | エージェント | model | 自動起動する条件 | |---|---|---| | **batch-apply** | sonnet | 確定パターンを3ファイル以上に適用するとき | | **component-builder** | sonnet | UIコンポーネントの作成・修正（設計が確定した後） | | **test-writer** | sonnet | ユーティリティ関数のテスト作成 | | **type-guardian** | sonnet | 型定義の変更後、整合性チェックが必要なとき | | **firebase-specialist** | sonnet | Firestoreルール・インデックスの変更 | | **Explore** | sonnet | 3クエリ以上の探索が見込まれるコードベース調査 | ### Opus が自分でやるべき作業（委譲しない） - 新機能の設計・アーキテクチャ判断 - ユーザーとの仕様すり合わせ - 複数システムにまたがるデバッグ - 手本ファイルの作成（横展開の元になる最初の1ファイル） - セッション管理（HANDOFF.md / MEMORY.md 更新） ### 委譲時のプロンプト設計 batch-apply に渡すプロンプトには必ず以下を含めること: 1. パターン定義 — 何をどう変更するか（具体的なコード例） 2. 対象ファイル一覧 — フルパスのリスト 3. マッピング表 — 変更前→変更後の対応 4. 手本ファイル — 完成形のファイルパス（あれば） 5. 触らない箇所 — 変更対象外の明示 ### 並列化の方針 - 独立したファイルへの変更は最大限並列化する - 1エージェントあたりの対象は 1〜3ファイル が最適 - 依存関係がある変更は順番に実行する --- _最終更新：（今日の日付）_ ``` --- #### .claude/agents/ — サブエージェント定義 以下の5ファイルを作成する。技術スタックに応じて内容を調整すること。 ##### batch-apply.md ```markdown --- name: batch-apply description: 確定したパターンを複数ファイルに横展開するサブエージェント。「この修正を全画面に適用して」「このパターンを残りのファイルにも」などの機械的な横展開タスクで起動する。 tools: Read, Edit, Glob, Grep model: sonnet --- あなたは「確定済みパターンの横展開」専門のエージェントです。 設計はメインセッション（Opus）が行い、あなたはその結果を複数ファイルに正確に適用します。 ## 基本原則 1. 指示されたパターンのみ適用する — 自分で設計判断しない 2. 対象ファイルを全て処理する — 漏れなく完了する 3. 既存ロジックは一切変更しない 4. 変更前に必ずファイルを読む ## 完了報告（必須） 作業完了時、変更済みファイル数・スキップ数・注意事項をテキストで返答する。 ``` ##### component-builder.md （技術スタックに応じて React / React Native / Vue 等のUI実装ルールを記載） ##### test-writer.md （テストフレームワークに応じて Vitest / Jest / Playwright 等のルールを記載） ##### type-guardian.md （TypeScript プロジェクトの場合のみ作成） ##### firebase-specialist.md （Firebase を使う場合のみ作成。使わない場合は db-specialist.md 等に置換） --- #### .agent/ フォルダ ``` .agent/ ├── memory/MEMORY.md └── handoff/HANDOFF.md ``` MEMORY.md: ```markdown # MEMORY.md - 蓄積された経験・知見 > AIが記録する学習ノート。AGENTS.md と重複しない内容のみ。 > 200行以内に収める。超過時は古い項目をアーカイブする。 --- ``` HANDOFF.md: ```markdown # HANDOFF - （今日の日付） ## 使用ツール Claude Code ## 現在のタスクと進捗 - [x] 記憶管理システム初期化 ## 試したこと・結果 - init-memory スキルでプロジェクト初期化を実行 ## 次のセッションで最初にやること 1. AGENTS.md を読む 2. 開発タスクに着手 ## 注意点・ブロッカー - なし ## 記事ネタ候補 セッション中に記事になりそうな出来事があれば記録する。なければ空欄でよい。 - （壁打ちで設計が変わった瞬間、意外な解決策、AI協働の学び、ハマりどころ、仕組み化の成功 など） ``` --- #### .spec/ フォルダ ``` .spec/ ├── SPEC.md └── TODO.md ``` SPEC.md: ```markdown # SPEC.md - 構造化された要件定義 > PLAN を元にAIが構造化する。人間の承認後に確定。 --- ``` TODO.md: ```markdown # TODO.md - タスク分解 > SPEC.md を元にAIが分解する。人間の承認後に確定。 > ステータス: [ ] 未着手 / [~] 作業中 / [x] 完了 / [-] スキップ --- ``` --- #### GEMINI.md（Gemini CLI 用） ```markdown # GEMINI.md — （プロジェクト名）Gemini CLI 専用コンテキスト > 共通ルール・仕様は `AGENTS.md` を参照してください。 ## Gemini CLI 固有のルール - 日本語で応答する - コードを書く前に AGENTS.md を読む - セッション終了時は `.agent/handoff/HANDOFF.md` を更新する ``` --- #### .gitignore に追記 既存の .gitignore に以下を追記（なければ作成）: ``` # Agent temporary files .agent/reports/ ``` --- ### ステップ4: 旧資産参照ルール（移行プロジェクトの場合） 参照元プロジェクトがある場合、CLAUDE.md に以下を追記: ```markdown ## 旧資産の参照 旧プロジェクト `（旧リポジトリのパス）` を参照可能。 コードをコピーする際は、以下を置換すること: - "（旧プロジェクト名）" → "（新プロジェクト名）" - （その他の置換ルール） ``` --- ### ステップ5: 完了報告 作成したファイル一覧をツリー形式で表示し、以下を報告: - 作成されたファイル数 - サブエージェントの種類（技術スタックに応じて何が生成されたか） - 「AGENTS.md の内容を確認・修正してください。このファイルは人間が管理するファイルです。」