using-brain-memory
Guidance for using Brain semantic memory effectively. Applies Zettelkasten atomic note principles with observations and relations. Use when deciding whether to query or create notes, structuring note content, or understanding the semantic knowledge graph.
- License 许可
- MIT
- 最近更新
- 2026-03-11
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- using-brain-memory
- agents
- [ "memory", "context-retrieval" ]
- license
- MIT
- metadata
- { "model": "claude-sonnet-4-5", "version": "1.0.0" }
- description
- Guidance for using Brain semantic memory effectively. Applies Zettelkasten atomic note principles with observations and relations. Use when deciding whether to query or create notes, structuring note content, or understanding the semantic knowledge graph.
02 资源文件 4
- 脚本capture-rate-limits.sh1.2 KB
- 参考文档REFERENCE.md1.8 KB
- 脚本select-review-profile.sh1.6 KB
- 参考文档TOOL_REFERENCE.md6.3 KB
03 SKILL.md 正文
Using Brain Memory
Brain is a semantic knowledge graph built from markdown files using Zettelkasten (atomic note) principles. Files are the source of truth. This skill guides effective memory usage.
Core Principles
- Local-First: Plain text markdown files on user's computer
- Files are Truth: Database is derived state, files are source of truth
- Persistent: Knowledge survives across sessions
- Semantic: Observations and relations create a navigable knowledge graph
When to Query Memory
Query memory proactively when:
- Starting work on a project (check for existing context)
- User references past work, decisions, or discussions
- Encountering a problem that may have been solved before
- Implementing patterns that may already be documented
- Needing context about preferences or approaches
Use mcp__plugin_brain_brain__search_notes with:
query: Natural language search terms- Optional filters:
category,tags,project
Getting Recent Notes
To see what's been recorded recently:
mcp__plugin_brain_brain__list_notes({
"limit": 10,
"project": "project-name"
})
This is useful when:
- Starting a session on a project you haven't worked on recently
- Reviewing what was captured in previous conversations
- Getting a quick overview of project knowledge
When to Create Notes
Create notes for knowledge worth preserving:
- Important decisions with rationale
- Technical patterns or approaches
- Architectural choices
- Preferences and workflows
- Project milestones
- Solutions to non-trivial problems
- Bug investigations and root causes
Do NOT create notes for:
- Temporary context (current file paths, transient issues)
- Common knowledge available elsewhere
- Trivial or throwaway information
- Content that changes frequently
Atomic Note Principles
Each note must pass the atomicity test:
- Can you understand it at first glance?
- Can you title it in 5-50 words?
- Does it represent ONE concept/fact/decision?
Note Structure
| Component | Purpose |
|---|---|
| Title | Short, searchable phrase |
| Category | Type: analysis, research, decision, feature, bug, pattern |
| Observations | Atomic facts about the topic |
| Relations | Links to other notes (bidirectional) |
| Tags | For categorization and filtering |
| Context | Additional markdown content |
Observations
Observations are atomic facts within a note. Each observation should:
- State ONE fact, insight, or finding
- Be self-contained and understandable
- Use clear, specific language
Example observations:
- "Uses JWT with httponly cookies for session management"
- "Performance degrades above 1000 concurrent connections"
- "Decided against GraphQL due to caching complexity"
Relations
Relations connect notes semantically:
relates_to: General connection between topicsdepends_on: Technical or logical dependencyimplements: Implementation of a design/specsupersedes: Replaces an older notereferences: Cites or mentions another note
Query Before Create
Always check for existing notes before creating:
mcp__plugin_brain_brain__search_notes({
"query": "<topic of potential new note>"
})
If similar note exists:
- Use
edit_notewithappendoperation to add new observations - Or create new note with
supersedesrelation if replacing - Or add
relates_torelation for connected topics
Progressive Knowledge Building
Build knowledge incrementally:
- Search for existing note on topic
- Append new observations to existing note
- Create new note only if topic is truly distinct
- Link related notes via relations
Use mcp__plugin_brain_brain__edit_note with operations:
append: Add to end (most common for new observations)prepend: Add to beginning (for urgent updates)find_replace: Replace specific textreplace_section: Replace markdown section by heading
Announcing Memory Operations
When creating a note, announce:
Saved to memory: "[title]"
Category: [category]
Tags: [tags]
Relations: [linked note titles]
When querying, summarize:
Found X notes about [topic]:
- [Note 1]: [brief insight]
- [Note 2]: [brief insight]
Content Organization
Notes are organized by:
- Category: analysis, research, decision, feature, bug, pattern, spec, etc.
- Project: Optional project scope
- Tags: Cross-cutting categorization
Example directory structure:
notes/
├── analysis/
│ └── topic-slug/
│ └── overview.md
├── decisions/
│ └── decision-slug.md
├── features/
│ └── feature-slug/
│ └── overview.md
└── patterns/
└── pattern-name.md
Tool Quick Reference
Note Tools
| Tool | Purpose |
|---|---|
mcp__plugin_brain_brain__search_notes |
Semantic search across notes |
mcp__plugin_brain_brain__read_note |
Read note by identifier |
mcp__plugin_brain_brain__write_note |
Create new note |
mcp__plugin_brain_brain__edit_note |
Incremental edit (append, prepend, replace) |
mcp__plugin_brain_brain__list_notes |
List notes with filters |
Full schemas: See TOOL_REFERENCE.md for complete parameter details and examples.
04 同仓库更多 Skills
validation-authority
Treat upstream validators as authoritative. Align local config to them. Use when validation fails unexpectedly, before modifying validator behavior, or when tempted to change upstream tool code.
threat-modeling
Structured security analysis using OWASP Four-Question Framework and STRIDE methodology. Generates threat matrices with risk ratings, mitigations, and prioritization. Use for attack surface analysis, security architecture review, or when asking what can go wrong.
taste-lints
Custom lints with agent-readable remediation instructions. Enforces taste invariants (file size, naming conventions, structured logging, complexity) and surfaces errors that agents can act on directly. Use when writing or reviewing code to catch style violations early.
style-enforcement
Validate code against style rules from .editorconfig, StyleCop.json, and Directory.Build.props. Detects line ending violations, naming convention issues, indentation problems, and charset mismatches across C#, Python, TypeScript, and JavaScript. Produces JSON reports for pre-commit hooks and CI pipelines.
steering-matcher
Match file paths against steering file glob patterns to determine applicable steering guidance. Use when orchestrator needs to inject context-aware guidance based on files being modified.
slashcommandcreator
Autonomous meta-skill for creating high-quality custom slash commands using 5-phase workflow with multi-agent validation and quality gates. Use when user requests new slash command, reusable prompt automation, or wants to convert repetitive workflows into documented commands.