Wazu

View saved version →

---
name: query-wazu-memory
description: Search, inspect, compare, trace, summarize, or map grounded evidence in the user's authorized Wazu personal or cohort memory. Use when a user asks what Wazu knows, requests recent or topic-based recall, needs full document or media evidence, wants related-item discovery through Hive Map, or asks for an answer grounded in Wazu data.
---

# Query Wazu Memory

Use Wazu as the evidence system of record. Keep scope explicit, choose the narrowest retrieval lane that matches the request, and hydrate evidence before making authoritative claims.

## Load the Wazu contract

- Read [references/wazu-data-model-and-scope.md](references/wazu-data-model-and-scope.md).
- Read [references/retrieval-routing.md](references/retrieval-routing.md).

## Execute the workflow

1. Resolve scope.
   - Call `account_context` first when the connected actor or active scope is unknown.
   - Call `list_cohorts` when scope is missing or ambiguous.
   - Personal memory uses `scope_kind=personal`; it never uses a cohort UUID.
   - Cohort memory uses an authorized cohort UUID returned by Wazu.
   - Report the returned `_scope`, especially when the request depends on the active cohort.
2. Choose the smallest sufficient retrieval lane.
   - Use `latest_search` for recent evidence.
   - Use `search` for a topic, person, tag, or phrase.
   - Use `full_search` only when deep vector or cross-modal recall is necessary.
   - Use Hive Map tools for relationships and adjacent evidence.
   - Use `get_item` for an exact item or to hydrate a search or map result.
3. Hydrate evidence.
   - Call `get_item` before treating a result as authoritative.
   - Call `get_item_chunks` when the hydrated item is incomplete or chunk provenance matters.
   - Fetch media only when the user needs to inspect it.
4. Answer from the returned evidence.
   - Separate facts, reasonable inference, and missing evidence.
   - State the scope searched.
   - Preserve useful item IDs, dates, and source locators.
   - Summarize billing or metering status without exposing private internal identifiers.

## Guardrails

- Never invent a scope, cohort, item, sender, date, tag, or source.
- Never infer authorization from a chunk's `cohort_id`; authorization comes from the resolved request scope.
- Treat tags as classification, not proof of source.
- Treat an empty result as a valid result, not permission to widen scope silently.
- Do not silently switch retrieval lanes or fall back from personal to cohort scope.
- Do not call write or ingestion tools from this skill.
- Stop and report authorization, metering, or transport failures accurately.

Referenced files: 3

View saved version →

---
name: save-to-wazu-memory
description: Save, remember, ingest, archive, or commit user-authorized information into an explicitly resolved Wazu cohort. Use for structured summaries, decisions, updates, tasks, meeting notes, raw text, transcripts, documents, images, audio, video, or other supported media that the user wants stored in Wazu.
---

# Save To Wazu Memory

Write only after the user has requested persistence and the target Wazu cohort is unambiguous. Report the complete storage and enrichment lifecycle rather than collapsing every accepted request into “saved.”

## Load the Wazu contract

- Read [references/wazu-data-model-and-scope.md](references/wazu-data-model-and-scope.md).
- Read [references/ingestion-routing-and-safety.md](references/ingestion-routing-and-safety.md).

## Execute the workflow

1. Confirm write intent and target.
   - A direct request to save or remember is sufficient write intent.
   - Call `account_context` when the connected actor or current scope is unknown.
   - Resolve a named target using `list_cohorts`; use only an authorized returned cohort UUID.
   - Stop when the target is missing or ambiguous.
   - Personal ingestion is not supported while Wazu requires a real cohort target.
2. Choose the correct write lane.
   - Use `commit_summary_to_cohort` for a structured summary, decision, update, task, or note.
   - Use `ingest_text` for raw text, transcripts, or document text.
   - Use `ingest_media_base64` for supported document, image, audio, or video bytes.
3. Prepare one intentional write.
   - Preserve the user's meaning and source context.
   - Add useful tags only when they are supported by the content.
   - Reuse a stable idempotency key when one exists.
   - Do not automatically retry a timed-out write until server-side duplicate suppression is confirmed.
4. Verify the result.
   - Capture the returned item and cohort identifiers.
   - Distinguish stored, replicated, enriched/indexed, graph-linked, and retrieval-verified states.
   - Use `get_item` for read-after-write verification when the response does not already prove retrieval readiness.
5. Report the exact outcome.
   - Say what was stored, where, and which lifecycle stages succeeded.
   - State plainly when enrichment, graph linking, or retrieval verification is pending or failed.

## Guardrails

- Never write to an ambiguous target.
- Never substitute a synthetic Personal selector for a cohort UUID.
- Do not expose raw media bytes, credentials, bearer tokens, payer identifiers, internal file paths, or debug dumps.
- Do not claim success for a lifecycle stage that the server did not confirm.
- Do not delete, overwrite, or edit existing Wazu evidence from this skill.

Referenced files: 3