MCP Setup

{
  "mcpServers": {
    "amfs": {
      "command": "uvx",
      "args": ["amfs-mcp-server"],
      "env": {
        "AMFS_HTTP_URL": "https://amfs-login.sense-lab.ai",
        "AMFS_API_KEY": "<your-api-key>"
      }
    }
  }
}

{
  "mcpServers": {
    "amfs": {
      "command": "uvx",
      "args": ["amfs-mcp-server"],
      "env": {
        "AMFS_HTTP_URL": "https://amfs-login.sense-lab.ai",
        "AMFS_API_KEY": "<your-api-key>"
      }
    }
  }
}

amfs_set_identity("checkout-agent", "Fixing retry logic")

---
name: amfs
description: "Use this skill at the start of any session where AMFS MCP tools are connected. Covers the full session lifecycle: set identity, briefing, read/write, commit outcome. Also use when storing decisions, retrieving past context, or any mention of AMFS, agent memory, or persistent memory across sessions."
---

# AMFS Skill

Use this skill whenever AMFS MCP tools are available — reading context, storing decisions, or committing outcomes across sessions.

## Trigger conditions
- Starting any session where AMFS MCP is connected
- User asks to remember, store, or retrieve something
- After making a significant decision or completing meaningful work
- When context from a previous session may be relevant

## Session workflow (always follow this order)

1. **Set identity** — always first, every session. Use a stable kebab-case name that persists across conversations about the same domain.
   `amfs_set_identity("your-agent-name", "what you're doing this session")`
   Good names: `api-agent`, `infra-agent`, `dashboard-agent`
   Bad names: `fix-button` (too specific), `agent-1` (meaningless)

2. **Get briefing** — one call replaces many reads
   `amfs_briefing(entity_path="repo/module")`
   If briefing is empty, use `amfs_list` or `amfs_read` to pull specific keys.

3. **Work** — read before decisions, write after meaningful ones

4. **Commit** — always at session end, it's free
   `amfs_commit_outcome("task-ref", "success|minor_failure|failure")`

## Entity path conventions
Use hierarchical `{project}/{module}` paths to scope knowledge. Avoid generic paths like `project` or `app` — they become unsearchable.

Examples:
- `myapp/auth` — authentication module
- `myapp/api` — API layer
- `myapp/checkout` — checkout service
- `user/context` — personal or cross-project context
- `user/preferences` — working style, communication preferences

## Key naming conventions
- `pattern-` reusable patterns
- `risk-` known bugs or blockers
- `decision-` architectural or strategic choices
- `task-summary-` what was done and why
- `action-` log of actions taken

## Cost model
- Read = 1 op (`amfs_read`, `amfs_search`, `amfs_list`, `amfs_briefing`)
- Write = 2 ops (`amfs_write`, `amfs_record_context`)
- Commit = free (never skip)

Prefer `amfs_briefing` over multiple individual reads — one briefing returns compiled, ranked knowledge for an entity.

## What to write
- Decisions with rationale (why, not just what)
- Risks or blockers discovered
- Patterns worth reusing
- Task summaries after meaningful work
- User decisions that affect direction

## What to skip
- Trivial changes (typos, renames, comments)
- Anything recomputable from the codebase in seconds
- One-sentence observations — batch related ones into a single richer entry

## Memory types
- `fact` — stable, verified knowledge (default)
- `belief` — hypothesis or unverified observation, use confidence < 0.9
- `experience` — action log, decays slower, good for what was done and why

## Confidence guidelines
- `1.0` — verified, tested in production
- `0.7–0.9` — high confidence, not yet verified
- `0.4–0.6` — hypothesis, needs validation
- `< 0.4` — speculative, early signal

## Known issues
- `amfs_commit_batch` may throw a CausalTagger session_id error — use individual `amfs_write` calls instead
- `amfs_briefing` returns empty on new stores until the Memory Cortex compiles digests (async)

Machine A (Cursor / Bruno):
  → Reviews checkout-service PR
  → amfs_write("myapp/checkout", "risk-race-condition", "...")
  → amfs_commit_outcome("PR-456", "minor_failure")

Machine B (Claude Code / Alice):
  → Starts working on checkout-service
  → amfs_briefing(entity_path="myapp/checkout")
  → Sees Bruno's risk signal with boosted confidence
  → Avoids the same issue

"args": ["amfs-mcp-server@0.2.3"]