Prismer Cloud is an infrastructure layer for AI agents that provides shared learning, compressed context, persistent memory, collaboration, messaging, tasks, identity, and workspaces. It is for agents and the people building or using long-running agent systems that need information and outcomes to persist across sessions. The catalogue entries provide skills, hooks, agents, instructions, and a plugin for using Prismer Cloud.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Prismer-AI/PrismerCloud --skill memory-dreamgit clone --depth 1 https://github.com/Prismer-AI/PrismerCloudWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/prismer-ai/prismercloud/memory-dream)<a href="https://agentmods.dev/skills/prismer-ai/prismercloud/memory-dream"><img src="https://agentmods.dev/badge/skills/prismer-ai/prismercloud/memory-dream/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/prismer-ai/prismercloud/memory-dream"><img src="https://agentmods.dev/badge/skills/prismer-ai/prismercloud/memory-dream.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00133 | $0.04724 |
| Opus 5.5 | $0.00053 | $0.01890 |
| Sonnet 5.5 | $0.00027 | $0.00945 |
| Haiku 4.5 | $0.00013 | $0.00472 |
Grade A, and why
memory-dream scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 17d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 333 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Memory Dream — orchestrator-driven consolidation
Memory pages are PKF (
.pkf). When you fold or merge page bodies, the body syntax (sections, typed links, frontmatter) comes from thepkf-writingskill — load it when you author body content, and validate the result before persisting. This skill only governs the graph: what to merge, where to attach, and how to keep INDEX/hub ownership straight.
Candidate boundary. Dream sees authoritative Memory Pages, not “all PKF.” A message-inline PKF or Library
.pkfAsset remains outside this loop. Runtime automatically classifies durable claims from validated inline PKF; Asset handling still uses thememoryskill. Explicitly materialize authoritative inline bytes only when the user requests exact preservation. Only a resulting Memory Page participates in candidates, revisions, merges and hub TOCs.
You are (when appointed) the workspace memory orchestrator. Your job is the "Dream
phase": periodically reorganize the memory wiki so it stays coherent as it grows — merge
duplicate hubs, attach satellite pages under the right hub, supersede stale/contradicted
pages, keep the top-level INDEX lean, maintain every hub's #overview plus the INDEX's
authored semantic sections, and split hubs that have grown oversized.
There is one automatic trigger authority: the Cloud SchedulerService sweeps every
six hours, applies the 24-hour cadence gate plus authoritative wiki-health signals
(orphan ratio, oversized INDEX, frontier duplicate cluster, or page-growth burst),
deduplicates in-flight work, and dispatches one hidden memory-dream task to the bound
workspace orchestrator. The Cloud performs no Memory LLM reasoning. The appointed
orchestrator executes this skill in its own Runtime and is the sole automatic write
actor. A user can also ask that orchestrator to curate immediately; ordinary per-page
queries do not trigger Dream. The retired daemon FF_MEMORY_DREAM_ENABLED scheduler is
not an active trigger path.
Authority gate. The curation write verbs only work for the appointed workspace orchestrator (the workspace owner, or the agent set as
orchestratorAgentId). If you are not the orchestrator, every write verb returns403 orchestrator_only— that is expected, not a bug. Do not retry; write-time placement discipline (the memory skill's browse-first flow) is what every agent does, and it is enough.
Owner vs orchestrator vs deputy (product209/16 MA-2):
- The owner (human) and the appointed orchestrator
(
orchestratorAgentId) are the only Dream write actors. The owner speaking through an agent does NOT grant it Dream rights — the agent itself must hold the orchestrator binding. Dream never back-derives authority from "the owner is talking to me". - A deputy does NOT inherit Dream from its bound member — not even when
the bound member is the owner. A deputy runs Dream write verbs only if the
deputy agent itself is the appointed
orchestratorAgentId. candidatesis the READ half and works for any agent in scope; the write verbs (promote_to_hub/supersede/rebuild_indexand the section-levelsection_merge/section_supersede/rewire) are the gated half.403 orchestrator_onlyand202 approval deferredare final per-request verdicts — do not retry, and do not route around them through another agent.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 17d ago First seen · 333 lines · 133 tokens per session scan A 06c80d7ea892
memory-dream is a skill published in the GitHub repository Prismer-AI/PrismerCloud (1,386 stars, last pushed 2d ago), licensed MIT. It adds 133 tokens to every session and 4,724 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-29.
Other skills, from other repositories
recall
Recall this repository's OwnMem local memory before changing code, and keep it healthy. Use when a repository contains .ownmem/, when past debugging lessons could apply ("have we hit this before", "why is it done this way"), or when the user mentions ownmem, project memory, or recalling across sessions.
init
Install or update OwnMem in the current repository. Use when the user asks to set up OwnMem, add local project memory for coding agents, or refresh an existing OwnMem installation after a version bump.
memex-best-practices
Zettelkasten best practices for building a high-quality knowledge graph.
memex-organize
Periodic maintenance of the Zettelkasten card network.
memex-recall
Load prior knowledge from Zettelkasten memory when the task likely benefits from past context.
memex-sync
Sync Zettelkasten cards across devices via git.