Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use Cortex decision memory through the normal Memtrace MCP tools. Trigger for free-text questions about what was decided, chosen, rejected, banned, or established as a convention; for why a symbol exists or which contracts constrain it; for whether a known decision held, drifted, or was violated; and for the implementation arc behind a decision. Use before non-trivial edits, refactors, deletions, or re-picking a library, pattern, architecture, or subsystem behavior. Routes internally across reca
.claude/skills/syncable-dev-memtrace-decision-memory/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-10 | ✗→✓ | ▲ Improved | 105% | 0% |
| case-13 | ✗→✓ | ▲ Improved | 51% | 0% |
| case-16 | ✗→✓ | ▲ Improved | 131% | 0% |
| case-17 | ✗→✓ | ▲ Improved | 75% | 0% |
| case-18 | ✗→✓ | ▲ Improved | 85% | 0% |
BEFORE you assume why code exists, contradict a convention, re-pick a settled
choice, or delete code that "looks unused/weird" → CHECK DECISION MEMORY.
recall_decision(free-text) → what did we decide / ban about X?
why_is_this_here(symbol_id) → what decision put this here?
verify_intent(decision_id) → did that decision still hold, or was it violated?
get_arc(decision_id) → what episodes implemented it?
governing_contracts(sym_id) → what constraints bind this symbol?This is the rationale layer of the codebase. memtrace-first answers what the code is and how it's wired (symbols, calls, git, blast radius). Decision memory answers why it is the way it is, what we already decided, and whether that decision still holds — extracted from real coding conversations and decisions, not the AST.
The graph can tell you a function exists and who calls it. Only decision memory can tell you that three weeks ago you banned the approach you're about to reintroduce.
Full parameter spec for every Memtrace tool: references/mcp-parameters.md (bundled at the memtrace-skills plugin root).
These five tools are deterministic, zero-LLM. Every call returns a labeled Verdict / Evidence / CannotProve answer carrying its FactStatus and proof path. No tool ever fabricates an answer.
| Answer | What it means | What you must NOT do | |---|---|---| | Verdict + Evidence (Observed / DeterministicallyDerived / StatisticallyRanked) | A recorded decision/provenance backs this | — | | CannotProve | No recorded decision governs this | Do not read it as "safe / approved / unconstrained." It means unknown, not permitted. Fall back to memtrace-first + asking the user. |
CannotProve is a real, trustworthy answer ("memory has nothing on this"), not a failure and not a green light. Never invent a rationale to fill the gap.
These tools are exposed on the normal memtrace MCP server: recall_decision, why_is_this_here, verify_intent, get_arc, and governing_contracts. Hosts do not need a second MemCortex MCP connection. If a tool call returns CannotProve because Cortex is unavailable (for example native Windows without WSL2), say decision memory was unavailable/unknown and continue with memtrace-first; do not fabricate decisions.
| What you're about to do / be asked | Right tool | Procedure | |---|---|---| | "Did we already decide/choose/reject X?" "What's our convention on Y?" | recall_decision("X") | Free-text recall | | "Is there a ban / a 'don't do this' on Z?" | recall_decision("Z") — bans surface as decisions | Free-text recall | | About to edit behavior, re-pick a library/pattern/architecture, or change a subsystem policy | recall_decision FIRST — don't re-litigate a settled call | Free-text recall | | "Why is this code here?" "Why is it done this odd way?" | why_is_this_here(symbol_id) | Symbol provenance | | About to delete/refactor/clean up existing code, especially odd or "dead" code | why_is_this_here + governing_contracts before touching it | Symbol provenance | | "What rules/contracts constrain this symbol?" | governing_contracts(symbol_id) | Symbol contracts | | "Did decision D actually hold, or did we drift?" | verify_intent(decision_id) | Intent verification | | "What commits/episodes implemented decision D?" | get_arc(decision_id) | Implementation arc |
Only recall_decision takes free text. The other four take numeric node ids (decision_id / symbol_id, uint64). The normal flow is:
recall_decision("auth strategy")
│ returns ranked hits, decisions first: [{ id, kind: "decision", ... }]
│ (pick a kind:"decision" hit; conversation hits are context, not chainable)
├─► verify_intent(decision_id) did it hold?
└─► get_arc(decision_id) what implemented it?
why_is_this_here(symbol_id)
│ returns the governing decision lineage for a symbol
└─► verify_intent(that decision_id) is that rationale still valid?symbol_id comes from a prior recall/arc result or the Cortex view — if you only have a name or a free-text question, start with recall_decision. Do not invent ids.
recall_decision("<symbol/subsystem>") first.symbol_id, why_is_this_here(symbol_id) → the governing decision, if any.governing_contracts(symbol_id) → constraints that must survive a rewrite.verify_intent(decision_id) to see if it still holds.memtrace-impact (blast radius) and the user.recall_decision("X") → did we already decide or ban this?verify_intent(decision_id) → is it still in force?ViolatedAt/superseded one — and say so explicitlyverify_intent(decision_id) → Held | ViolatedAt | CannotProveget_arc(decision_id) → the episodes that implemented (or should have) it| Thought | Reality | |---|---| | "This code looks unused, I'll delete it" | why_is_this_here first — a decision may govern it; deletion may reopen a closed issue | | "I'll just edit/refactor this existing behavior" | recall_decision("<behavior/subsystem>") first — the change may violate a recorded decision or ban | | "I'll just use library/pattern X" | recall_decision("X") — you may be undoing a deliberate ban | | "The diff/git log will tell me why" | Git shows what changed, not what was decided or rejected. Decision memory has the rationale and the bans. | | "CannotProve, so it's fine/approved" | CannotProve = unknown, not approved. Don't treat absence of a record as permission. | | "I'll guess the rationale from the code" | Don't fabricate a why. Return what the tool proves, or say it's unknown. |
This is a process skill — it runs alongside memtrace-first before implementation. Use memtrace-first for what/where/impact (code graph); use decision memory for why/whether-it-held (rationale). When both apply, decision memory gates the intent, the code graph gates the mechanics.
The routing outcome: which sibling skill/tool to invoke, and the evidence to quote.
Ask: "Should I switch to library X?"
Route: recall_decision("library X") → free-text recall
Hit: { id: 4217, kind: "decision", ... } (a ban exists)
Next: verify_intent(4217) → intent verification
Quote: Verdict + Evidence (FactStatus, proof path) — or CannotProve = unknown, not permission| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 20,771 | 5,573 | -73% | 1 | 1 | 0% | 2,537 | 2,145 | -15% | 0 | 0 | — |
case-02 | fail→fail | 14,176 | 27,794 | +96% | 1 | 1 | 0% | 1,447 | 2,161 | +49% | 0 | 0 | — |
case-03 | fail→fail | 17,132 | 3,974 | -77% | 1 | 1 | 0% | 2,835 | 2,191 | -23% | 0 | 0 | — |
case-04 | fail→fail | 10,797 | 5,670 | -47% | 1 | 1 | 0% | 1,676 | 2,128 | +27% | 0 | 0 | — |
case-05 | fail→fail | 14,641 | 5,121 | -65% | 1 | 1 | 0% | 2,434 | 2,434 | 0% | 0 | 0 | — |
case-06 | pass→pass | 11,823 | 3,481 | -71% | 1 | 1 | 0% | 1,683 | 2,403 | +43% | 0 | 0 | — |
case-07 | fail→fail | 10,990 | 5,549 | -50% | 1 | 1 | 0% | 1,709 | 2,125 | +24% | 0 | 0 | — |
case-08 | fail→fail | 10,535 | 6,319 | -40% | 1 | 1 | 0% | 1,549 | 2,371 | +53% | 0 | 0 | — |
case-09 | fail→fail | 12,302 | 9,178 | -25% | 1 | 1 | 0% | 1,412 | 2,098 | +49% | 0 | 0 | — |
case-10 | fail→pass | 9,213 | 4,914 | -47% | 1 | 1 | 0% | 1,348 | 2,763 | +105% | 0 | 0 | — |
case-11 | fail→fail | 3,591 | 2,135 | -41% | 1 | 1 | 0% | 553 | 2,292 | +314% | 0 | 0 | — |
case-12 | fail→fail | 8,868 | 5,271 | -41% | 1 | 1 | 0% | 1,241 | 2,130 | +72% | 0 | 0 | — |
case-13 | fail→pass | 13,235 | 6,791 | -49% | 1 | 1 | 0% | 1,933 | 2,915 | +51% | 0 | 0 | — |
case-14 | fail→fail | 11,732 | 3,900 | -67% | 1 | 1 | 0% | 1,785 | 2,142 | +20% | 0 | 0 | — |
case-15 | pass→pass | 12,038 | 3,519 | -71% | 1 | 1 | 0% | 1,587 | 2,492 | +57% | 0 | 0 | — |
case-16 | fail→pass | 8,425 | 5,854 | -31% | 1 | 1 | 0% | 1,242 | 2,866 | +131% | 0 | 0 | — |
case-17 | fail→pass | 8,488 | 3,110 | -63% | 1 | 1 | 0% | 1,364 | 2,387 | +75% | 0 | 0 | — |
case-18 | fail→pass | 9,135 | 8,743 | -4% | 1 | 1 | 0% | 1,485 | 2,752 | +85% | 0 | 0 | — |
case-19 | fail→pass | 15,738 | 3,366 | -79% | 1 | 1 | 0% | 2,393 | 2,402 | +0% | 0 | 0 | — |
case-20 | pass→fail | 10,170 | 8,275 | -19% | 1 | 1 | 0% | 1,520 | 2,401 | +58% | 0 | 0 | — |
case-21 | fail→fail | 19,996 | 6,318 | -68% | 1 | 1 | 0% | 2,642 | 2,167 | -18% | 0 | 0 | — |
case-22 | pass→fail | 3,581 | 25,457 | +611% | 1 | 1 | 0% | 469 | 6,249 | +1232% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 9 counted toward the lift figure. The other 13 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +18 percentage points is the difference between those two pass rates over the 9 comparable cases. 4 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.