
Memory Notes
Author Basic Memory markdown notes with frontmatter, categorized observations, and wiki-link relations so agents and humans get a searchable knowledge graph.
Install
npx skills add https://github.com/basicmachines-co/basic-memory-skills --skill memory-notesWhat is this skill?
- Three-part note anatomy: YAML frontmatter, Observations section, Relations section
- Observations use semantic categories such as decision, requirement, and risk with optional #tags
- Relations link entities with wiki-links (implements, depends_on, relates_to)
- Required frontmatter title becomes the knowledge-graph entity name
- Guidance for improving existing notes, not only greenfield files
Adoption & trust: 561 installs on skills.sh; 20 GitHub stars; 2/3 security scanners passed (skills.sh audits).
Recommended Skills
Journey fit
Docs is the canonical shelf because the skill defines durable note structure that backs specs, decisions, and runbooks across the product lifecycle. Subphase docs fits structured knowledge capture that ships alongside code—not a one-off research scrape or landing copy task.
Common Questions / FAQ
Is Memory Notes safe to install?
skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.
SKILL.md
READMESKILL.md - Memory Notes
# Memory Notes Write well-structured notes that Basic Memory can parse into a searchable knowledge graph. Every note is a markdown file with three key sections: frontmatter, observations, and relations. ## Note Anatomy ```markdown --- title: API Design Decisions tags: [api, architecture, decisions] --- # API Design Decisions The API team evaluated multiple approaches for the public API during Q1. After prototyping both REST and GraphQL, the team chose REST due to broader ecosystem support and simpler caching semantics. This note captures the key decisions and their rationale, along with open questions still to resolve. ## Observations - [decision] Use REST over GraphQL for simplicity #api - [requirement] Must support versioning from day one - [risk] Rate limiting needed for public endpoints ## Relations - implements [[API Specification]] - depends_on [[Authentication System]] - relates_to [[Performance Requirements]] ``` ### Frontmatter Every note starts with YAML frontmatter: ```yaml --- title: Note Title # required — becomes the entity name in the knowledge graph tags: [tag1, tag2] # optional — for organization and filtering type: note # optional — defaults to "note", use custom types with schemas permalink: custom-path # optional — auto-generated from title if omitted --- ``` - The `title` must match the `# Heading` in the body - Tags are searchable and help with discovery - Custom `type` values (Task, Meeting, Person, etc.) work with the schema system. See the **memory-schema** skill for defining schemas, validating notes against them, and detecting drift. - The `permalink` is auto-generated from the `title` and `directory`. For example, title "API Design Decisions" in directory "specs" produces permalink `specs/api-design-decisions` and memory URL `memory://specs/api-design-decisions`. If no directory is specified, the permalink is just the kebab-cased title. Permalinks stay stable across file moves. You rarely need to set one manually. > **Note:** When using `write_note`, you don't write frontmatter yourself. The `title`, `tags`, `note_type`, and `metadata` are separate parameters — Basic Memory generates the frontmatter automatically. Your `content` parameter is just the markdown body starting with `# Heading`. ### Body / Context Free-form markdown between the heading and the Observations section. This is the heart of the note — write generously here: - Background, motivation, and history - Detailed explanation of what happened and why it matters - Analysis, reasoning, and trade-offs considered - Context that someone (or an AI) needs to understand this note later Write complete, substantive prose. Basic Memory's search retrieves relevant chunks from note bodies, so longer, richer context makes notes more discoverable and more useful when found. Don't reduce everything to bullet points — tell the story. ## Observations Observations are categorized facts — the atomic units of knowledge. Each one becomes a searchable entity in the knowledge graph. ### Syntax ``` - [category] Content of the observation #optional-tag ``` - **Square brackets** define the semantic category - **Content** is the fact, decision, insight, or note - **Hash tags** (optional) add extra metadata for filtering ### Categories Are Arbitrary The category in brackets is free-form — use whatever label makes sense for the observation. There is no fixed list. The only rule is the `[category] content` syntax. Consistency within a project helps searchability, but invent categories freely. A few examples to illustrate the range: ``` - [decision] Use PostgreSQL for primary data store - [risk] Third-party API has no SLA guarantee - [technique]