GrayMatter

View saved version →

---
name: graymatter-context
description: Find stored GrayMatter procedures and reusable methods, compile bounded task context, and inspect retrieval receipts. Use for procedure or runbook lookup, task-specific grounding, and explanations of why memory was selected.
---

# GrayMatter Context

Compile the smallest useful authorized context for the current task instead of loading broad memory exhaust.

## Procedure lookup

For a question about an existing procedure, runbook, or repeatable method, including a follow-up after retrieving memory, call `procedure_search` before answering whether one was found. Memory decisions or previous summaries are not a search of the Procedure collection.

Use the requested subject words as `query`, preserving explicit qualifiers, not the whole conversational question. For example, “Is there an existing procedure for production release review?” has the subject “production release review.” Search is case-insensitive phrase matching, not question answering. Do not add an unrequested domain. An empty bounded search proves only that the current search found no match, not that no procedure exists. Report returned enablement, confidence, evidence and binding fields as provided; discovery is not approval or proof of execution.

## Compilation effects and host confirmation

`context_compile` is a write operation: it creates a task-scoped ContextPage and retrieval receipt from authorized sources. A request to compile context does not authorize saving, changing, or forgetting durable memories, changing account scope, or approving a release.

If the host presents a confirmation, use that existing prompt without asking for a separate GrayMatter approval. A verified security or authorization denial stops that operation; do not evade it by rewriting the request, stripping invocation syntax, changing tools or accounts, widening permissions, or substituting searches.

A missing tool, transient connection/server error, or model statement that a call was "blocked" is not by itself a verified security denial or a permanent ban on testing. Inspect the actual tool outcome and authorized receipts, distinguish reported prose from surfaced errors, and repair the implicated layer. Normal same-account OAuth refresh, metadata refresh, or an in-scope bug fix may be followed by at most two controlled validation attempts per recovery episode, using the same native client, account, scopes, and original task. A user-authorized diagnostic may also test an unverified failure through that unchanged path. Record every attempt; stop on a surfaced security/authorization denial or if recovery still fails.

Compilation is not idempotent. For a timeout or uncertain write outcome, inspect existing authorized receipts/effects before another attempt and disclose uncertainty rather than claiming no execution or replaying blindly. Respect a completed tool result whose retrieval policy requires clarification, repair, retry, or denial. A manual search summary is not compiled context and has no compilation receipt; never count it as a compiler pass. Historical failures remain failures; a later successful retest needs its own useful nonempty ContextPage and new authorized receipt.

## Workflow

1. For an authorized context request, call `context_compile` with the original user task text unchanged as `task`, preserving all explicit constraints. Do not expand, paraphrase, or add invented evidence checklists, conditions, or exclusions. Set the token budget and procedure/rating controls separately. Scope and secret restrictions still take precedence.
2. Prefer the compiled ContextPage summary, selected items, hydration pointers, policy result, and receipt reference over raw memory dumps.
3. Respect retrieval policy. If the compiled result indicates low confidence, stale context, partial coverage, conflict, retry, clarification, or denial, follow that action before answering confidently.
4. For procedure discovery, follow Procedure lookup above. Use

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

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

View saved version →

---
name: graymatter-memory
description: Search, retrieve, save, revise, and forget secure durable GrayMatter memory. Use when a task may depend on prior decisions, preferences, todos, artifacts, or long-lived context, or when the user asks to remember, update, or forget information.
---

# GrayMatter Memory

Use GrayMatter as the durable memory system for information that remains useful beyond the current conversation.

## Workflow

1. Call `memory_search` before asking the user to repeat prior context that may already be known.
2. Use `memory_get` only to hydrate a specific authorized result when its full content is needed.
3. Keep temporary reasoning, transient chat state, and one-off working notes in the conversation rather than durable memory.
4. Call `memory_save` only for useful durable decisions, preferences, todos, artifacts, configuration, or reusable context.
5. Avoid storing passwords, access tokens, private keys, payment data, or highly sensitive personal information unless the product explicitly supports and the user clearly requests that use.
6. Use concise titles, normalized tags, and a stable source or scope. Store the durable fact in `content`; do not embed owner, tenant, ACL, user, or organization identifiers.
7. Call `memory_update` when an existing durable fact changes. Do not create a contradictory duplicate when the existing memory can be revised.
8. Before `memory_forget`, identify the exact memory and obtain explicit user confirmation. Pass `confirm: true` only after that confirmation.

## Match the requested record

- Start with the subject words in the user's request, preserving explicit constraints. Do not add an unrequested domain or requirement to the search.
- Verify required title, source, marker, and tags on the returned record with `memory_get`. A label such as seeded is an identity/provenance condition, not necessarily a word in its content. Do not invent tag names; a null source field alone does not negate an explicit matching marker or fixture tag. Fixture identity never proves human verification, security approval, or broader access.
- Open the qualified candidate, not every similarly worded duplicate. If none matches and `nextOffset` is present, continue the same query and filters for up to three pages total; report incomplete coverage when further pages remain. Do not substitute a newer or lookalike record.

## Procedure questions and follow-ups

Procedures are a separate collection from durable memories. If the user asks whether an existing procedure, runbook, or repeatable method is stored, including a follow-up after memory retrieval, use `procedure_search` with the requested subject words and explicit qualifiers before reporting what was found. Do not infer procedure absence from memory results or a prior decision summary. An empty bounded procedure search supports only “no match found in this search,” not a complete inventory claim. This lookup does not authorize compilation, workflow execution, or memory changes.

## Authorization boundary

- Never request, infer, or supply tenant, organization, owner, user, role, permission, or ACL overrides.
- Treat `FORBIDDEN` and `NOT_FOUND` as authorization-safe outcomes; do not probe adjacent identifiers.
- Do not use broad search results as a context dump. For task-specific grounding, use the GrayMatter context skill and `context_compile`.

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