XMemo

View saved version →

---
name: xmemo-audit-progress
description: Verify project or agent progress claims against an approved baseline, XMemo context, and current artifacts. Use to identify evidence gaps, drift, blockers, and the next action; distinguish claims from verified completion.
---

# Audit Progress with XMemo

Measure reality against the approved baseline. Follow
**baseline → claims → evidence → reconcile → verdict → checkpoint**.

## 1. Recover the governing baseline

Use `recall_context`, `get_project_summary`, `search_memory`, and relevant
`todo` reads to recover the approved plan, criteria, decisions, last verified
checkpoint, and known blockers. Name the governing artifact or memory and flag
ambiguity before auditing.

## 2. Normalize progress claims

Break the report into atomic claims: changed, tested, deployed, reviewed,
documented, blocked, or deferred. Preserve source agent and artifact/version
when known, but do not treat identity as evidence.

## 3. Verify current evidence

Inspect available files, diffs, commits, tests, logs, deployments, or explicit
user confirmation. Classify each claim:

- **verified** — direct evidence satisfies the criterion;
- **partial** — some evidence exists, but the criterion is incomplete;
- **claimed** — asserted without adequate evidence;
- **stale** — superseded by newer state;
- **conflicting** — sources disagree and evidence does not resolve them;
- **blocked** — a named dependency prevents verification or completion.

Absence of evidence is not proof of failure. A local test is not deployment
evidence; a commit is not proof of hosted behavior.

## 4. Return a formal audit

Use:

1. **Audit scope and baseline**
2. **Verdict** — `on_track`, `at_risk`, `blocked`, or `not_verified`
3. **Claim matrix** — claim, status, evidence, gap
4. **Plan drift**
5. **Risks and blockers**
6. **Acceptance gaps**
7. **Exact next action**

When requested, create a durable Markdown report using
`assets/progress-audit-template.md`. Do not write a file for a report-only
request.

## 5. Reconcile XMemo from verified truth

With authorization, replace the checkpoint via `update_state`, complete or
update TODOs only when their conditions are met, record a milestone with
`record_event`, correct durable claims with `update_memory`, and preserve new
lessons with `remember`.

Never save the audit narrative as a transcript or mark completion from an
agent's confidence alone. Read
`../xmemo-memory-steward/references/review-playbooks.md`,
`../xmemo-memory-steward/references/workflows.md`, and
`../xmemo-memory-steward/references/tool-routing.md` for detailed contracts.

## Shared boundaries

Before any tool call, read and apply
[plugin boundaries](../xmemo-memory-steward/references/plugin-boundaries.md).
Use [tool routing](../xmemo-memory-steward/references/tool-routing.md) for unfamiliar
operations, [temporal queries](../xmemo-memory-steward/references/temporal-queries.md)
for dates or chronology, and [memory policy](../xmemo-memory-steward/references/memory-policy.md)
before writes. Reuse existing authorization; clarify only unresolved scope.
Report failed or unconfirmed operations without claiming success.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: xmemo-brainstorm
description: Explore options using relevant XMemo goals, constraints, decisions, and failed approaches. Use for brainstorming grounded in saved personal or project context; keep proposals tentative and persist only authorized outcomes.
---

# Brainstorm with XMemo

Create new options without losing the context that already shapes the work.
Follow **frame → recall → diverge → challenge → converge → preserve**.

## 1. Frame the exploration

State the problem, desired outcome, decision horizon, known constraints, and
what must remain open. Ask only for missing information that would materially
change the option space.

## 2. Recall decision-relevant context

Use `recall_context` for bounded background, `search_memory` for a named
decision or failed approach, and `get_project_summary` for a known project.
Retrieve goals, prior decisions, constraints, preferences, unresolved items,
and lessons—not broad history.

Label recalled items as current, potentially stale, or conflicting. Current
user instruction and verified evidence outrank saved context.

## 3. Diverge deliberately

Generate several genuinely different approaches. For each include:

- core idea and intended value;
- assumptions and dependencies;
- major trade-offs and risks;
- reversibility and cost of being wrong;
- evidence or experiment that would reduce uncertainty.

Do not quietly collapse to the first plausible answer or treat a previous
decision as immutable when the user explicitly reopens it.

## 4. Challenge and compare

Stress-test the strongest options against saved constraints and current
evidence. Identify contradictions, missing evidence, second-order effects, and
criteria that distinguish the options.

## 5. Converge with the user

Return:

1. **Problem frame**
2. **Relevant remembered context**
3. **Option set**
4. **Comparison and risks**
5. **Recommended direction**
6. **Open questions or experiments**
7. **Decision required from the user**

Keep the recommendation provisional until the user approves it.

## 6. Preserve only approved outcomes

If the user authorizes saving, route only the requested outcomes below.
Approval of a direction alone does not authorize persistence. Preserve the
actual decision status and do not manufacture an approval milestone:

- durable direction or rationale → `remember`;
- correction to an existing concept → `update_memory`;
- concrete follow-up → `todo`;
- unfinished exploration and unresolved choices → `update_state`;
- material approval milestone → `record_event`.

Preview writes when their scope remains unclear; do not reconfirm an authorized
batch. Never store the raw brainstorm, discarded alternatives as facts, or
unverified claims as decisions. Return a
compact receipt of what was saved, updated, or intentionally left tentative.

Read `../xmemo-memory-steward/references/review-playbooks.md`,
`../xmemo-memory-steward/references/memory-policy.md`, and
`../xmemo-memory-steward/references/tool-routing.md` when detailed policy or
routing is needed.

## Shared boundaries

Before any tool call, read and apply
[plugin boundaries](../xmemo-memory-steward/references/plugin-boundaries.md).
Use [tool routing](../xmemo-memory-steward/references/tool-routing.md) for unfamiliar
operations, [temporal queries](../xmemo-memory-steward/references/temporal-queries.md)
for dates or chronology, and [memory policy](../xmemo-memory-steward/references/memory-policy.md)
before writes. Reuse existing authorization; clarify only unresolved scope.
Report failed or unconfirmed operations without claiming success.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: xmemo-distill-session
description: Distill a session into concise decisions, durable context, actions, and resumable state for XMemo. Use when extracting outcomes or saving important session results; a summary-only request does not authorize persistence.
---

# Distill a Session to XMemo

Preserve what remains useful after the conversation disappears. Follow
**collect → classify → deduplicate → preview → write → receipt**.

## 1. Identify the durable boundary

Determine the subject, project or scope, and whether the user wants a summary,
a durable save, or both. Do not infer consent for sensitive or ambiguous
writes.

## 2. Extract outcomes, not chronology

Classify:

- final decisions and material rationale;
- stable preferences, rules, constraints, and definitions;
- verified facts, procedures, fixes, and lessons;
- concrete commitments and follow-up actions;
- unresolved questions, choices, or blockers;
- current verified state and exact next action.

Exclude raw transcripts, repeated explanations, long logs, large code blocks,
credentials, private traces, and speculative ideas that were not accepted.

## 3. Deduplicate and preview

Use `search_memory` or `recall_context` when duplicate or superseding content is
plausible. Prefer `update_memory` for a changed concept and `remember` for a
genuinely new durable concept.

When classification, replacement, or project placement is unresolved, preview
the affected candidates and clarify that scope. An explicit request to save a
clear batch already authorizes it. Label tentative and verified items separately.

## 4. Route confirmed outcomes

- new durable concept → `remember`;
- corrected durable concept → `update_memory`;
- concrete action → `todo`;
- unresolved blocker or unfinished state → `update_state`;
- significant milestone or handoff → `record_event`.

Use only routes supported by actual outcomes. Return saved, updated,
checkpointed, skipped, and unresolved counts plus the exact next action. Read
`../xmemo-memory-steward/references/workflows.md`,
`../xmemo-memory-steward/references/memory-policy.md`, and
`../xmemo-memory-steward/references/tool-routing.md` for details.

## Shared boundaries

Before any tool call, read and apply
[plugin boundaries](../xmemo-memory-steward/references/plugin-boundaries.md).
Use [tool routing](../xmemo-memory-steward/references/tool-routing.md) for unfamiliar
operations, [temporal queries](../xmemo-memory-steward/references/temporal-queries.md)
for dates or chronology, and [memory policy](../xmemo-memory-steward/references/memory-policy.md)
before writes. Reuse existing authorization; clarify only unresolved scope.
Report failed or unconfirmed operations without claiming success.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: xmemo-memory-steward
description: Save, recall, apply, correct, and manage the user's XMemo memories across conversations and agents. Use for remember this, what did we decide, saved preferences or knowledge, and mixed memory work; proactively recall when prior context materially affects a task. Guide planning, review, distillation, resume, and handoff through the companion skills when needed. Personal memories require no project.
---

# XMemo Memory Steward

This is the general entrypoint for saving and recalling memory. Handle ordinary
memory requests here; select a companion skill only when its specialized
workflow is needed. XMemo carries personal preferences, knowledge, decisions,
lessons, procedures, and work context across conversations and compatible agents.

Before any tool call, read and apply [plugin boundaries](references/plugin-boundaries.md),
including restrictions on health records, payment-card data, government IDs,
credentials, unnecessary context, and commerce. These apply to queries and
returned content as well as writes.

## When to recall, save, or stay quiet

- Recall when the user asks what was saved, refers to earlier discussions or
  another agent, resumes substantive work, or when remembered preferences,
  decisions, constraints, or lessons could materially change the answer.
- Apply useful recalled context to the current task, and briefly identify it
  when it influences the result so the user can correct it. The current user
  instruction and fresh verified evidence take precedence over old memory.
- Save when the user asks to remember information or clearly wants it carried
  forward. For a useful lasting preference or settled decision without clear
  saving intent, offer to save it in one short line instead of writing silently.
- An explicit correction to a saved fact authorizes updating that exact memory.
  A one-time exception or correction only to the current answer does not.
- Skip memory tools for casual chat, generic questions, and tasks saved context
  cannot change. Do not recall or save on every turn. A summary-only request,
  skill activation, or finishing a workflow does not itself authorize a write.

## Use this plugin's connection

Use only tools exposed by this plugin's authenticated XMemo connection. The host
may prefix tool names; match their names and current schemas, not tools on some
other account or similarly named connection. Never use a legacy or unexposed tool.
Read [tool routing](references/tool-routing.md) for unfamiliar operations.

Check available tools before saying XMemo is disconnected. Use `get_mcp_identity`
when account or authorization needs checking. If connection or a needed tool is
unavailable, say which operation could not run and direct the user to the host's
XMemo connection controls. Never request passwords, tokens, or OAuth codes in
chat. Continue from supplied material when useful, clearly without saved-memory
evidence; never simulate a successful save or recall.

## Recall and answer

Start with one appropriate read, rather than calling every retrieval tool:

| User goal | Tool |
| --- | --- |
| Quick question about something saved | `recall` with a focused `query` |
| Strict lookup of a decision, phrase, or particular fact | `search_memory` |
| Several related memories needed for a task | `recall_context` with bounded `max_items` and `max_tokens` |
| More content from an identified memory or Document | `read_memory` |
| Broad "what do you remember about me?" | `memory_overview()` without optional sections |
| Status of one exact authorized project | `get_project_summary` |
| Why an identified memory exists or matched | `explain_memory` |
| Count a word or phrase across stored memories | `analyze_memory_text` |

Use natural subject words and known names from the request or saved location.
Do not require a project, ID, or exact original wording for ordinary recall.
Keep queries relevant and exclude secrets. Check relevance before reporting:
narro

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: xmemo-plan-project
description: Create or revise project and execution plans using XMemo context and available artifacts. Use to turn goals into scoped phases, dependencies, and acceptance gates; distinguish proposed work from approved or completed work.
---

# Plan a Project with XMemo

Turn intent into reviewable, executable artifacts. Follow
**discover → recall → frame → decompose → gate → write → approve → checkpoint**.

## 1. Discover the planning surface

Inspect the live project or supplied artifacts before designing the plan.
Identify canonical documentation, existing plans, architecture, test and
release commands, ownership conventions, and dirty-worktree boundaries. If the
active surface cannot inspect them, label the baseline unverified instead of
inventing commands, paths, or completed work.

Clarify whether the request needs a strategic project plan, implementation or
migration plan, release plan, recovery plan, or both stable and executable
plans.

## 2. Recall relevant context

Use `recall_context` or `get_project_summary` for goals, constraints, decisions,
rejected approaches, risks, acceptance criteria, and latest verified state.
Use `search_memory` for exact decisions or lessons. Reconcile memory with live
evidence; do not use memory as proof.

## 3. Frame the project contract

Define:

- problem, users, and desired outcome;
- in-scope and explicitly out-of-scope work;
- current verified baseline;
- constraints and invariants;
- success measures and acceptance evidence;
- assumptions, dependencies, and unresolved choices.

Keep unresolved choices visible in the draft. If checkpoint saving is authorized,
preserve blocking choices in `update_state`; do not silently turn them into decisions.

## 4. Decompose executable work

For each independently reviewable phase include objective, rationale, exact
scope, artifacts, dependencies, owner, ordered steps, verification evidence,
acceptance gate, recovery path, and handoff condition. Keep implementation,
review, merge, deployment, and production verification as distinct states.

## 5. Design evidence gates

Map every requirement to tests, inspection, review, deployment evidence, or
user acceptance. Add security, privacy, compatibility, data-loss, migration,
and operational controls when applicable. Read
`references/plan-quality-gates.md` before producing a formal plan.

## 6. Write Markdown artifacts

Respect repository conventions. When none exist and the user requests files,
use:

- `PROJECT_PLAN.md` for stable purpose, scope, architecture, milestones, risks,
  and success criteria;
- `EXECUTION_PLAN.md` for ordered phases, status, evidence gates, ownership, and
  the exact next action.

Adapt `assets/project-plan-template.md` and
`assets/execution-plan-template.md`; do not copy irrelevant sections.

## 7. Review and approve

Return files changed, unresolved choices, assumptions, critical risks, first
acceptance gate, and exact next action. Label approval status accurately and
reuse approval already given in this task.
Use `$xmemo-review-plan` for a formal review.

## 8. Preserve the approved state

When saving is authorized, preserve only the requested record types. Plan
approval alone does not authorize these writes:

- save durable decisions and constraints with `remember` or `update_memory`;
- create only concrete near-term actions with `todo`;
- save the active phase, verified baseline, blocker, and next action with
  `update_state`;
- record material approval or a phase transition with `record_event`;
- create a formal XMemo project with `project` only when explicitly requested.

Do not mirror the entire plan into XMemo or mark planned work as implemented.
Read `../xmemo-memory-steward/references/memory-policy.md`,
`../xmemo-memory-steward/references/workflows.md`, and
`../xmemo-memory-steward/references/tool-routing.md` for write, checkpoint, and
routing rules.

## Shared boundaries

Before any tool call, read and apply
[plugin boundaries](../xmemo

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: xmemo-review-plan
description: Review a proposed plan against saved XMemo goals, decisions, constraints, and current evidence. Use for a plan critique or acceptance recommendation, not implementation progress verification.
---

# Review a Plan with XMemo

Test a proposal against durable context before execution. Follow
**scope → baseline → decompose → challenge → verdict → gate**.

## 1. Define the review contract

Identify the plan version, outcome, project or scope, decision owner, risk
tolerance, and required depth. Distinguish draft, proposed, approved, and
implemented states.

## 2. Recover the authoritative context

Use `recall_context` for the bounded decision set, `search_memory` for exact
constraints, `get_project_summary` for current project state, and `todo` for
active commitments. Retrieve only context that can affect the review.

Resolve conflicts by current user instruction, verified evidence, recency, and
scope. Use `explain_memory` when a decisive match or its provenance is unclear.

## 3. Decompose and challenge the plan

Map goals, assumptions, dependencies, sequencing, ownership, rollback,
verification, acceptance criteria, and unresolved choices. Check:

- alignment with saved goals and constraints;
- contradictions with settled decisions;
- missing evidence, dependencies, migration, or recovery paths;
- security, privacy, data-loss, compatibility, and operational risks;
- testability, observability, and release gates;
- duplicated completed work or ignored lessons;
- cross-agent ownership and handoff boundaries.

## 4. Return a formal review

Use:

1. **Plan and baseline reviewed**
2. **Verdict** — `recommended`, `changes_requested`, `blocked`, or `rejected`
3. **Critical findings**
4. **Required changes**
5. **Risks and assumptions**
6. **Missing evidence or decisions**
7. **Acceptance gate** — exact evidence required before approval or execution

Separate blocking findings from optional improvements. A favorable review is
a recommendation, not user approval or authorization to execute.

## 5. Preserve the outcome carefully

Keep the verdict and user approval distinct. If saving the review is authorized,
save its durable rationale with `remember` or `update_memory`. Use `todo`,
`update_state`, or `record_event` only for the separately authorized outcomes.
Approval of the plan alone does not authorize any of these writes.

Clarify unresolved write scope and return a receipt for authorized writes. Never
claim implementation or deployment merely because a plan passed review. Read
`../xmemo-memory-steward/references/review-playbooks.md`,
`../xmemo-memory-steward/references/memory-policy.md`, and
`../xmemo-memory-steward/references/tool-routing.md` for detailed rules.

## Shared boundaries

Before any tool call, read and apply
[plugin boundaries](../xmemo-memory-steward/references/plugin-boundaries.md).
Use [tool routing](../xmemo-memory-steward/references/tool-routing.md) for unfamiliar
operations, [temporal queries](../xmemo-memory-steward/references/temporal-queries.md)
for dates or chronology, and [memory policy](../xmemo-memory-steward/references/memory-policy.md)
before writes. Reuse existing authorization; clarify only unresolved scope.
Report failed or unconfirmed operations without claiming success.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: xmemo-work-continuity
description: Resume unfinished work or prepare and reconcile a cross-session or cross-agent handoff using XMemo context and current evidence. Use when continuing saved work, switching agents, or receiving a handoff; distinguish recovering context, preparing a brief, and actually continuing work.
---

# Work Continuity with XMemo

Choose the mode requested by the user; do not automatically run all three.
Ordinary fact saving and recall stay in `$xmemo-memory-steward`.

| Intent | Mode | Result |
| --- | --- | --- |
| Continue an identified unfinished task | Resume | Verified brief and authorized next action |
| Prepare work for another session or agent | Prepare handoff | Restart-ready package with provenance and access limits |
| Assess a received handoff | Receive handoff | Reconciled state, gaps, and acceptance recommendation |

## Recover and reconcile once

Identify the objective and relevant project, task, or artifacts. Use
`get_project_summary` for an exact project or `recall_context` for a bounded task
context. Add targeted `search_memory`, `read_memory`, or TODO reads only to close
a gap. Do not assume that another agent saved its work or shares the same tools.

Recover the goal, acceptance criteria, decisions, verified checkpoint, completed
work, open actions, constraints, blocker, and next action. Compare saved claims
with current files, tests, deployment evidence, and explicit user corrections
where available. Mark stale, conflicting, or unverified state; do not treat
an agent's confidence or an old checkpoint as proof. Resolve uncertainty before
dependent actions while continuing independent authorized work when possible.

## Produce the requested result

**Resume:** give a concise brief with the objective, verified state, work not to
repeat, decisions, open actions, blocker, next step, and sources. If the user
asked to continue and the next action is authorized, execute it. A request only
to report status or prepare a brief does not authorize execution.

**Prepare handoff:** include the same verified brief plus source and recipient
when known, artifact/version provenance, acceptance criteria, evidence, remaining
scope, access limitations, and the next review gate. Name local-only artifacts
that the recipient might not access. Preparing or saving this package does not
send it, establish receipt, or restore the original chat. Do not contact a
recipient without explicit sending authorization.

**Receive handoff:** compare incoming claims against the governing baseline and
current evidence; do not overwrite newer verified state. Return `accepted`,
`accepted_with_gaps`, `blocked`, or `rejected`, with reasons and the next action.
This is a local readiness recommendation, not proof of delivery or permission
to execute or persist anything. Continue only if requested and authorized.

Adapt the checkpoint and handoff formats in
[workflows](../xmemo-memory-steward/references/workflows.md) when useful; omit
irrelevant fields. Use [review playbooks](../xmemo-memory-steward/references/review-playbooks.md)
for disputed progress claims, or `$xmemo-audit-progress` for a full evidence audit.

## Persist only what was authorized

When checkpoint saving is authorized, replace the same scoped `update_state`
slot with the reconciled status. Use `record_event` only if recording the
occurrence is also authorized, and describe preparation as preparation rather
than completed delivery. Create a TODO only for an authorized concrete action.
Use `remember` or `update_memory` only for authorized durable outcomes. A
handoff-only request does not silently create every record type.

Return a receipt for actual writes, including partial failures and uncertainty.
Do not claim successful memory operations after a missing or failed tool call.

## Shared boundaries

Before any tool call, read and apply
[plugin boundaries](../xmemo-memory-steward/references/plugin-boundaries.md).
Use [tool routing](../xmemo-memory-stewar

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.