memory-bank

メモリバンク

セッションをまたいで Claude Code に永続的でインテリジェントなコンテキストを提供し、トークンの無駄を削減して、セッションを 3～5 倍長く続けられる適応型メモリシステムです。単なるフラットファイルではありません。必要な情報だけを読み込みながら、圧縮、分岐、差分管理、自己修復を行う階層型アーキテクチャです。

---

コアアーキテクチャ

メモリバンクは 3 つのレイヤーで動作します。

┌─────────────────────────────────────────────┐
│  Layer 2: GLOBAL MEMORY                     │
│  ~/.claude/GLOBAL-MEMORY.md                 │
│  Cross-project patterns, user preferences,  │
│  reusable decisions. Permanent.             │
├─────────────────────────────────────────────┤
│  Layer 1: PROJECT MEMORY                    │
│  ./MEMORY.md (+ branch overlays)            │
│  Architecture, decisions, active work.      │
│  Lives as long as the project.              │
├─────────────────────────────────────────────┤
│  Layer 0: SESSION CONTEXT                   │
│  In-conversation only.                      │
│  Current task focus, scratch notes.         │
│  Dies when session ends (persisted to L1).  │
└─────────────────────────────────────────────┘

レイヤー 0（セッション） — 一時的なレイヤーです。現在の作業内容を追跡します。セッション終了時にレイヤー 1 へ自動的に書き出されます。

レイヤー 1（プロジェクト） — 主要なメモリファイルです。プロジェクトの状態、決定事項、進行中の作業、ブロッカーを追跡します。ブランチを認識し、各 git ブランチにはベースメモリと統合される独自のオーバーレイを設定できます。

レイヤー 2（グローバル） — プロジェクト間で共有される知識です。コーディングの好み、ツールの選択、いつも使うパターンが含まれます。~/.claude/GLOBAL-MEMORY.md に保存され、セッション開始時にレイヤー 1 とともに読み込まれます。

アーキテクチャの詳細については、references/memory-layers.md を参照してください。

---

起動タイミング

トリガー	アクション
セッション開始時に MEMORY.md が存在する	全読み込みシーケンス
"remember this"、"don't forget"	セッション中の更新
"wrap up"、"save progress"、"done for now"	セッション全体を書き込む
"pick up where we left off"、"what were we doing"	読み込み＋要約
"switch to [branch]"、"context for [feature]"	ブランチを認識した読み込み
"memory health"、"is memory stale"	ヘルスチェック
"hand off"、"onboard someone"	引き継ぎドキュメントを生成
"compress memory"、"clean up memory"	圧縮を実行
"rebuild memory"	復旧モード
"save state"、"continue this later"	セッション継続プロトコル
"context budget"、"how much context left"	コンテキスト予算を確認
"running out of context"、"session is long"	緊急保存＋継続ファイル

---

ワークフロー

1. セッション開始 — 読み込みシーケンス

ほかの作業を始める前に、次のシーケンスを実行します。

Step 1: Detect memory files
  └─ Check for MEMORY.md in project root
  └─ Check for ~/.claude/GLOBAL-MEMORY.md
  └─ Check for MEMORY-ARCHIVE.md (has history been archived?)

Step 2: Detect git context
  └─ Current branch name
  └─ Check for .memory/branches/<branch>.md overlay
  └─ Days since last session (from "Last updated" field)

Step 3: Session diff (if git available)
  └─ Commits since last memory update
  └─ Files changed since last session
  └─ Any conflicts between memory and current code state

Step 4: Health check
  └─ Score memory freshness (see Health Scoring below)
  └─ Flag stale entries
  └─ Flag referenced files that no longer exist

Step 5: Context-aware greeting
  └─ Summarize where we left off (2-3 sentences, specific)
  └─ Report any drift detected (code changed, memory stale)
  └─ State the next immediate action
  └─ Ask: "Ready to continue, or has the plan changed?"

挨拶の例（メモリが新しく、同じブランチの場合）：

「おかえりなさい！前回のセッションでは、Stripe の Webhook ハンドラーを src/api/webhooks/stripe.ts に実装し、次に統合テストを書くところでした。 handlePaymentSuccess() 関数は完成していますが、handleRefund() は スタブのままです。その後、コミットが 3 件入りました。すべてあなたの変更で、 想定外のものはありません。統合テストから再開しますか？」

挨拶の例（メモリが古く、ブランチが切り替わっている場合）：

「おかえりなさい！メモリは 5 日前の main の状態ですが、現在は feature/user-profiles にいます。プロフィール画像のアップロードに関する コンテキストを含む、3 日前のブランチオーバーレイが見つかりました。ただし、 メモリで参照されている src/components/Avatar.tsx は ProfileImage.tsx に名前が変更されています。続行する前に、現在の状態に合わせて メモリを更新しますか？」

MEMORY.md が存在しない場合：

• 通常どおり進めます
• 最初の有意義な作業の後に、次のように提案します。「進捗の記録を始めましょうか？次回のセッションですぐに再開できるよう、メモリファイルを作成します。」

---

2. セッション中の更新

ユーザーが「これを覚えておいて」と言ったとき、または重要なマイルストーンを達成したとき：

1. 現在の MEMORY.md を読み込みます
2. 変更点を特定します：
   • 新しい決定事項がある場合 → Key Decisions を更新
   • タスクが完了した場合 → Active Work から Completed に移し、Where We Left Off を更新
   • 新しいブロッカーがある場合 → Blockers に追加
   • 重要なコンテキストがある場合 → Notes に追加
3. 更新したファイルを書き込みます
4. 具体的な内容を添えて確認します：「保存しました。Zod の移行に関する決定を追加し、ユーザーモデルを完了として記録しました。」

**セッション中の更新でファイル全体を書き換えてはいけません。**変更されたセクションだけを修正します。これにより、セッション開始時のコンテキストが保持されます。

---

3. セッション終了 — 書き込みシーケンス

作業を終える際は、メモリ全体を書き込む処理を実行します。

Step 1: Audit the session
  └─ What was accomplished? (be specific: files, functions, lines)
  └─ What decisions were made and why?
  └─ What's blocked or unresolved?
  └─ What should happen next? (crystal clear next step)

Step 2: Compress completed work
  └─ Move finished items to Completed with one-line summaries
  └─ Remove resolved blockers
  └─ Archive stale notes

Step 3: Update memory health metadata
  └─ Update "Last updated" timestamp
  └─ Increment session counter
  └─ Update file reference table (verify paths still exist)

Step 4: Write MEMORY.md
  └─ Full overwrite with current state
  └─ Verify the file was written successfully

Step 5: Check compression threshold
  └─ If > 150 lines, suggest compression
  └─ If > 200 lines, auto-compress (see Smart Compression)

Step 6: Prompt for global memory
  └─ Any cross-project learnings worth saving to Layer 2?
  └─ New user preferences discovered?

---

MEMORY.md テンプレート

# Project Memory
Last updated: [DATE] | Session [N] | Branch: [BRANCH]
Memory health: [SCORE]/10

## Project Overview
[1-2 sentences. What this is, what stack, what stage.]

## Where We Left Off
- **Current task:** [specific task with file/function reference]
- **Status:** [done | in progress | blocked]
- **Next immediate step:** [so clear Claude can start without asking anything]
- **Open question:** [decision pending, if any]

## Completed
- [DATE] [one-line summary with key files touched]
- [DATE] [one-line summary]

## Active Work
- [ ] [task — specific file, function, or component]
- [ ] [task]
- [x] [recently completed, will archive on next compression]

## Blockers
- [blocker with context on what's needed to unblock]

## Key Decisions
| Date | Decision | Reasoning | Affects |
|------|----------|-----------|---------|
| [DATE] | [what was decided] | [why] | [files/areas impacted] |

## Key Files
| File | Purpose | Last Modified |
|------|---------|---------------|
| [path] | [what it does] | [session N] |

## Architecture Notes
[Non-obvious design choices, data flow, system boundaries]

## Known Issues
- [issue, severity, and workaround if any]

## Session Log
| Session | Date | Summary |
|---------|------|---------|
| [N] | [DATE] | [one-line summary of what happened] |

## User Preferences
[How the user likes to work — discovered across sessions]

## External Context
[APIs, services, env setup — NO secrets, NO credentials, NEVER]

---

ブランチを考慮したメモリ

複数の Git ブランチをまたいで作業する場合、メモリは適応します。

MEMORY.md                          <- Base project memory (main/trunk)
.memory/
  branches/
    feature-auth.md                <- Overlay for feature/auth branch
    feature-payments.md            <- Overlay for feature/payments branch
    bugfix-race-condition.md       <- Overlay for bugfix branch

仕組み：

1. セッション開始時に、現在の Git ブランチを検出します
2. まずベースの MEMORY.md を読み込みます
3. .memory/branches/<branch-slug>.md にオーバーレイがあるか確認します
4. オーバーレイをベースに重ねて統合します（オーバーレイのセクションが優先されます）
5. セッション終了時に、変更を適切なレイヤーに書き戻します：
   • アーキテクチャ上の決定 → ベースの MEMORY.md（ブランチ間で共有）
   • ブランチ固有の作業 → .memory/branches/<branch>.md

ブランチのマージ時：

• フィーチャーブランチが main にマージされると、次のように確認します： 「feature/auth ブランチがマージされました。メモリの オーバーレイをベースの MEMORY.md に統合して、ブランチファイルを クリーンアップしますか？」

マージ戦略については、references/branch-aware-memory.md を参照してください。

---

スマート圧縮

メモリファイルは増大します。スマート圧縮によって、メモリを有用な状態に保ちます。

自動圧縮のトリガー：

• MEMORY.md が 150 行を超える → 圧縮を提案します
• MEMORY.md が 200 行を超える → 自動で圧縮します
• 5 セッションより前のエントリー → アーカイブ候補になります

圧縮ルール：

1. 3 セッションより前に完了したタスク → セッションログ内の 1 行にまとめます
2. 解決済みのブロッカー → 完全に削除します
3. 古くなった「進行中の作業」項目（3 セッション以上進展なし）→ ユーザーに知らせます
4. 決定ログのエントリー → 絶対に圧縮しません（恒久的な記録です）
5. アーキテクチャノート → 絶対に圧縮しません（恒久的な記録です）

アーカイブ： セッション数が 10 を超えたら、MEMORY-ARCHIVE.md を作成します：

# Memory Archive
Archived sessions from Project Memory.

## Sessions 1-8 Summary
[Paragraph summary of early project work]

## Key Milestones
- Session 2: Initial project scaffolding complete
- Session 5: Auth system shipped
- Session 8: Database migration to Prisma complete

圧縮アルゴリズムの詳細については、references/smart-compression.md を参照してください。

---

セッション差分の確認

セッション開始時に、メモリが最後に書き込まれてから変更された内容を検出します。

# Get the date from MEMORY.md "Last updated" field
# Then check what happened since

git log --oneline --since="[last-updated-date]"
git diff --stat HEAD~[commits-since]

報告形式：

「前回のセッション（3 日前）以降、7 件のコミットがあります： あなたによるものが 4 件、@teammate によるものが 3 件です。主な変更点：src/api/users.ts がリファクタリングされ、 package.json に新しい依存関係（zod、@tanstack/query）が 2 件追加されています。 メモリには src/api/users.ts への参照があります。現在も正確か確認します。」

競合の検出： セッション差分によってメモリと矛盾する変更が見つかった場合：

• メモリには「Express を使用」とあるが、現在の package.json には Fastify がある → 要確認として通知します
• メモリは src/auth/login.ts を参照しているが、ファイルが削除されている → 要確認として通知します
• メモリには「API キー待ち」とあるが、現在の .env にキーがある → 更新します

競合解決の戦略については、references/session-diffing.md を参照してください。

---

メモリの健全性スコア

次の 4 つの観点で、メモリを 1～10 の尺度で評価します。

観点	重み	スコア 10	スコア 1
鮮度	30%	今日更新	14 日以上前
関連性	30%	参照先のファイルがすべて存在する	ほとんどのファイルが見つからない、または名前が変更されている
完全性	20%	すべてのセクションが記入され、次の手順が明確	重要なセクションが不足している
実行可能性	20%	すぐに作業を開始できる	3 件以上の質問が必要

セッション開始時に表示：

Memory health: 8/10
  Freshness:    9/10 (updated yesterday)
  Relevance:    7/10 (2 file paths changed)
  Completeness: 8/10 (all sections present)
  Actionability: 9/10 (next step is crystal clear)

健全性スコアが 5 未満の場合： 復旧モードを起動するか、メモリの再構築を提案します。

---

復旧モード

メモリが大幅に古くなっている、破損している、または重要なコンテキストが欠落している場合：

Step 1: Scan the project
  └─ Read package.json / pyproject.toml / go.mod (detect stack)
  └─ Read README.md and CLAUDE.md (project context)
  └─ List key directories and recent files

Step 2: Read git history
  └─ Last 20 commits (who, what, when)
  └─ Current branch and recent branches
  └─ Any open/recent PRs

Step 3: Reconstruct memory
  └─ Build Project Overview from package.json + README
  └─ Build Key Files from most-modified files in git log
  └─ Build Key Decisions from commit messages and code patterns
  └─ Set "Where We Left Off" from most recent commits
  └─ Flag confidence level: "Reconstructed from code — verify with user"

Step 4: Present and confirm
  └─ Show reconstructed memory to user
  └─ Ask for corrections
  └─ Write verified MEMORY.md

---

引き継ぎプロトコル

Claude 向けではなく、人間向けに最適化された開発者引き継ぎドキュメントを生成します。

# Project Handoff: [Project Name]
Generated: [DATE] | By: [user] via Claude Code

## Quick Start
1. Clone: `git clone [repo]`
2. Install: `[package manager] install`
3. Setup: [env vars, database, etc.]
4. Run: `[dev command]`

## Current State
[Where the project is right now — what works, what doesn't]

## Architecture
[System diagram, key components, data flow]

## Active Work
[What's in progress, what's next, what's blocked]

## Key Decisions & Why
[Decisions that a new developer would question — with the reasoning]

## Gotchas
[Things that will bite you if you don't know about them]

## Who to Ask
[People, channels, or docs for domain-specific questions]

「generate a handoff」「onboard someone to this project」 「write a handoff doc」で起動します。

---

コンテキスト効率化エンジン

Claude Code への最大の不満は、セッションがすぐにコンテキスト上限に達することです。 トークンの半分をコンテキストの説明し直しに費やし、残り半分で 実際の作業を行います。Memory Bank はこの比率を逆転させます。

トークンの問題（tiktoken で検証済み）

memory-bank がない場合、セッション開始のたびに約 1,200 トークンが必要です。

Conversation overhead (4 exchanges):      ~566 tokens
  User re-explains project, stack, status
  Claude asks clarifying questions
  User answers follow-ups
  Back-and-forth until Claude understands

File reads (Claude reads 3+ files to orient): ~634 tokens
  Webhook handler:    ~344 tokens
  Checkout route:     ~257 tokens
  Stripe client:      ~33 tokens

TOTAL per session: ~1,200 tokens
TOTAL over 10 sessions: ~12,000 tokens wasted

トークンの解決策（検証済み）

memory-bank を使うと、同じセッション開始に必要なトークンは約 400 です。

MEMORY.md loads (compact format):  ~334 tokens
  Entire project context in one structured file
  Decisions, files, status, blockers, architecture

Claude greeting + user confirms:   ~60 tokens
  Claude already knows everything, no questions needed

File reads needed:                 0 tokens
  Memory has file purposes, no need to read source

TOTAL per session: ~394 tokens (67% reduction)
TOTAL over 10 sessions: ~3,940 tokens (saved ~8,060)

この数値は、サンプルファイルを使って tiktoken で測定しました。 実際の削減量はプロジェクトの複雑さによって異なります（規模の大きなプロジェクトほど削減量が増えます）。

段階的な読み込み

すべてをコンテキストに一度に読み込まないでください。段階的に読み込みます。

Tier 1: ALWAYS load (costs ~200 tokens)
  └─ Project Overview (1-2 sentences)
  └─ Where We Left Off (current task, status, next step)
  └─ Active Blockers

Tier 2: Load on DEMAND (costs ~300 tokens when needed)
  └─ Key Decisions (only when a decision comes up)
  └─ Key Files (only when working with files not in Tier 1)
  └─ Architecture Notes (only when touching architecture)

Tier 3: Load ONLY when asked (costs ~200 tokens when needed)
  └─ Session Log (only for velocity/history questions)
  └─ User Preferences (only on first session or when relevant)
  └─ External Context (only when working with APIs/services)

結果： メモリーを一度に800トークン読み込む代わりに、まず200トークンをすぐに読み込み、残りは実際に必要になったときだけ読み込みます。ほとんどのセッションでは、Tier 3 は必要ありません。

コンパクトなエンコードのルール

MEMORY.md の各行は、トークンあたりの情報量が最大になるように最適化されています。

文章ではなく、構造化された略記を使います：

BAD (38 tokens):
  "We made the decision to use Prisma as our ORM instead of Drizzle
   because it provides better TypeScript type inference and the team
   is already familiar with it from previous projects."

GOOD (14 tokens):
  | 2025-04-01 | Prisma over Drizzle | Type inference, team familiarity | All DB |

構造化データには、圧縮しやすい表を使います：

BAD (scattered prose — 120 tokens for 5 files):
  The main checkout route is in src/app/api/checkout/route.ts. The Stripe
  client is configured in src/lib/stripe.ts. Cart state management is in...

GOOD (table — 60 tokens for 5 files):
  | File | Purpose |
  | src/app/api/checkout/route.ts | Stripe session creation |
  | src/lib/stripe.ts | Stripe client singleton |
  | src/stores/cart.ts | Zustand cart + persistence |

進行中の作業には、一覧性が高く情報密度の高いチェックリストを使います：

BAD (prose):
  We are currently working on the webhook handler, which is partially
  complete. We also need to write tests and haven't started yet.

GOOD (checklist):
  - [x] Stripe webhook handler — handlePaymentSuccess()
  - [ ] handleRefund() — stubbed, needs implementation
  - [ ] Integration tests for webhook endpoints

1行に1つの事実だけを書きます。余分な言葉は使いません：

BAD: "The project is essentially a web application that was built for..."
GOOD: "Bakery e-commerce. Next.js 14, Prisma, Stripe. Launching April."

コンテキスト予算の追跡

トークンの使用量を監視し、上限に達する前に警告します：

At session start, estimate the context budget:

Available context:   ~200,000 tokens (Claude's window)
Memory load:         ~800 tokens (Tier 1 + loaded Tiers)
System prompt:       ~2,000 tokens
Remaining for work:  ~197,200 tokens

At 40% usage (~80,000 tokens consumed):
  → Suggest: "We're at 40% context. Consider compacting soon."

At 60% usage (~120,000 tokens consumed):
  → Save a session checkpoint automatically
  → Suggest: "Context at 60%. Good time to /compact or start fresh."

At 80% usage (~160,000 tokens consumed):
  → Auto-save full state to MEMORY.md
  → Alert: "Context is at 80%. Saving state now — you can continue
     in a new session with zero loss. Say 'wrap up' or keep going."

セッション継続プロトコル

セッションがコンテキストの上限に達した場合、またはユーザーが新たに始めたい場合：

Step 1: EMERGENCY SAVE (before context dies)
  └─ Write MEMORY.md with EVERYTHING from current session
  └─ Include exact cursor position: file, function, line number
  └─ Include any uncommitted mental model (what Claude was thinking)
  └─ Include partial work state: what's done, what's half-done, what's next

Step 2: Write CONTINUATION.md (a one-shot warm-up file)
  └─ Ultra-compact: under 50 lines, under 500 tokens
  └─ Contains ONLY what the next session needs to start immediately
  └─ Format:

  ```markdown
  # Continue: [task name]
  Resume from: `src/auth/refresh.ts:47` — writing rotateToken()
  
  ## State
  - handlePaymentSuccess(): DONE ✓
  - handleRefund(): stubbed at line 89, needs Stripe refund.created event
  - Tests: NOT STARTED
  
  ## Context
  - Stripe webhook sig verified in middleware (line 12)
  - Using stripe.webhooks.constructEvent() not manual HMAC
  - Refund handler follows same pattern as payment handler
  
  ## Immediate Next Action
  Implement handleRefund() in src/api/webhooks/stripe/route.ts:89
  using the stripe.refund.created event payload. Pattern:
  extract refund.payment_intent → find order → update status to "refunded"

ステップ 3：あいさつして作業開始（次のセッション） └─ まず CONTINUATION.md を読む（最短ルートです） └─ 必要な場合のみ、全体のコンテキストを確認するため MEMORY.md を読む └─ 読み込み後に CONTINUATION.md を削除する └─ すぐに作業を開始する — 質問やウォームアップは不要

**Trigger phrases:** "save state", "I'm running out of context",
"continue this later", "session is getting long"

### Token Savings By Feature (Verified)

| Feature | How It Saves | Measured Impact |
|---------|-------------|-----------------|
| Structured memory vs re-explaining | Compact file replaces 4+ conversation exchanges | ~566 tokens/session |
| Eliminating orientation file reads | Claude doesn't need to read source files to understand project | ~634 tokens/session |
| Compact encoding (tables > prose) | Same info, 39-42% fewer tokens than prose | 39-42% reduction in memory size |
| Session continuation protocol | CONTINUATION.md is under 200 tokens vs full re-warm-up | ~1,000 tokens on session handoff |
| Smart compression | Keeps memory under 150 lines / ~700 tokens | Prevents bloat over time |

**Verified totals (measured with tiktoken):**

| Scenario | Tokens | Turns |
|----------|--------|-------|
| Without memory-bank | ~1,200/session | 8 turns |
| With memory-bank | ~394/session | 2 turns |
| **Savings** | **~806/session (67%)** | **6 turns** |
| Over 10 sessions | **~8,060 saved** | 60 turns saved |
| Over 30 sessions | **~24,180 saved** | 180 turns saved |

### Anti-Patterns That Waste Tokens

**Never do these in memory files:**

✗ 表で済む内容を冗長な文章で書く ✗ 同じ情報を複数のセクションで繰り返す ✗ コードスニペットをメモリーに保存する（代わりにファイル名と行番号を参照する） ✗ 完了した作業を長々と説明する（1行の要約だけにする） ✗ 解決済みの障害を残す（削除する） ✗ すでに README.md や CLAUDE.md にある情報を保存する ✗ Git が追跡している情報（コミット履歴、差分、blame）にメモリーを使う

**Always do these:**

✓ 構造化データ（決定事項、ファイル、タスク）には表を使う ✓ 進行中の作業にはチェックリストを使う ✓ プロジェクト概要は段落ではなく1文にする ✓ コードを説明する代わりに、ファイル名と行番号を参照する ✓ 解決済みの項目は削除する（Git の履歴に残っています） ✓ 内容を重複させず、他のファイルを参照する

> See `references/context-efficiency.md` for the full token optimization guide.

---

## Rules for Excellent Memory

**Be surgical, not vague.**
Bad: "Working on auth"
Good: "Implementing JWT refresh token rotation in `src/auth/refresh.ts` —
`rotateToken()` is complete, needs Redis TTL logic in `src/cache/tokens.ts:47`"

**The "Next immediate step" is the single most important line.**
It should be so precise that Claude can start coding the instant a session
begins, with zero clarifying questions.

**Capture the "why" behind every decision.**
Future Claude will encounter the same trade-offs and re-litigate them
unless the reasoning is recorded.

**Never store secrets.** No API keys, passwords, tokens, or credentials.
Ever. Not even "temporarily". Reference `.env` or a secrets manager instead.

**Overwrite on session end, surgical update mid-session.**
Session end = full rewrite for consistency. Mid-session = targeted section
updates to avoid losing context.

**Keep it under 150 lines.** Compress aggressively. Stale information is
actively harmful — it misleads more than it helps.

---

## Auto-Setup via CLAUDE.md

For fully automatic memory with all features, add to project `CLAUDE.md`
(or `~/.claude/CLAUDE.md` for all projects):

```markdown
## Memory

At the start of every session:
1. Check for MEMORY.md in the project root
2. Check for ~/.claude/GLOBAL-MEMORY.md
3. Check current git branch and look for .memory/branches/<branch>.md
4. Run session diff — what changed since last memory update
5. Score memory health and flag any issues
6. Greet me with a specific summary and the next immediate step

During sessions:
- Update memory when I say "remember this" or complete a milestone
- Track key decisions with reasoning in the decision table

At session end (when I say "wrap up", "save", "done for now"):
1. Write comprehensive MEMORY.md with full current state
2. Ensure "Next immediate step" is crystal clear
3. Run compression if over 150 lines
4. Confirm what was saved

完全な統合ガイドについては、references/claude-md-integration.md を参照してください。

---

参考ファイル

• references/memory-layers.md — 昇格ルールとレイヤー間の相互作用を含む、3層メモリーシステムの完全なアーキテクチャ
• references/branch-aware-memory.md — Git ブランチとの統合、オーバーレイのマージ、クリーンアップ戦略
• references/smart-compression.md — 圧縮アルゴリズム、アーカイブのしきい値、圧縮してはいけない内容
• references/session-diffing.md — セッション間の変更検出、競合解決、ドリフト補正
• references/advanced-patterns.md — チームのワークフロー、ベロシティの追跡、引き継ぎプロトコル、エンタープライズ向けパターン
• references/context-efficiency.md — トークン最適化ガイド、段階的な読み込みの詳細、コンパクトなエンコードのリファレンス
• references/claude-md-integration.md — すべてのプロジェクトで自動的にトリガーするための完全なセットアップガイド

例

• examples/solo-fullstack.md — Next.js アプリを開発する個人開発者向けのメモリー
• examples/team-backend.md — バックエンドサービス向けのチーム共有メモリー
• examples/monorepo.md — モノレポ向けの複数ドメインのメモリー
• examples/minimal.md — 迅速なプロトタイプ向けの5行メモリー