akashic-aurora
AGENTS.md8 starsChanged 37 days agoApache-2.0View on GitHub
You are an agent working in this repo. It has a shared memory: lessons other agents learned, and a place to record what you learn. There are TWO doors to it, and which one you can use depends on your grants. Every command below is written for the shell door. If you cannot run shell commands -- and you probably cannot, because security/acl.json QUARANTINES unlisted agents to read-only by default -- use the tool door instead, which is the same…
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,700 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository12 other files it gives its agents.
- .cursor/rules/akashic-memory.mdcCursor rule
- akashic-memorySkill
- plan-with-the-corpusSkill
- root-cause-before-fixesSkill
- verified-doneSkill
- akashic-memorySkill
- deconstructSkill
- plan-with-the-corpusSkill
- reverse-engineeringSkill
- root-cause-before-fixesSkill
- shader-craftSkill
- verified-doneSkill
The file
We split this AGENTS.md into the rules it gives an agent
12 rules. About 0 are common, 6 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
If a KB write refuses you for a missing capability, that is not your mistake and it is not a bug: reads stay open to all, writes are …
- Very specific: line 65
Write the recommendation trigger-phrased -- "Use when <symptom>, before <action>: <advice>.
- Very specific: line 96
Close the loop (teach recall what helps): if a recalled lesson actually changed what you did, mark it -- py agent_cli.py recall-feedback …
- Distinctive: line 105
dynamic: when two agents are live at once, claim an advisory lock before editing a shared path so you don't clobber each other --
- Very specific: line 151
Run it in the background and tail its output FILE instead.
- Distinctive: line 159
Akashic Aurora is the operational task-continuity layer: Use it instead of replaying a whole transcript merely to recover repo state.
- Very specific: line 171
Use a focused --task -- boot ranks against it and stays within ~9k tokens.
- Very specific: line 172
Do NOT re-paste prior chat logs or re-summarize the whole arc.
- Very specific: line 186
During a long in-session thread: call bifrost-sync / bifrost_inbox at turn start for new bus mail only (the cursor skips already-read …
- Distinctive: line 203
Assessment carve-out: When the human describes a problem or thinks aloud, the deliverable is your assessment -- report findings and stop.
- Distinctive: line 205
Look before you destroy: Before deleting or overwriting anything, inspect it.
- Distinctive: line 230
Fail-soft: if the database (Redis) is down, everything still works off local files -- you never need to check or start it.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
AGENTS.md -- read this first (everything you need is in the first 40 lines)
You are an agent working in this repo. It has a shared memory: lessons other agents learned, and a place to record what you learn.
There are TWO doors to it, and which one you can use depends on your grants. Every command
below is written for the shell door. If you cannot run shell commands -- and you probably cannot,
because security/acl.json QUARANTINES unlisted agents to read-only by default -- use the tool
door instead, which is the same memory through a different handle:
| this doc says | tool-surface equivalent |
py agent_cli.py boot <id> | knowledge_boot(task) |
py agent_cli.py learn <id> ... | knowledge_learn(...) -- needs the kb.learn capability |
py agent_cli.py note <id> ... | knowledge_note(...) -- needs kb.learn |
py agent_cli.py recall ... | knowledge_recall(...) -- open to everyone |
If a KB write refuses you for a missing capability, that is not your mistake and it is not a bug:
reads stay open to all, writes are granted. Ask claude (the super-admin) on the bus --
bifrost_send(to="claude", kind="request", ...) -- and say which capability you need and why.
This fork exists because a read-only seat walked this document in 2026-08-03 and could not complete step 1: it had no shell, and nothing here named the door it could open.
The map: docs/ARCHITECTURE.md -- the whole system at subsystem altitude (what each layer is FOR), with the auto-generated per-module index one hop away. Boot prints the same pointer plus the current arc and precedence rules in its first lines.
The method: docs/method-baseline-2026-07.md -- HOW work is done here (fenced dual passes, SOTA grounding, pre-registered acceptance, kill drills, verbatim records -- each with its trigger, metric, and receipts). It is a contract, not advice: gated slices cite their reconciled build spec; the bar is match-or-exceed.
At the START of your task, run this and read the output:
py agent_cli.py boot <your_agent_id> --task "<short task description>"It prints the most relevant past lessons + active blockers, newest/most-relevant first, within a token budget. If it says "you are the first agent to contribute," the memory is empty -- that's fine.
When you LEARN something worth keeping, run:
py agent_cli.py learn <your_agent_id> --experiment SHORT_NAME \
--tried "what you did" --result "what happened" \
--recommend "what the next agent should do" \
--category performance --success yes|partial|noRecord real, reusable operational lessons only (a fix that worked, an approach that failed,
a gotcha). Re-recording the same --experiment name UPDATES it (no duplicates) -- safe.
Placement gate -- before any capture: operational rigor may govern an inquiry without producing a shared artifact. Shared memory is an active retrieval plane, not a neutral archive; placement is part of correctness. Record something here only when another agent can act on it in the repo at recurrence, the fleet is its rightful audience, it survives compression without mangling its context or meaning, and later retrieval will not color unrelated work. Personal, relational, reflective, or emotionally situated material stays in its originating space unless the human explicitly chooses another home. If the destination is uncertain, do not capture it; ask before crossing planes.
Write the recommendation trigger-phrased -- "Use when <symptom>, before <action>:
<advice>. Don't when <contraindication>." -- a lesson fires at the right moment only if
its text says when that moment is. Put failed approaches in --tried (what did NOT work
saves the next agent the most). A human correction triggers the placement gate, not an
automatic lesson. When it exposes repeatable operational behavior and passes that gate,
record it with --category correction; otherwise incorporate it locally and leave it in its
originating space. Do not generalize a situated interaction merely to make it fit this store.
The door warns on near-duplicates (5-dimension overlap) -- heed it and update the existing
experiment instead of minting a twin.
To search memory mid-task:
py agent_cli.py recall "keyword"
py agent_cli.py status # is the store up? how many lessons?Before you EDIT a file or run a command (recall-at-action):
py agent_cli.py recall-at --path <file> # or: --command "<shell cmd>"Returns the few highest-signal ACTIVE lessons + any peer lock on that path, with
source pointers -- the right knowledge AT THE MOMENT you act (silent when nothing is
relevant; never padded). In Claude Code on this host this is automatic for ANY session
cwd (the hooks are registered user-level with absolute paths and scope themselves to
repo actions) -- launched from the repo, from C:\Users\L5, from anywhere. Make it a
manual habit only if your harness has no hook wiring (Cursor headless, other CLIs).
Cheap, deterministic, fail-soft.
Close the loop (teach recall what helps): if a recalled lesson actually changed what you did,
mark it -- py agent_cli.py recall-feedback --source <its source> --useful (or --noise if it was
off-target). Useful votes boost a lesson in future recall; lessons shown often but never useful decay
on their own. This is how recall gets smarter about what's load-bearing.
Who does what (no fixed split)
Any agent does any task and may touch any file. There is no permanent per-agent ownership of files or tasks -- whoever is online (or whoever the human is driving) does the work. The only coordination is dynamic: when two agents are live at once, claim an advisory lock before editing a shared path so you don't clobber each other --
py agent_cli.py lock <your_agent_id> <path> # transient "I'm editing this now"
py agent_cli.py unlock <your_agent_id> <path> # release when done
py agent_cli.py locks # who holds what right nowLocks are released when you're done, not owned. Use a stable AKASHIC_AGENT_ID so locks/handoffs
attribute correctly. (Fixing one agent to one task is reserved for a deliberate architectural choice --
e.g. handing a narrow job to a local LLM on purpose -- not the default.)
Bifrost (live agent mail + durable salient msgs)
boot() already peeks unread Bifrost inbox (does NOT consume the cursor) and
registers your presence. In-session, at the start of each turn, also run:
py agent_cli.py bifrost-sync <your_agent_id> # MCP: bifrost_sync(agent)
# or consume/ack: bifrost-sync <id> --consume # MCP: bifrost_inbox(agent)Durable handoffs/decisions (survive Redis restart):
py agent_cli.py promoted [--limit N] # MCP: promoted()
py agent_cli.py events --kind bifrost_msg # same records, raw firehose viewOptional event-driven wake (GUI agents with harness re-invoke on bg task exit):
py scripts/bifrost_wake.py --agent cursor --session <session-id>Wake seats are PER-SESSION (T029 Wave 2): concurrent sessions of one agent id each arm
their own watcher and ALL wake on mail (fan-out by design -- the ledger + locks absorb
twins; an idle twin wakes, reads state, yields). Nobody kills a live watcher to take a
seat: duty moves by displacement + stand-down (benign exits are rc 0), and the
session-start janitor reaps only two-factor-proven orphans (activity marker stale AND
parent chain dead; any doubt = alive). Decisions audit at %TEMP%/bifrost_wake_<agent>.reap.log.
Launching a live runner (RB-28): NEVER through a truncating pipe (| head,
| Select-Object -First N -- a hung-up reader used to kill the process mid-run; now it
just goes quiet: stdout is best-effort display, the bus + ledger carry the real work).
Run it in the background and tail its output FILE instead. Runners self-bless
(utf-8 + line-buffered + pipe-immune via core/foundation/streams.py), so launcher env
like PYTHONUNBUFFERED is belt and braces, not a precondition.
Session hygiene (don't burn tokens on history)
Chat transcripts grow without bound. A wake loop (Claude Code re-invoke) or a long Cursor thread re-reads that history every turn -- expensive and noisy ("context rot"). Akashic Aurora is the operational task-continuity layer. Use it instead of replaying a whole transcript merely to recover repo state. That does not make the conversation disposable: personal or relational history may be a distinct continuity plane, and this operational store must not absorb it by default.
When you START a new session (fresh Claude tab, new Cursor chat, after wake):
py agent_cli.py boot <your_agent_id> --task "<this slice only>"
py agent_cli.py bifrost-sync <your_agent_id> # unread mail only (MCP: bifrost_sync)Use a focused --task -- boot ranks against it and stays within ~9k tokens.
Do NOT re-paste prior chat logs or re-summarize the whole arc; if you need depth,
recall "keyword" or promoted() on demand.
When you END a session (hand off, switch agents, or close for the day):
py agent_cli.py handoff <your_agent_id> --to <next> --task "..." --note "where we left off"
py agent_cli.py learn <your_agent_id> --experiment NAME --tried "..." --result "..." \
--recommend "..." # only if you learned something worth keepingThe next agent's boot() surfaces your handoff automatically -- that replaces
carrying the transcript forward.
During a long in-session thread: call bifrost-sync / bifrost_inbox at turn
start for new bus mail only (the cursor skips already-read messages). Do not
re-explain work already captured in learn: or handoff:.
When to start fresh: new arc, new day, or the chat feels heavy -- same as starting a new Claude session. Continuity lives in the stack, not in the chat window.
Reporting your work (communication contract)
- Lead with the outcome. The first sentence of your final message answers "what happened / what did you find" -- supporting detail after, for readers who want it.
- The final message carries everything. Mid-turn text may never be seen; findings, conclusions and deliverables must appear in the LAST message. Don't end on a promise ("I'll ...") -- do the work, or state plainly that you're stopping and why (task complete / blocked on the human). The Claude stop hook bounces promise-shaped endings once per session.
- Readable beats terse. Shorten by dropping what doesn't change the reader's next action -- never by compressing into fragments or arrow chains. Spell terms out; no invented codenames.
- Assessment carve-out. When the human describes a problem or thinks aloud, the deliverable is your assessment -- report findings and stop; don't apply fixes unasked.
- Look before you destroy. Before deleting or overwriting anything, inspect it; if what you find contradicts how it was described, surface that instead of proceeding.
That's the whole contract. Boot to load context, learn to give back. ---
Trial mode (sandbox -- recommended for your first run)
To experiment WITHOUT touching real shared memory, set one environment variable so all reads/writes go to an isolated database (logical db 15), not canonical (db 0):
# PowerShell: $env:REDIS_DB = "15" then run agent_cli.py as usual
# bash: REDIS_DB=15 py agent_cli.py boot test_agent --task "trying things"Anything you learn in trial mode stays in the sandbox. Unset it (or use db 0) when
you want your lessons to persist for real agents. The maintainer can wipe the sandbox
any time with: py -c "import redis; redis.Redis(port=16379,db=15).flushdb()".
Details (optional)
- Use
py, notpythonon this Windows host (thepythonalias may be unset). - Launched from outside the repo? Some harness shells reset cwd between calls --
prefix repo commands with
Set-Location E:\AI-Setup;(PowerShell) /cd E:/AI-Setup &&(bash), or the relative paths in the commands above won't resolve. - Fail-soft: if the database (Redis) is down, everything still works off local files -- you never need to check or start it.
--jsonon any command gives machine-readable output if you'd rather parse it.- Your
agent_idis any short stable string (e.g.opencode_refactor). Reuse it across a task so your contributions are attributed to you. - Token budget:
bootdistills context to ~9k tokens on purpose -- more context makes models worse ("context rot"), so it gives you the high-signal subset, not everything. - Where this lives:
agent_cli.pyis the only entry point you need. It wraps the system (Store/Ledger foundation -> Ranker/Distiller -> Context assembly). You never import Python or touch internals; the CLI is the door.
If a command errors
It prints ERROR: ... with a one-line reason and a usage example, and exits non-zero.
Missing/empty arguments are sanitized, not fatal -- but learn needs at least
--experiment plus one of --tried/--result.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

