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 agentmods add instructions/dimpagk92/cellar/agents-mdgit clone --depth 1 https://github.com/dimpagk92/cellarWhat 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 | $0.01296 | $0.01296 |
| Opus 5 | $0.00648 | $0.00648 |
| Sonnet 5 | $0.00259 | $0.00259 |
| Haiku 4.5 | $0.00130 | $0.00130 |
Grade A, and why
cellar AGENTS.md 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 2d 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- cellar CLAUDE.md — 95% identical, 7 lines differ
How it starts
The opening of the file, as written. The whole thing — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agent Working Memory
This repository should be built around four layers:
Sources / adaptersCEL OSS contractsCellar/Dilipod runtimeAgents
The durable OSS value is the context/memory/brief/receipt data plane, not one planner and not the live runtime itself.
The product direction is CEL as the context and trust layer for AI-operated software. Agents can plan in many ways; Cellar should make their context, memory, briefs, actions, verifications, and receipts reliable.
Repo Direction
- Sources and adapters should be easy to build and extend.
- OSS CEL should own context snapshots, merge contracts, memory contracts, brief assembly, transport schemas, and receipt schemas.
- The commercial runtime should own live cortex operation, policy, monitoring, compliance, and hosted execution.
- Agents should be pluggable: LangGraph, Mastra, Codex, Claude Code, GPT, Gemini, Cursor, n8n, or future in-house runtimes.
What CEL Owns
cel-context: fused context snapshot and merge contractscel-memory/cel-memory-sqlite: durable memory contract and local backendcel-brief: per-turn LLM brief assembly / budgeting / brief receipts- receipt, event, MCP, CLI, SDK, and N-API schemas
- the split between dispatch proof, model-input proof, and task completion proof
What The Commercial Runtime Owns
- live cortex operation, freshness, diffs, anomalies, source prioritization
- runtime capability reporting
- adapter lifecycle, dispatch, and policy enforcement in production sessions
- audit timelines, retention, alerting, compliance exports, and governance workflows
What CEL Does Not Need To Own Right Now
- one mandatory planner
- one mandatory orchestration runtime
- retry / branching / checkpoint policy as a repo-defining concern
Built-in planners and runners can exist, but they should be treated as clients, examples, or transitional implementations unless proven otherwise.
Boundary Rules
- Keep the agent boundary generic.
- Preserve stable context, action, result, receipt, and adapter contracts.
- Keep improving AX and the shared crates even when an app later gets an adapter.
- Prefer app-specific structured truth in adapters over forcing everything through generic UI perception.
- Do not make LangGraph, Mastra, or any single runtime the identity of the platform.
- Do not design evals so they only make sense for one agent backend.
- Treat
intent -> dispatch -> observed effect -> evidenceas the core trust loop.
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.
- 2d ago First seen · 110 lines · 1,296 tokens per session scan A 1cd19bc78706
cellar AGENTS.md is an instructions file published in the GitHub repository dimpagk92/cellar (4 stars, last pushed 22d ago), licensed Apache-2.0. It adds 1,296 tokens to every session, about $0.0065 per session on Opus 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-08-31.
Other instructions, from other repositories
ACCESSIBILITY.md AGENTS.md
Instructions for mgifford/ACCESSIBILITY.md, covering repository instructions for ai coding agents, scope, when each instruction file is useful, project mission and status and required project context.
ACCESSIBILITY.md copilot-instructions.md
Instructions for mgifford/ACCESSIBILITY.md, covering github copilot repository instructions, purpose and usefulness, required behavior, copilot-specific notes and where new copilot guidance belongs.
langgraph AGENTS.md
AGENTS.md instructions for langchain-ai/langgraph, covering agents instructions, corridor security analysis, libraries and dependency map.
agentgateway copilot-instructions.md
Copilot instructions for agentgateway/agentgateway: Do not check for, speculate about, or report compilation errors during code review. Compilation diagnostics from review are frequently incorrect; rely on CI to detect and report compilation failures.
Codex-Skills AGENTS.md
Instructions for TheGoat395/Codex-Skills, covering repository operating notes, required checks, evidence rules and change hygiene.
hatch3r CLAUDE.md
Instructions for hatch3r/hatch3r, covering hatch3r — development instructions, architecture, development commands, two-axis pillar framework (2.0.0) and orchestrator self-discipline (bypass protection).