From memex
Provides Zettelkasten best practices for high-quality memex cards: atomic insights, own words, linking in context; covers Markdown format, frontmatter, slug naming, tagging, categories. Use for writing/reviewing cards, naming, linking strategies.
How this skill is triggered — by the user, by Claude, or both
Slash command
/memex:memex-best-practicesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A reference guide for writing high-quality memex cards that compound in value over time. Covers card format, naming conventions, tagging, linking strategy, and graph health maintenance.
A reference guide for writing high-quality memex cards that compound in value over time. Covers card format, naming conventions, tagging, linking strategy, and graph health maintenance.
This is NOT a workflow skill (see memex-recall, memex-retro, memex-organize for those). This is a quality standard — consult it when writing or reviewing cards.
Before writing a card, verify:
[[wikilinks]] are embedded in sentences explaining why the relationship exists.---
title: "Short Noun Phrase ≤60 chars"
created: "YYYY-MM-DD"
source: "<auto-filled by client>"
tags: [domain-tag, type-tag]
category: "<domain>"
---
One atomic insight, written in your own words.
This relates to [[other-card]] because <explanation of the relationship>.
| Field | Required | Format |
|---|---|---|
title | ✅ | Noun phrase, ≤60 chars |
created | ✅ | ISO date YYYY-MM-DD |
source | ✅ | Auto-filled by MCP/CLI client |
| Field | Format | Notes |
|---|---|---|
tags | YAML list | See Tag System below |
category | Single string | See Categories below |
links | YAML list of slugs | Explicit links (in addition to wikilinks) |
status | conflict / draft | Set by organize skill when needed |
[[slug]] wikilinks inline, within natural sentencesSlugs are permanent identifiers. Choose them carefully.
| ✅ Good | ❌ Bad | Why |
|---|---|---|
docker-compose-port-binding | note-1 | Descriptive vs. meaningless |
jwt-revocation-blacklist | docker | Specific vs. too broad |
nextjs-app-router-caching | how-to-fix-the-bug-we-found | Noun phrase vs. sentence |
vitest-mock-timer-gotcha | vitest_mock_timer | kebab-case vs. snake_case |
Use these prefixes to signal card type at a glance:
| Prefix | Use | Example |
|---|---|---|
adr-* | Architecture decision records | adr-monorepo-vs-polyrepo |
gotcha-* | Pitfalls, traps, surprising behavior | gotcha-yaml-date-auto-parse |
pattern-* | Reusable patterns, best practices | pattern-retry-with-backoff |
tool-* | Tool-specific tips and configs | tool-gh-cli-pagination |
These are conventions, not enforced constraints. Use them when they fit naturally.
Assign one category per card to indicate its domain:
architecture · backend · frontend · devops · tooling · security · workflow · testing · data
Categories are broad. Use tags for fine-grained classification.
Tags serve two purposes: domain (what technology) and type (what kind of knowledge).
Use the specific technology or concept name:
docker · nodejs · typescript · react · nextjs · postgres · redis · git · api · css · linux · aws · azure
Classify the kind of insight:
| Tag | When to use |
|---|---|
decision | A choice was made between alternatives |
gotcha | Surprising behavior, easy-to-miss pitfall |
pattern | Reusable solution or approach |
howto | Step-by-step procedure |
reference | Factual lookup (config format, API shape) |
debug | Root cause analysis of a specific bug |
rate-limiting, not Rate Limiting)Links are the most valuable part of a Zettelkasten. They create a network that surfaces unexpected connections.
Every [[wikilink]] should appear in a sentence that explains the relationship:
<!-- ✅ Good: link explains WHY -->
This contradicts what we found in [[jwt-migration]] — stateless tokens
can't be revoked without a server-side blacklist.
<!-- ❌ Bad: link without context -->
Related: [[jwt-migration]]
Not every card needs to link to every related card. Link when the connection would surprise someone or change how they read either card.
The index card is a curated entry point to the entire knowledge graph — inspired by Luhmann's Schlagwortregister (keyword register).
memex-recall skill---
title: Keyword Index
created: <date>
source: organize
---
## Authentication
- [[jwt-revocation-blacklist]] — Server-side revocation for stateless tokens
- [[oauth2-pkce-flow]] — PKCE flow for public clients (SPAs, mobile)
## Docker
- [[docker-compose-port-binding]] — 0.0.0.0 vs 127.0.0.1 gotcha
- [[docker-multi-stage-builds]] — Reducing image size with build stages
The index is maintained by the memex-organize skill. You can also update it manually after writing cards.
The core memex workflow is a learning cycle:
┌─────────────────────────────────────────────────┐
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ RECALL │───▶│ WORK │───▶│ RETRO │ │
│ │ │ │ │ │ │ │
│ │ Search │ │ Do the │ │ Distill │ │
│ │ existing │ │ actual │ │ insights │ │
│ │ cards │ │ task │ │ to cards │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ▲ │ │
│ └───────────────────────────────┘ │
│ Cards feed future recalls │
└─────────────────────────────────────────────────┘
This loop is implemented by the memex-recall and memex-retro skills. The key insight: retro is not just documentation — it's how you learn. Writing in your own words forces deeper understanding than simply bookmarking a Stack Overflow link.
A knowledge graph degrades without maintenance. The memex-organize skill handles this, but here are the principles:
An orphan is a card that nothing links to. It may be:
A hub card is referenced by many others. It may be:
When two cards disagree, this is valuable signal — not a bug. The organize skill flags contradictions with status: conflict for human resolution. Don't auto-resolve conflicting beliefs.
If a card's information is outdated:
When importing notes from external tools like flomo, the bar is higher than session retro:
source: flomo (or the appropriate source). This enables anti-loopback guards in bidirectional sync.Cards with source: flomo are never pushed back to flomo. This is enforced in code and must not be removed. The same principle applies to any future external source: never echo content back to its origin.
| ❌ Don't | ✅ Do Instead |
|---|---|
| Write a card for every task | Only capture non-obvious insights |
| Copy-paste error messages as cards | Distill the root cause and fix |
| Create cards with no links | Always link to at least one related card |
Use vague slugs like notes or misc | Use descriptive slugs: postgres-connection-pool-sizing |
| Write essay-length cards | Keep cards atomic — split if needed |
| Hoard tags (5+ per card) | Use 1–3 tags: one domain + one type |
| Link without explaining why | Every [[link]] needs a surrounding sentence |
| Mechanical 1:1 import from external tools | Digest and curate — external notes are raw material |
| Push source: flomo cards back to flomo | Anti-loopback: never echo content to its origin |
For easy lookup, here's the complete format in one block:
---
title: "Descriptive Noun Phrase ≤60 chars"
created: "2025-01-15"
source: "<auto>"
tags: [typescript, gotcha]
category: "backend"
---
<One atomic insight in your own words.>
<Context with [[wikilinks]] explaining relationships.>
Slug: kebab-case-english-3-to-60-chars
Tags: 1 domain + 1 type, lowercase
Links: in sentences, not in lists
Length: a few paragraphs, not an essay
npx claudepluginhub iamtouchskyer/memex --plugin memexCaptures user thoughts, ideas, knowledge, questions, or sources as TwinMind cards with type classification, duplicate detection, creation, auto-linking, and index updates. Use for memorable knowledge shares.
Maintains a Zettelkasten card network by detecting orphan cards, hub cards, contradictions, and rebuilding the evolution of ideas. Run periodically or on demand to keep the card graph healthy.
Enforces Zettelkasten note-writing discipline: atomic claims, declarative titles, own-words prose, and typed link relationships. Use when capturing or refactoring evergreen notes.