agentleFS
modeled-information-formatmodeled-information-format/mnemonic/skills/core/SKILL.md

core

Skill23 starsChanged 10 months agoMITView on GitHub

This skill should be used when the user says "capture memory", "save to memory", "remember this", or trigger phrases like: "I've decided", "let's use", "we're going with", "I learned", "turns out", "TIL", "discovered", "I'm stuck", "blocked by", "always use", "never do", "convention is". Also triggers on recall phrases: "what did we decide", "how do we handle", "remind me", "search memories".

28 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ts-core, native-ui and 3 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • VercelSkill

    ts-core

    Authoring guide for the primary Native SDK app-logic path: TypeScript app cores - Model, Msg, update, and the pure functions they call, written in the closed app-core subset, checked by the @native-sdk/core frontend, and compiled ahead-of-time to native code by the external core compiler. Use for new apps unless the user explicitly chose Zig, when writing or modifying a src/core.ts app core, fixing subset checker errors (NS1001-NS1069), or deciding how to express state, messages, text (bytes and the byte-text string methods), text input, continuous controls (sliders, scroll), effects (Cmd), subscriptions (Sub), the host-event wiring channels (frameMsg, keyMsg, pinchMsg, dropMsg, appearanceMsg, chromeMsg, envMsgs, app manifest assets), derived values, the view_unbound lint opt-out, local mutation of owned arrays, or how to split a core into modules under src/ (relative imports, namespace imports, @native-sdk/core/text, @native-sdk/core/events). Use ts-services alongside this guide for src/services work.

    Also in 3 projects that use this

  • VercelSkill

    native-ui

    Authoring guide for the Native markup (.native) view tier of native-rendered Native SDK apps. TypeScript cores are the default and use this skill together with ts-core; Zig cores are an explicit alternative and this guide labels their lower-level UiApp recipes. Use when building or modifying native UI (widgets, layout, bindings, messages), writing .native files, wiring views to Model/Msg/update, testing markup views, or verifying a native app through the automation harness.

    Also in 3 projects that use this

  • +3 more from vercel-labs

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 7 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 20 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run /mnemonic:list --namespaces to see available namespaces from loaded ontologies.

    line 25
  2. Distinctive:

    When to capture: Only capture when the user explicitly states a decision, learning, pattern, or blocker in their message.

    line 69
  3. Distinctive:

    Do NOT say "I'm capturing this" or similar

    line 73
  4. Very specific:

    Run /mnemonic:status to show memory stats

    line 98
  5. Distinctive:

    Use search to find recent relevant memories

    line 99
  6. Distinctive:

    Search for existing memories with similar keywords:

    line 112
  7. Distinctive:

    If matches found, read the top result

    line 117
  8. Distinctive:

    If it covers the same topic → UPDATE existing memory (use Edit tool) instead of creating new

    line 118
  9. Very specific:

    If related but different → create new memory with a relates-to relationship

    line 119
  10. Distinctive:

    Only create brand new if no matches found

    line 120

“Common” is measured: kept by at least 6 in 10 of the 20 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- BEGIN MNEMONIC PROTOCOL -->

Memory

Search first: /mnemonic:search {relevant_keywords} Capture after: /mnemonic:capture {namespace} "{title}"

Run /mnemonic:list --namespaces to see available namespaces from loaded ontologies.

<!-- END MNEMONIC PROTOCOL -->

Mnemonic Core

Memory system operations. See references/ for full documentation.

Trigger Phrases

Capture Triggers (silently capture when user says):

Decisions (namespace: _semantic/decisions):

  • "I've decided", "let's use", "we're going with"
  • "we'll use", "I'm choosing", "going forward with"
  • "the decision is", "we chose", "decided on"

Learnings (namespace: _semantic/knowledge):

  • "I learned", "turns out", "discovered that"
  • "TIL", "gotcha", "found out", "realized"
  • "the root cause was", "it was because"

Patterns (namespace: _procedural/patterns):

  • "always use", "never do", "when X do Y"
  • "the pattern is", "we should always", "convention is"
  • "standard approach", "best practice here"

Blockers (namespace: _episodic/sessions/blockers):

  • "I'm stuck on", "blocked by", "can't figure out"
  • "hitting a wall", "the problem is", "struggling with"

Context (namespace: _semantic/knowledge):

  • "important to know", "keep in mind", "context is"
  • "background", "constraint", "requirement"

Recall Triggers (search memories when user asks):

  • "what did we decide about", "how do we handle"
  • "what's our approach to", "check for decisions"
  • "any learnings about", "patterns for"
  • "remind me", "what do we know about"
  • "search memories", "recall", "find memories"

Silent Capture Protocol

When to capture: Only capture when the user explicitly states a decision, learning, pattern, or blocker in their message. Do NOT capture based on Claude's own suggestions or recommendations.

When trigger phrases are detected:

  1. Capture to appropriate namespace WITHOUT announcing
  2. Do NOT say "I'm capturing this" or similar
  3. Continue natural conversation flow
  4. Memory creation is invisible to user

Do NOT capture:

  • Claude's own suggestions (only user-stated facts)
  • Hypothetical scenarios ("we could use...")
  • Questions or exploratory discussion

Visibility & Review

Users can review captured memories at any time:

# Check session status and recent captures
/mnemonic:status

# List recent memories (last 7 days)
find ${MNEMONIC_ROOT} -name "*.memory.md" -mtime -7 -exec basename {} \;

# Search for specific captures
/mnemonic:search {keywords}

If a user asks "what did you capture?" or "show me my memories":

  • Run /mnemonic:status to show memory stats
  • Use search to find recent relevant memories
  • This is NOT a violation of silent capture - user explicitly requested visibility

Capture

/mnemonic:capture {namespace} "{title}"

Namespaces: _semantic/decisions | _semantic/knowledge | _procedural/patterns | _episodic/blockers | _episodic/sessions

MANDATORY: Before creating any memory, check for duplicates:

  1. Search for existing memories with similar keywords:
    rg -i "{key_words}" ${MNEMONIC_ROOT}/ --glob "*.memory.md" -l | head -5
  2. If matches found, read the top result
  3. If it covers the same topic → UPDATE existing memory (use Edit tool) instead of creating new
  4. If related but different → create new memory with a relates-to relationship
  5. Only create brand new if no matches found

Recall

rg -i "{keywords}" ${MNEMONIC_ROOT}/ --glob "*.memory.md" -l

Minimal Memory Format

CRITICAL: Generate real values. NEVER write placeholders like "PLACEHOLDER_UUID" or "PLACEHOLDER_DATE".

Generate a UUID and timestamp FIRST, then write the file:

# Generate these BEFORE writing the memory file
UUID=$(uuidgen 2>/dev/null | tr '[:upper:]' '[:lower:]')
[ -z "$UUID" ] && UUID=$(python3 -c "import uuid; print(uuid.uuid4())")
DATE=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

Type must match namespace path:

  • _semantic/* → type: semantic
  • _procedural/* → type: procedural
  • _episodic/* → type: episodic

Then create the file with the real generated values:

---
id: <the real UUID generated above>
title: "Your actual title here"
type: semantic
namespace: _semantic/decisions
created: <the real DATE generated above>
temporal:
  validFrom: <the real DATE generated above>
  recordedAt: <the real DATE generated above>
  lastAccessed: <the real DATE generated above>
  decay:
    model: exponential
    halfLife: P90D
    strength: 1.0
provenance:
  sourceType: agent_inferred   # user_explicit if the user stated it directly
  agent: claude
  confidence: 0.9
---

# Your actual title here

Content here.

Half-life defaults:

  • _semantic/decisions: P180D (long-lived)
  • _semantic/knowledge: P90D
  • _procedural/patterns: P180D (long-lived)
  • _episodic/*: P30D (fast decay)

References

  • references/capture.md - Full capture workflow
  • references/recall.md - Search and retrieval patterns
  • references/schema.md - Complete MIF Level 3 schema
  • references/examples.md - Working examples

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.