mcpField
M
memory-bank

memory-bank

github.com/fockusエージェントワークフロー3265 回インストール2 週間前に更新
リポジトリ

memory-bank について

Memory Bank は、セッションをまたいでプロジェクトの文脈を保持するコーディングエージェント向けのスキルと開発ツールキットです。構造化されたメモリ、設定可能な開発ルール、計画・実装ワークフロー、コード検索機能を組み合わせています。

主な機能

  1. 01プロジェクト情報の継続的な保存
  2. 02設定可能な開発ルール
  3. 03仕様・計画・タスクのワークフロー
  4. 0436 個の開発コマンド
  5. 05コードグラフとセマンティック検索

活用シーン

  1. 01セッションをまたいで作業を再開
  2. 02要件から実装計画を作成
  3. 03テストとアーキテクチャのルールを適用
  4. 04コード依存関係とテストを追跡

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/fockus/skill-memory-bank --skill memory-bank

インストール後、Claude Code で/memory-bankを入力して読み込まれたか確認します。

詳細

Memory Bank スキル

コードエージェント向けの3つの機能を備えたスキルです。

  1. Memory Bank — .memory-bank/(status.md、checklist.md、roadmap.md、research.md、backlog.md、adr.md、progress.md、lessons.md、notes/、plans/、experiments/、reports/、codebase/)を通じた、プロジェクトの長期的な記憶です。
  2. RULES — グローバルなエンジニアリングルール:TDD、Clean Architecture(バックエンド)、FSD(フロントエンド)、Mobile(iOS/Android UDF)、SOLID、Testing Trophy。
  3. 開発ツールキット — 36個のコマンド:/mb、/start、/done、/plan、/brief、/discuss、/groom、/sdd、/work、/drive、/team、/qa、/config、/pipeline、/profile、/rules、/commit、/pr、/review、/test、/refactor、/doc、/changelog、/catchup、/adr、/contract、/security-review、/api-contract、/db-migration、/observability、/roadmap-sync、/traceability-gen、/analyze-task、/flow、/goal、/agree。

設計上の契約。 Memory Bank は、侵すことのできないひとつの約束――エージェントは記憶する――と、その上に重なる、完全に設定可能でトークン効率に優れた複数のレイヤーを基盤としています。明示的に有効化しない限り、デフォルトの動作は変わりません。ユーザーによるカスタマイズはアップグレード後も維持され、コストの高い処理はデフォルトで無効です。契約の詳細については、references/design-principles.md を参照してください。

詳細は、必要に応じて読み込む1階層のリファレンスファイルに記載されています。末尾のリファレンスを参照してください。


開発フロー — コードエージェントが想定すべきステージ

Memory Bank プロジェクトでの作業は、次の順序で進みます。タスクの複雑さに応じて深さが変わります。開発以外のすべてのステージは、簡単な作業では省略できます。レビューとジャッジはオプトインです。

#ステージコマンド備考
1ヒアリング/mb discuss <topic>(別名 /mb askme)詳細なヒアリング → context/<topic>.md に記録される、決定事項と EARS で検証済みの要件ドラフト
2仕様または計画/mb sdd <topic> · /mb plan <type> <topic>複雑さに応じて選択します:機能追加/複数タスク → 仕様書一式(specs/<topic>/requirements+design+tasks.md、実行可能な );範囲の限定された小規模な変更 → 計画書(`plans/*.md`、);簡単な修正 → 成果物なし(ルールは適用されます)
3開発/mb work <target>仕様のタスク/計画のステージを、役割別サブエージェントを通じて、実装 → 検証のループで順に実行します(TDD、コントラクトファースト)
4検証/mb verifyplan-verifier が差分を計画/仕様の DoD と照合して監査します。計画/仕様に沿って作業した場合、/mb done の前に必ず実施してください
5レビュー (任意)/mb work <target> --reviewレビュアーの判定(サブエージェントのアンサンブルまたは外部 codex)と重大度ゲート。デフォルトでは無効です
6ジャッジ (任意)/mb work <target> --judgemb-judge が GO / GO_WITH_BACKLOG / NO_GO を判定し、レビューループを終了します
6aQA (任意)/mb qa run実際のブラウザー(Playwright MCP)を使って稼働中の環境で、<bank>/qa/test_cases/ にある md 形式の受け入れシナリオを実施します。環境の更新後、作業の終了前に行います
7完了/mb doneMemory Bank を最新化します:進捗の追記、チェックリスト/ステータスの更新

グルーミング(任意のステージ)。 /mb groom <topic>(別名 grooming)は、固定の順序にとらわれず、批判的なグルーミングセッションを実施します。生のアイデア、仕様がすでにあるタスク、再検討する価値のある決定が対象です。/mb discuss とは異なり、目的は仕様を作ることではありません。エージェントは必要性とアプローチを問い直し、独自の解決策を提案して、見落とされている点を検討します。要約は context/<topic>-groom.md に記録され、確認済みの決定事項は agreements.md/バックログ(ADR/Ideas)に反映されます。セッションの最後に、次のステップ(例:/mb sdd)を提案します。 パイプライン。 一連の流れ全体を、名前付きワークフロー(ステップ、ロールごとの model/thinking、重要度ゲート、保護対象パス、予算)として <bank>/pipeline.yaml に記述できます。設定されている場合、/mb work は自動的にこれを解決し(mb-workflow.sh)、設定されたステップに従います。たとえば、ガバナンスに基づく implement → verify → review → judge → fix → done を実行でき、実行ごとのフラグは不要です。/mb pipeline//mb config で管理し、/mb config validate で検証します。オプトインしない限り、デフォルトは変わりません。パイプラインもフラグもない場合は、シンプルな implement → verify になります。

コマンド一覧 — /mb のすべてのサブコマンド(利用できることを把握し、関連する場合はユーザーに提案してください。各サブコマンドの詳細 → commands/mb.md または /mb help <sub>):

  • セッションとコンテキスト: context(デフォルト、引数なし) · start · done · update · tasks · note <topic> · index
  • 要件と意思決定: discuss <topic>(別名 askme) · groom <topic>(別名 grooming) · sdd <topic> · openspec <import|list|status|sync> · plan <type> <topic> · idea <title> · idea-promote <I-NNN> · adr <title> · agree <sub> · goal
  • 実行: work [target] · verify · config <sub> · pipeline <sub> · flow <route> · analyze-task
  • コードベースのインテリジェンスとメモリ: map [focus] · graph · wiki · research <query> · search <query> · recall <query> · recap <sid> · conflicts · consolidate · tags
  • セットアップとメンテナンス: init · install · profile <sub> · rules <sub> · doctor · compact · migrate-structure · import · upgrade · deps · statusline · help [sub]

/mb 以外にも、ツールキットにはスタンドアロンコマンドが含まれています(上記の概要にある一覧を参照):/commit、/pr、/review、/test、/refactor、/doc、/changelog、/catchup、/contract、/security-review、/api-contract、/db-migration、/observability、/roadmap-sync、/traceability-gen。

計画の階層: フェーズ → スプリント → ステージ。規模のしきい値、用語、各レベルを使うタイミングについては、references/templates.md § 計画の分解 を参照してください。キリル文字の «Этап / Спринт / Фаза» はレガシーの別名であり、plans/done/*.md 内でのみ使用できます。


タスクの振り分け

着手する前に、タスクの規模を「ごく小規模/小規模/標準/大規模/特大」に分類し、その区分に合わせて計画、テスト、ドキュメント、チェックを選んでください:references/effort-tiers.md。ユーザーからの明示的な依頼は、見積もりより優先されます。独立したタスクは並列サブエージェントに割り当ててください。計画は大まかに立て、行き詰まった場合にのみ細分化します(ADaPT)。

ワークスペースの解決 — エージェントに依存しないストレージ

Memory Bank は scripts/_lib.sh::mb_resolve_path を通じてアクティブなバンクを解決します。優先順位は固定され、明示されています。

  1. 明示的な引数 — mb-*.sh <mb_path> が常に優先されます。
  2. MB_PATH 環境変数の上書き — シェルセッションで一時的にリダイレクトする場合に使います。
  3. ローカルモード — <project>/.memory-bank/(/mb init のデフォルト。チームで共有でき、コミット可能)。
  4. グローバルモード — <agent_config>/memory-bank/registry.json に登録されます。初期化時に --storage=global --agent=<name>(または $MB_AGENT 環境変数)が必要です。エージェントごとのパスについては、references/structure.md § グローバルストレージのパスを参照してください。
  5. レガシーの .claude-workspace — 古いポインターモードです。references/structure.md § 旧パターンを参照してください。
  6. フォールバック — 相対パスの .memory-bank(既存のスクリプトとの互換性のため)。
アクティブ状態の意味
  • [MEMORY BANK: ACTIVE] — リゾルバーが既存のバンク(ローカルまたは登録済みのグローバル)を返した場合。
  • [MEMORY BANK: ABSENT] — 現在のプロジェクトにバンクが存在しない場合。この状態を示し、Memory Bank のライフサイクルを停止してください。黙って初期化してはいけません。
  • [MEMORY BANK: INITIALIZED] — 明示的な /mb init が正常に完了した後に限ります。
ルールのみモード

プロジェクトによっては、意図的にメモリバンクを持たない場合があります([MEMORY BANK: ABSENT])。その場合:

  • /mb のライフサイクルコマンドは、ユーザーが明示的に /mb init を実行するまで無効のままです。
  • エンジニアリングルールのベースラインは引き続き適用されます:TDD、SOLID、クリーンアーキテクチャ/FSD、DRY/KISS/YAGNI、Testing Trophy、保護対象ファイル、プレースホルダーの禁止、完了前の検証。グローバルスキルをインストールしても、メモリバンクの状態が自動的に有効になることはありません。

MB Manager やスクリプトを呼び出すときは、必ず解決済みの mb_path を渡してください。


ツール — シェルスクリプト

すべてのスクリプトは、この SKILL.md と同じ場所にある scripts/ に格納されています。グローバルインストールでは、通常、ホストのエイリアスからバンドルを利用できます:

  • Claude Code:~/.claude/skills/memory-bank/
  • Codex:~/.codex/skills/memory-bank/
  • Cursor:~/.cursor/skills/memory-bank/

スクリプトは、カレントディレクトリの .memory-bank/、または mb_path 引数を通じて動作します。 読み込まれた SKILL.md を含む絶対ディレクトリ(または MB_SKILLS_ROOT)を SKILL_DIR に設定し、各コマンドと同じシェル呼び出しで指定してください。Codex では通常、上記のスキルエイリアスを使用します。 パスを設定した後、SKILL_DIR="${MB_SKILLS_ROOT:-${SKILL_DIR:?Set SKILL_DIR from the loaded skill path}}" を使用してください。

GraphRAG-lite 検索の振り分け

「X のロジックはどこにありますか?」や「似た実装を探して」など、コードの理解に関する曖昧な質問では、code_context がデフォルトです。正確な構造に関する質問は、グラフツールに直接振り分けます:「X を呼び出している/インポートしている/定義しているのはどれですか?」→ graph_neighbors、「逆依存関係」または変更の影響→ graph_impact、「このファイル/シンボルを対象とするテストは?」→ graph_tests。ユーザーが「セマンティック検索」を明示的に依頼した場合は、明示されたツールの意図が優先されるため search_code を使用します。

フェイルオープンで動作します:グラフがない、古くなっている、セマンティックプロバイダーがない、またはネイティブ拡張が利用できない場合でも、エージェントの処理を妨げてはなりません。オプションの依存関係(tree-sitter、networkx、fastembed)がインストール済みとは限りません:bash "$SKILL_DIR"/scripts/mb-deps-check.sh --install-hints を実行すると、正確なインストールコマンドが表示されます。汎用 CLI のフォールバックとして、bash "$SKILL_DIR"/scripts/mb-graph.sh who-calls|impact|tests <Symbol> / search "<query>" / status と scripts/mb-code-context.py を使用してください。Pi と OpenCode ではネイティブのツールラッパーが公開されることがあります。一方、Claude Code、Codex、汎用 AGENTS.md エージェントはスクリプトを直接呼び出せます。

エージェントが呼び出すエントリーポイント(内部ライブラリを含む完全なグループ別表 → references/scripts.md):

  • mb-context.sh [--deep] — バンクのコンテキスト(ステータス、チェックリスト、アクティブな計画、コードベースの概要)を読み込む
  • mb-graph.sh who-calls|impact|tests <Symbol> / search "<query>" / status — グラフとセマンティックコード検索の入り口
  • mb-search.sh <q> [--tag t] — バンク全体をキーワード検索する
  • /mb recall <query>(hooks/mb-recall.sh)— セッション、ノート、合意事項、進捗を対象に、セマンティック検索と字句検索を組み合わせて検索する(RRF)
  • mb-plan.sh <type> <topic> / mb-plan-sync.sh <plan> — `` マーカー付きの計画を作成し、チェックリスト/ロードマップと同期する
  • mb-spec-validate.sh <topic> — 仕様の 3 点セット(EARS、実行可能な `` タスク、REQ のカバレッジ)を検証する
  • mb-workflow.sh / mb-work-resolve.sh / mb-work-plan.sh — /mb work のワークフロー、対象、項目ごとの JSON 計画を解決する
  • mb-agree.sh add|question|list … — agreements.md の単一の書き込み元
  • mb-coord.sh active / append — 読み込まずに、セッション横断のボードを読み書きする
  • mb-idea.sh / mb-adr.sh — backlog.md にアイデア(I-NNN)を記録するか、adr.md に ADR(ADR-NNN)を記録する
  • mb-profile.sh — ルールプロファイル(init、show、validate、set)
  • mb-drift.sh / mb-done-gates.sh — 決定論的なドリフトチェッカー。/mb done の必須ゲート

クイックスタート

# Storage modes — pick one per project:
/mb init                                      # local mode (default) — bank in repo (.memory-bank/)
/mb init --storage=local                      # explicit local mode — same as above
/mb init --storage=global --agent=claude-code # global mode — bank in ~/.claude/memory-bank/...
                                              # (personal, NOT committed to the repo)
# Rules-only mode: no /mb init at all — [MEMORY BANK: ABSENT] state;
# /mb lifecycle stays inactive; all TDD/SOLID/Clean Architecture/DRY/KISS/YAGNI rules still apply.

# Initialization flags
/mb init --full          # same as /mb init (stack auto-detect + CLAUDE.md generation)
/mb init --minimal       # only the .memory-bank/ structure

# Session flow (basic)
/mb start                # load context
# ... work, checklist.md updates as tasks complete ...
/mb verify               # verify plan alignment (if there was a plan)
/mb done                 # actualize + note + progress

# Unified SDD flow (spec-driven features)
/mb discuss <topic>      # EARS-validated requirements → context/<topic>.md
/mb sdd <topic>          # spec triple: requirements / design / tasks.md (executable)
# specs/<topic>/tasks.md is a first-class executable artifact with  markers,
# NOT a scaffold — each block is resolved by /mb work <topic> as a work item.
/mb work <topic>         # execute spec tasks one by one (reads  blocks)
/mb verify               # verify against spec + plan
/mb done                 # actualize + progress

# Personalize rules for your stack (optional):
/mb profile init --scope=project --role=backend --stack=go --architecture=microservices --delivery=contract-first
# or user-global (works even without a project Memory Bank):
/mb profile init --scope=user --role=frontend --stack=typescript

ホストがネイティブのスラッシュコマンドをサポートしていない場合は、次を使用してください:

  • ワークフローのエントリーポイントとして commands/mb.md;
  • install/init/doctor のフローには memory-bank ... CLI;
  • このスキルバンドルに含まれるスクリプトとエージェントプロンプト。

エージェント — サブエージェント

全エージェント一覧(呼び出すタイミング、プロンプトファイル、compose: 部分)→ references/agents.md。

計画の作成と ML 結果の評価は、メインエージェントが担当します。ユーザーのコンテキストと判断を把握しているためです。mb-architect は承認済みの計画に含まれるアーキテクチャ関連の項目を実行します。バグ、失敗するテストや不安定なテスト、説明できない動作は mb-debugger に任せます(修正の前に根本原因を特定します)。

呼び出し

エージェント名を指定してディスパッチします — Agent(subagent_type="mb-manager", description="…", prompt="action: <action>\n\n<context>")。 インストール済みのエージェント定義がデフォルト値を指定します。pipeline.yaml で異なるモデルや作業レベルを要求する場合があります。ホストでそのロールへの呼び出しごとの上書きが許可されている場合に限り、呼び出しごとの上書きを使用してください。許可されていない場合は、ディスパッチ前に一致するロールを生成して再読み込みするか、値を黙って置き換えずに不一致を報告してください。 コマンドは Claude Code 形式で出力します。他のホストでは、同じインストール済みロールをそれぞれのツールでディスパッチします。

ホスト名前を指定したディスパッチロールのインストール先
Claude CodeAgent(subagent_type=<name>, prompt=…)(旧ビルドでは Task)~/.claude/agents/<name>.md
OpenCodesubagent({agent: "mb-developer", description: "Implement assigned task", prompt: "Implement the assigned task and verify its definition of done."}).opencode/agent/<name>.md。グローバルなオプトイン設定:セットアップ
Codexspawn_agent(agent_type=<name>, message=…)。インストール済みのロールにはモデルと作業レベルが設定されています。実行時の上書きはホストのサポート状況によります~/.codex/agents/<name>.toml
Pimb_dispatch_subagent(role=<name>, task=…) または pi-subagents の subagent(agent=<name>, task=…)。thinking は引き継がれます~/.pi/agent/agents/<name>.md

OpenCode の model 引数は省略可能です。名前を指定したディスパッチに対応していないホストでは、ロールファイルとその compose: 部分を読み込み、インラインで作業します。


フック、ホスト、プライバシーとキャプチャ

  • Codex のネイティブフックには、モデルを使わないルートセッションのメモリと、ユーザーの信頼を得た後の子コンテキストが含まれます。MB_SESSION_CAPTURE=off でオプトアウトできます。詳細:references/codex-native-hooks.md。
  • OpenCode 2 はネイティブコマンド/フックと、オプトイン方式のモデルを使わないルートキャプチャに対応しています。実行ごとのモデル/バリアントの継承によって、永続的な固定設定が変更されることはありません。セットアップ、キャプチャの切り替え、制限:OpenCode 2。
  • ライフサイクルフック(一覧とホストごとの設定):references/hooks.md § フック一覧。
  • ホスト固有の注意事項(Claude Code のネイティブメモリ、Codex、Cursor):references/hosts.md。
  • <private> の内容、自動キャプチャ(MB_AUTO_CAPTURE)、セッションログ、PreCompact の引き継ぎ:references/privacy-and-capture.md。/mb done でバンクを自動コミットできます(MB_AUTO_COMMIT=1、scripts/mb-auto-commit.sh)。

セッション間の連携 — .memory-bank/COORDINATION.md

同じ作業ツリー内で2つ以上のセッションが並行して作業する場合(エージェントの CLI が2つ、またはエージェントと人間)、バンクのルートにある単一の追記専用ボードファイル COORDINATION.md を通じて連携します。これは任意の仕組みです。並行セッションの存在を最初に知ったセッションがファイルを作成します。ボードファイルがなければ、プロトコルによる負荷はありません。

  • scripts/mb-coord.sh active で読み込み、cat は使わないでください — ボードは追記専用で、数百 KB に達します。このコマンドは有効な FREEZE、ACK のない HANDOVER、直近の3エントリ、合計行を表示します。エントリは mb-coord.sh append --type <T> --title <t> で書き込みます。
  • プロトコル全体(エントリの規約、競合への対処、信頼ルール、新しいセッション用の接続プロンプト):references/coordination.md。

合意事項一覧 — .memory-bank/agreements.md

現在有効な確定済みの決定事項をまとめた正式なレジストリです。progress.md (経緯の記録)やADR(変更が困難な決定事項のうち、その理由を記録するもの)とは区別されます。すべての変更は scripts/mb-agree.sh(add | supersede | defer | reject | question | resolve | list | sync)を通じて行います。モデルによる直接編集は禁止です。変更内容はプロジェクトルートの CLAUDE.md/AGENTS.mdにある管理ブロック (``)にも自動同期されるため、新しいセッションでも、リマインドされなくてもすべての有効な合意事項を確認できます。

  • 完全なプロトコル(合意事項に該当するもの/しないもの、反例、ステータス、ADRへの振り分け):references/agreements.md。コマンドリファレンス:commands/agree.md。

参考資料

  • ルールプロファイルのスキーマ(次元、不変のベースライン、優先順位、検証):references/rules-profile.schema.md
  • 設計原則(侵害されないメモリの約束+設定可能なレイヤー):references/design-principles.md
  • メタデータプロトコル+index.json+8つの主要ルール:references/metadata.md
  • 計画の分解(Phase / Sprint / Stage)、テンプレート、ドリフトチェック:references/templates.md
  • 計画+Plan Verifier のワークフロー:references/planning-and-verification.md
  • Orchestrator コンソール(進行中のトラック、未解決の質問、コンパクション後のチェック):references/orchestrator-console.md
  • 工数ティア(タスクの規模を trivial … extra に分類し、計画/テスト/ドキュメント/チェックを対応付ける):references/effort-tiers.md
  • ADaPT-lite — 行き詰まった項目のみを分解する仕組み、complexity_escalation:references/adapt.md
  • /mb work のリファレンス資料(ワークフローモード、JSON スキーマ、例、スクリプト、並列実行):references/work-reference.md
  • /mb work のスプリント契約、進捗の傾向、戦略的な方向転換:references/work-loop-v2.md
  • .memory-bank/ の構成:references/structure.md
  • コードグラフのクックブック(jq ライブラリ、graph.json スキーマ、インテリジェンスレイヤー、セマンティック検索のルーティング):references/code-graph.md
  • ワークフロー(セッションのライフサイクル):references/workflow.md
  • セッションメモリ(チャットをまたぐ記録、/mb recall、session-doctor):references/session-memory.md
  • セッション間の調整ボード(COORDINATION.md プロトコル):references/coordination.md
  • 合意事項の継続リスト(agreements.md プロトコル、ステータス、アンチパターン):references/agreements.md
  • コマンドファイルのテンプレート:references/command-template.md
  • フック(ホストごとの配線+ライフサイクル):references/hooks.md
  • スクリプト — グループ別の完全な表(バンクのコア、計画と仕様、/mb work、グラフ、セッションメモリ、内部ライブラリ):references/scripts.md
  • エージェント — サブエージェントの完全な一覧:references/agents.md
  • mb-debugger のデバッグ手法(superpowers、MIT を基に調整):references/debugging/root-cause-tracing.md · references/debugging/defense-in-depth.md · references/debugging/condition-based-waiting.md
  • ホスト固有の注意事項(Claude Code、Codex、Cursor):references/hosts.md
  • プライバシーと記録(<private>、自動記録、セッションログ、PreCompact の引き継ぎ):references/privacy-and-capture.md
  • Codex ネイティブフックアダプター:references/codex-native-hooks.md
  • Pi ネイティブ統合:references/pi-native-integration.md
  • アダプターマニフェストのスキーマ:references/adapter-manifest-schema.md
  • タグの語彙:references/tags-vocabulary.md
  • CLAUDE.md 自動生成テンプレート:references/claude-md-template.md
  • グローバルルール(~/.claude/RULES.md としてインストール):rules/RULES.md;常時適用されるコアブロック:rules/CLAUDE-GLOBAL.md
  • 主要ルールのカタログ(1行で記述されたコード/プロセスのルール、デフォルト、固定された原則;/mb rules/mb-rules.sh で選択):rules/key-rules.json
  • スタック別のレビュアー調整例:references/rubric-examples/common.md · references/rubric-examples/backend.md · references/rubric-examples/frontend.md · references/rubric-examples/go.md · references/rubric-examples/mobile.md · references/rubric-examples/python.md · references/rubric-examples/typescript.md
  • フロールート:flow-templates/arch.md · flow-templates/bugfix.md · flow-templates/code-change.md · flow-templates/migration.md · flow-templates/research.md
  • フローパターン:flow-templates/patterns/adversarial-verify.md · flow-templates/patterns/classify-and-act.md · flow-templates/patterns/fanout-synthesize.md · flow-templates/patterns/generate-filter.md · flow-templates/patterns/loop-until-done.md · flow-templates/patterns/tournament.md
  • CHANGELOG:CHANGELOG.md
  • v1→v2 の移行:docs/MIGRATION-v1-v2.md
  • 主なエントリーポイント:
    • /mb — ホストがネイティブコマンドに対応している場合
    • commands/mb.md/memory-bank CLI — ネイティブコマンドのインターフェースが利用できない場合

コメント