Use when Daem0nMCP tools are available - enforces the sacred covenant (commune at session start, seek counsel before changes, inscribe decisions, seal outcomes)
When Daem0nMCP memory tools are available, you MUST follow this protocol. Memory without discipline is noise.
Core principle: Check before you change, record what you decide, track whether it worked.
First, verify Daem0nMCP tools are available:
Look for these tools in your available tools:
- mcp__daem0nmcp__get_briefing
- mcp__daem0nmcp__context_check
- mcp__daem0nmcp__remember
- mcp__daem0nmcp__record_outcome
- mcp__daem0nmcp__link_memories
- mcp__daem0nmcp__trace_chain
- mcp__daem0nmcp__get_graph
- mcp__daem0nmcp__find_code
- mcp__daem0nmcp__analyze_impact
- mcp__daem0nmcp__index_project
If tools are NOT available: This skill does not apply. Proceed normally.
If tools ARE available: Follow the protocol below. No exceptions.
IMMEDIATELY when you have daem0nmcp tools:
mcp__daem0nmcp__get_briefing()
DO NOT:
- Ask user what they want first
- Skip briefing because "it's a quick task"
- Assume you remember from last session
The briefing loads:
BEFORE touching any file:
mcp__daem0nmcp__context_check(description="what you're about to do")
OR for specific files:
mcp__daem0nmcp__recall_for_file(file_path="path/to/file")
If context_check returns:
AFTER every significant decision:
memory_result = mcp__daem0nmcp__remember(
category="decision", # or "pattern", "warning", "learning"
content="What you decided",
rationale="Why you decided it",
file_path="relevant/file.py", # optional
tags=["relevant", "tags"]
)
SAVE THE MEMORY ID - you need it for record_outcome
Category Guide:
| Category | Use For | Persistence |
|---|---|---|
| decision | Architectural/design choices | Decays over 30 days |
| pattern | Recurring approaches to follow | PERMANENT |
| warning | Things to avoid | PERMANENT |
| learning | Lessons from experience | Decays over 30 days |
AFTER implementing and testing:
mcp__daem0nmcp__record_outcome(
memory_id=<id from remember>,
outcome="What actually happened",
worked=true # or false
)
FAILURES ARE VALUABLE. If something doesn't work:
worked=false with explanationrecall_for_filerememberrecord_outcome called| Excuse | Reality |
|---|---|
| "It's a small change" | Small changes compound into big problems |
| "I'll remember later" | You won't. Record now. |
| "Context check is overkill" | 5 seconds now vs hours debugging later |
| "The warning doesn't apply" | Warnings exist because someone failed before |
| "I don't need to record failures" | Failures are the most valuable memories |
The Sacred Covenant is now ENFORCED, not advisory:
COMMUNION_REQUIRED blockCOUNSEL_REQUIRED blockremedy: The exact tool call to fix itTools are classified:
After context_check(), you receive a preflight_token in the response.
This is cryptographic proof you consulted the Daem0n.
Token is valid for 5 minutes.
Before file edits, use the parallel-preflight skill to run:
IN PARALLEL for maximum efficiency.
SESSION START
└─> get_briefing()
BEFORE CHANGES
└─> context_check("what you're doing")
└─> recall_for_file("path") for specific files
└─> ACKNOWLEDGE any warnings
AFTER DECISIONS
└─> remember(category, content, rationale)
└─> SAVE the memory_id
└─> link_memories() if causally related to other decisions
AFTER IMPLEMENTATION
└─> record_outcome(memory_id, outcome, worked)
INVESTIGATING CONTEXT
└─> trace_chain() to understand decision history
└─> get_graph() to visualize relationships
Without protocol discipline:
With protocol discipline:
Memories can be explicitly linked to create a knowledge graph. Use these when decisions are causally related.
| Type | Meaning | Example |
|---|---|---|
led_to |
A caused/resulted in B | "PostgreSQL choice led to connection pooling pattern" |
supersedes |
A replaces B (B is outdated) | "New auth flow supersedes old JWT approach" |
depends_on |
A requires B to be valid | "Caching strategy depends on database choice" |
conflicts_with |
A contradicts B | "Sync processing conflicts with async pattern" |
related_to |
General association | "Both relate to authentication" |
mcp__daem0nmcp__link_memories(
source_id=<memory_id>,
target_id=<other_memory_id>,
relationship="led_to",
description="Optional context for the link"
)
When to link:
mcp__daem0nmcp__trace_chain(
memory_id=<id>,
direction="backward", # "forward", "backward", or "both"
max_depth=5
)
Use cases:
mcp__daem0nmcp__get_graph(
memory_ids=[1, 2, 3], # OR
topic="authentication",
format="mermaid" # or "json"
)
Returns a mermaid diagram or JSON structure showing nodes and edges.
mcp__daem0nmcp__unlink_memories(
source_id=<id>,
target_id=<id>,
relationship="led_to"
)
If the project uses OpenSpec (spec-driven development), the openspec-daem0n-bridge skill provides bidirectional integration:
Auto-detection: After get_briefing(), if openspec/ directory exists, specs are automatically imported as patterns and rules.
Before creating proposals: Use "prepare proposal for [feature]" to query past decisions and failures.
After archiving changes: Use "record outcome for [change-id]" to convert completed work to learnings.
See the openspec-daem0n-bridge skill for full workflow details.
Memories now auto-detect tags from content:
You don't need to manually tag common patterns.
For projects with many memories, use condensed recall:
mcp__daem0nmcp__recall(topic="authentication", condensed=True)
Returns compressed output (~75% token reduction):
Index your codebase:
mcp__daem0nmcp__index_project() # Index all code entities
Search code semantically:
mcp__daem0nmcp__find_code(query="user authentication")
Analyze change impact:
mcp__daem0nmcp__analyze_impact(entity_name="UserService.authenticate")
Only re-indexes changed files:
mcp__daem0nmcp__health()
Now returns:
code_entities_count: Total indexed entitiesentities_by_type: Breakdown by class/functionlast_indexed_at: When index was last updatedindex_stale: True if >24 hours since last indexMemory tools exist. Use them correctly.
Check context. Record decisions. Track outcomes. Link related memories.
This is non-negotiable when Daem0nMCP tools are available.