levara-memory-workflow git:20260807.429eeecA

Immutable. This exact content never changes and is served at /api/v1/blob/62a8682826a92420.

---
name: levara-memory-workflow
description: Automatically restore and curate durable project context through a Levara MCP server. Use implicitly for substantial coding, debugging, architecture, code review, SRE incident, operational investigation, and cross-session continuation work when Levara tools are available. At task start select the project collection and recall relevant context; before recommendations recall prior decisions; after verified outcomes save only durable decisions, discoveries, facts, preferences, advice, or dated events while excluding secrets, ephemeral state, code details, and duplicates.
---

# Levara memory workflow

Use Levara as durable agent memory, not as a transcript store or replacement
for source control, task tracking, or human documentation.

When this repository also loads [`AGENTS.md`](../../../AGENTS.md) or the server
returns `levara_instructions`, treat those as the canonical Levara playbook.
This skill is a portable client workflow: follow the stricter rule when they
differ, and never skip an immediate durable save required by the server
contract merely to stay under a soft write budget.

## Check availability

1. Prefer the native `levara` MCP tools.
2. Call `levara_instructions` once per session and follow the embedded server
   contract when it is stricter than this skill.
3. If Levara is unavailable, continue the user's task. Do not debug the
   connection unless requested; mention skipped memory synchronization only
   when it materially matters.
4. Never expose, retrieve, or copy Levara credentials while using memory.
5. Detect whether `supersede_memory` is available. Full history-preserving
   replacement requires a profile that exposes it (`memory`, `full`, or
   `long-horizon`). `core` and `workspace` support recall and `save_memory`
   only.

## Start substantial work

1. Derive a stable collection from the repository or explicit project name.
   Do not use an absolute filesystem path.
2. Call `set_context` with that collection.
3. Call `wake_up` with the default small token budget.
4. Recall the task topic before proposing architecture, revisiting a bug, or
   recommending an operational change. Filter by `room` or `hall` when known.
5. Use `get_project_context` only for broad onboarding or resuming after a
   long gap; avoid its larger payload during routine tasks.

Treat recalled memory as a lead, not current truth. Verify it against current
code, configuration, telemetry, or user direction whenever it may be stale.

## Recall while working

- Recall prior `decision` entries before making a competing recommendation.
- Recall `discovery` entries before debugging a previously touched subsystem.
- Recall `preference` entries when shaping deliverables or workflow.
- Use `search` for indexed knowledge beyond curated memories.
- Do not interrupt the task merely to narrate routine memory reads.

## Capture durable outcomes

Save explicit decisions, verified root causes, durable user preferences, and
significant dated events as soon as they become clear. At meaningful
milestones and before finishing, run a final capture check for outcomes that
were not already saved.

Save an outcome only when all are true:

1. It is likely to help in a future session.
2. It is supported by observed evidence, tests, current source, or an explicit
   user choice.
3. It can be stated atomically and concisely.
4. It is not better represented by source control, a task tracker, project
   documentation, or another authoritative system.
5. It contains no secret or unnecessarily sensitive data.

Choose the hall deliberately:

- `decision`: what was chosen and why, including the important tradeoff.
- `discovery`: symptom, root cause, fix, and validation.
- `fact`: stable objective information that is not a secret.
- `preference`: a durable user preference or working style.
- `advice`: a reusable rule learned from evidence.
- `event`: a significant milestone with an absolute date in the value.

Always set `collection`, `room`, and `hall`. Use a concept-oriented key, not a
filename or function name.

Before saving, search or recall similar memories:

- Skip equivalent duplicates.
- When a new outcome replaces an older live memory and `supersede_memory` is
  available, call `supersede_memory` with the old memory id. That tool archives
  the old row (`superseded_by` / `valid_until`) and inserts the replacement.
  Do not rely on `save_memory(supersedes_memory_id=...)` for replacement:
  that field is provenance only and does not retire the old row from recall.
- On `core` / `workspace` without `supersede_memory`, either overwrite the same
  key with `save_memory` (history is destroyed) or leave the old memory active
  and state that limitation. Never claim history-preserving supersession.
- Prefer at most three new memories per task as a soft noise budget. Exceed it
  whenever additional independent durable outcomes exist; never postpone a
  verified decision, discovery, preference, advice, or dated event that the
  canonical playbook would save immediately.
- Do not pin automatically. Pin only an explicitly declared global hard rule
  or a user-requested critical fact (including critical infrastructure the
  user asks to keep in wake-up).
- Respect host approval prompts for all writes; never bypass them.

Read [references/memory-policy.md](references/memory-policy.md) when choosing
between memory types, drafting a non-trivial entry, or deciding which system
should remain authoritative.

## Never save

- Passwords, API keys, tokens, private keys, credentials, or unredacted
  secrets.
- Raw chat transcripts, logs, stack traces, or large command outputs.
- Temporary TODOs, current progress, speculative guesses, or unverified
  diagnoses.
- File paths, function names, code snippets, commit history, or facts easily
  recovered from source control.
- Data the user asks not to remember.
- Entries that merely paraphrase existing memory.

## Finish transparently

Do not turn memory into a long status section. When a material memory write
occurred, add one concise sentence to the final response naming the collection
and captured memory types. Say nothing about Levara when no outcome passed the
durable-memory gate.