memory-bank
Persistent project documentation system that maintains context across sessions. Creates structured Memory Bank files to preserve project knowledge, decisions, and progress.
Best use case
memory-bank is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Persistent project documentation system that maintains context across sessions. Creates structured Memory Bank files to preserve project knowledge, decisions, and progress.
Teams using memory-bank should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/memory-bank/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How memory-bank Compares
| Feature / Agent | memory-bank | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Persistent project documentation system that maintains context across sessions. Creates structured Memory Bank files to preserve project knowledge, decisions, and progress.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Memory Bank
I am Claude Code, an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.
## Memory Bank Structure
The Memory Bank consists of required core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
```
memory-bank/
├── projectbrief.md # Foundation - core requirements and goals
├── productContext.md # Why this exists, problems it solves
├── activeContext.md # Current focus, recent changes, next steps
├── systemPatterns.md # Architecture, patterns, decisions
├── techContext.md # Tech stack, setup, constraints
└── progress.md # Status, what works, what's left
```
### File Hierarchy
```
projectbrief.md
├── productContext.md
├── systemPatterns.md
└── techContext.md
└── activeContext.md
└── progress.md
```
### Core Files (Required)
1. **projectbrief.md**
- Foundation document that shapes all other files
- Created at project start if it doesn't exist
- Defines core requirements and goals
- Source of truth for project scope
2. **productContext.md**
- Why this project exists
- Problems it solves
- How it should work
- User experience goals
3. **activeContext.md**
- Current work focus
- Recent changes
- Next steps
- Active decisions and considerations
4. **systemPatterns.md**
- System architecture
- Key technical decisions
- Design patterns in use
- Component relationships
5. **techContext.md**
- Technologies used
- Development setup
- Technical constraints
- Dependencies
6. **progress.md**
- What works
- What's left to build
- Current status
- Known issues
### Additional Context
Create additional files/folders within memory-bank/ when they help organize:
- Complex feature documentation
- Integration specifications
- API documentation
- Testing strategies
- Deployment procedures
## Core Workflows
### Starting a Session
1. Read ALL memory bank files in order:
- projectbrief.md (foundation)
- productContext.md (why)
- techContext.md (how)
- systemPatterns.md (architecture)
- activeContext.md (current state)
- progress.md (status)
2. Verify context is complete
3. Identify current work focus from activeContext.md
4. Continue from where we left off
### During Work
1. Keep activeContext.md updated with current focus
2. Document significant decisions in systemPatterns.md
3. Update progress.md after completing features
4. Add new patterns or constraints to relevant files
### Ending a Session
1. Update activeContext.md with:
- What was accomplished
- Current state of work
- Immediate next steps
- Any blockers or considerations
2. Update progress.md with:
- New completed items
- Changed status of in-progress items
- New known issues
## Documentation Updates
Memory Bank updates occur when:
1. Discovering new project patterns
2. After implementing significant changes
3. When user requests with **update memory bank** (MUST review ALL files)
4. When context needs clarification
When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md and progress.md as they track current state.
## Initializing Memory Bank
When starting a new project or if memory-bank/ doesn't exist:
```bash
mkdir -p memory-bank
```
Create projectbrief.md first by asking the user:
- What is this project?
- What are the core requirements?
- What are the main goals?
Then create remaining files based on discovered context.
## File Templates
### projectbrief.md
```markdown
# Project Brief
## Overview
[One paragraph describing what this project is]
## Core Requirements
- [Requirement 1]
- [Requirement 2]
## Goals
- [Goal 1]
- [Goal 2]
## Scope
### In Scope
- [Item]
### Out of Scope
- [Item]
```
### productContext.md
```markdown
# Product Context
## Problem Statement
[What problem does this solve?]
## Solution
[How does this project solve it?]
## User Experience
[How should users interact with this?]
## Success Criteria
- [Criteria 1]
- [Criteria 2]
```
### activeContext.md
```markdown
# Active Context
## Current Focus
[What we're working on right now]
## Recent Changes
- [Change 1]
- [Change 2]
## Next Steps
1. [Step 1]
2. [Step 2]
## Active Decisions
- [Decision being considered]
## Blockers
- [Any blockers]
```
### systemPatterns.md
```markdown
# System Patterns
## Architecture
[High-level architecture description]
## Key Patterns
### [Pattern Name]
- Purpose: [Why this pattern]
- Implementation: [How it's implemented]
## Component Relationships
[How components interact]
## Design Decisions
| Decision | Rationale | Date |
|----------|-----------|------|
| [Decision] | [Why] | [When] |
```
### techContext.md
```markdown
# Tech Context
## Stack
- [Technology]: [Purpose]
## Development Setup
```bash
# Setup commands
```
## Dependencies
- [Dependency]: [Version] - [Purpose]
## Constraints
- [Constraint 1]
## Environment
- [Environment variable]: [Purpose]
```
### progress.md
```markdown
# Progress
## Completed
- [x] [Feature/Task]
## In Progress
- [ ] [Feature/Task] - [Status]
## Planned
- [ ] [Feature/Task]
## Known Issues
- [Issue 1]
## Metrics
- [Metric]: [Value]
```
## Best Practices
1. **Be Concise** - Memory bank files should be scannable
2. **Be Current** - Update after significant changes
3. **Be Accurate** - Don't let documentation drift from reality
4. **Be Complete** - Include enough context to resume work
5. **Be Structured** - Use consistent formatting
## REMEMBER
After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.Related Skills
moai-foundation-memory
Persistent memory across sessions using MCP Memory Server for user preferences, project context, and learned patterns
memorylane
Zero-config persistent memory for Claude with automatic cost savings. Use when you need to remember project context, reduce API token costs, track learned patterns, manage memories across sessions, or curate/clean up memories. Automatically compresses context 6x and saves 84% on API costs. Keywords: memory, remember, recall, context, cost savings, reduce tokens, learn, patterns, insights, curate, clean up memories, review memories.
memory-sync
Guided workflow for maintaining strategic redundancy between Serena memories and project documentation. Use after significant code changes, phase completions, or when new architectural patterns are discovered.
memory-management
Guide for managing Claude Code memory effectively. Use when setting up project memory, optimizing CLAUDE.md files, configuring rules directories, or establishing cross-session knowledge patterns. Covers memory hierarchy, best practices, and context optimization.
memory
Manages memory, SSOT files, and Plans.md operations. Use when user mentions メモリ, memory, SSOT, decisions.md, patterns.md, マージ, merge, Plans.md, 移行, migrate. Do NOT load for: 実装作業, レビュー, 一時的なメモ, セッション中の作業記録.
memory-conventions
This skill should be used when persisting context between sessions, saving project state, loading previous session context, or managing longitudinal memory beyond beads issue tracking.
memory-capture
Capture and organize memories, decisions, and learnings to a memories.md file. Use when you want to save context for future sessions.
context-memory
Advanced context and memory management system for AI agents. Provides persistent memory across sessions through daily logs (memory/YYYY-MM-DD.md), long-term curated memory (MEMORY.md), conversation archives with semantic search, and automatic behavioral learning from user satisfaction tracking. Use when you need to: (1) Remember information across sessions, (2) Archive conversations before context loss, (3) Search past discussions, (4) Track and learn from user satisfaction patterns, (5) Maintain session continuity, (6) Implement proactive memory maintenance. Includes conversation-archiver.py and satisfaction-tracker.py scripts, session startup routines, and periodic reflection workflows.
Bankr x402 SDK - Job Management
This skill should be used when the user asks about "job status", "check if request completed", "cancel request", "why is my request taking so long", "poll for result", "batch requests", "retry failed request", "request timeout", "async operations", "job lifecycle", "manual polling", or needs advanced control over SDK async operations, manual job polling, batch processing, retry logic, or job cancellation.
banking-domain-conventions
Use when writing code in a Firefly Banking Platform (firefly-oss) service — applies domain organization, service taxonomy, inter-service communication patterns, POM inheritance, and platform-specific conventions
ac-memory-manager
Manage persistent memory for autonomous coding. Use when storing/retrieving knowledge, managing Graphiti integration, persisting learnings, or accessing episodic memory.
atuin-memory
Check, store, and retrieve project memories from atuin kv. Use when starting work on a project, recalling previous context, storing plans or specs, or when the user mentions memory, atuin, or project context.