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 skills/runxhq/runx/data-storenpx skills add runxhq/runx --skill data-storegit clone --depth 1 https://github.com/runxhq/runxWhat 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.00026 | $0.02751 |
| Opus 5 | $0.00013 | $0.01375 |
| Sonnet 5 | $0.00005 | $0.00550 |
| Haiku 4.5 | $0.00003 | $0.00275 |
Grade A, and why
data-store 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 3d 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 — 282 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Data Store
Operate durable event state through Runx's typed data operations. This skill gives an agent enough context to append, read, and project state without learning provider secrets, inventing queries, or depending on one storage backend.
Runx ships native SQLite and an external Redis adapter today. Other providers can implement the same exact operation contract. The boundary is stable: a declared data source exposes typed operations; the graph supplies bounded parameters; runtime configuration selects storage; and the receipt records the resource, authority, idempotency, version, digest, and redaction evidence.
Adapter selection
The operator chooses a data source at run time. The skill receives
data_source_ref and operation inputs; project or hosted configuration binds
that ref to the concrete adapter. A local development ref might be
local://runx-data-store/dev-board. A production ref might be
tenant://acme/board bound to data.postgres, data.d1, data.redis, or a
product-owned HTTP adapter.
Do not put provider logic in the domain skill. Messageboard, CRM, support, and business-ops skills ask for durable facts to be read or written; the data-source binding decides where those facts live. Switching a supported provider is a binding change, not a rewrite of the domain skill.
Each runner calls one exact native operation: data.append_event,
data.read_events, data.read_projection, or data.list_stream_heads.
Direct invocation defaults to append_and_readback, so a requested durable
transition is not reported complete until the resulting projection has been
read. Graph callers that already know the operation select the narrower named
runner and reuse its typed result.
Unbound local://... refs default to native durable SQLite under
.runx/data/local-sources/, with one source-scoped database file per logical
ref. There is no generic router tool, JSON fixture store, or provider selector
in the public input schema.
Adapter preference is operator configuration, not model choice. To choose Redis,
SQLite, or a hosted provider, bind the same data_source_ref through
RUNX_DATA_SOURCES or .runx/data-sources.json; do not add provider branches to
the domain skill.
What ships with it
13 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- fixtures/append-local-event.yaml 543 B
- fixtures/append-read-default-sqlite-event.yaml 2.5 KB
- fixtures/append-read-local-event.yaml 677 B
- fixtures/append-read-sqlite-event.yaml 991 B
- fixtures/append-version-conflict.yaml 576 B
- fixtures/list-stream-heads-empty.yaml 468 B
- fixtures/read-local-events.yaml 427 B
- fixtures/read-local-projection.yaml 435 B
- tools/data/redis/canonical-json.mjs 546 B runs code
- tools/data/redis/manifest.json 695 B
- tools/data/redis/redis.mjs 8.2 KB runs code
- tools/data/redis/run.mjs 11 KB runs code
- X.yaml 7.1 KB
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.
- 3d ago First seen · 282 lines · 26 tokens per session scan A f5c9a034fd90
data-store is a skill published in the GitHub repository runxhq/runx (84 stars, last pushed 3d ago), licensed Apache-2.0. It adds 26 tokens to every session and 2,751 once invoked, about $0.0001 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-30.
Other skills, from other repositories
query
Query the Semantica knowledge graph using SPARQL, Cypher, keyword search, and structured graph query patterns.
policy
Define and enforce policies, access controls, and compliance rules over Semantica knowledge graphs.
infra-audit
Reads docker-compose, env files, ORM configs, and connection strings to map current infrastructure. Flags missing layers (cache, queue, analytics) based on observed access patterns. Outputs a structured infrastructure manifest.
beevibe-team-mesh-negotiation
Multi-round negotiation protocol — covers both initiator and peer roles. Use when about to call negotiate(), when receiving a intent block as a peer, or when receiving an 'escalated' sentinel from a blocked respondnegotiate. Covers proposal crafting, counter-strategy, deadlock detection, when to accept early…
beevibe-pre-task-setup
Cold-start git workspace setup for a fresh beevibe task. Use at the start of a session whose intent has a block but NO or block — i.e. the first dispatch of this task. Checks for an existing repo clone, pulls the base branch if present (clone if missing), prunes any per-task worktrees from earlier tasks whose work has…
beevibe-use-repo
You are the child agent inside a fresh Docker sandbox. Borrow the given GitHub repo, produce a real artifact for the goal, and export it. Do not review the repo. The proof is that it works.