███████╗██╗ ██╗██╗██╗ ██╗ ███████╗
██╔════╝██║ ██╔╝██║██║ ██║ ██╔════╝
███████╗█████╔╝ ██║██║ ██║ ███████╗
╚════██║██╔═██╗ ██║██║ ██║ ╚════██║
███████║██║ ██╗██║███████╗███████╗███████║
╚══════╝╚═╝ ╚═╝╚═╝╚══════╝╚══════╝╚══════╝
the RedDB.io marketplace
Plugins that teach agents how to use our products — the open-source engine, the managed cloud, the satellites we ship on top. One marketplace, one install.
One-line install — auto-updates on every Claude Code startup:
/plugin marketplace add reddb-io/skills && /plugin install reddb@skills
Install · reddb · reddb-cloud · Add a new plugin · Conventions
reddb reddb-cloud (future plugins …)
the engine the managed cloud red-graph · red-memory · red-cdc · …
open source reddb.io satellites on top of the stack
Highlights
🧠 Product-first — every plugin maps 1:1 to a RedDB.io surface
📚 Deep where it matters — reddb ships 7 reference docs (cheatsheet, collections, types, infra, AI, recipes)
🛰 Skeleton-friendly — start a new plugin small, deepen later (reddb-cloud is the example)
🔌 Marketplace-native — one /plugin install per surface, auto-updates on startup
🧭 Clear boundary — engineering meta-skills live in reddb-io/red-skills; this repo is products only
Sister repo:
reddb-io/red-skills— domain-agnostic engineering skills for code agents (autonomous loops, triage, TDD, diagnose, …). If a skill isn't about a RedDB.io product, it belongs there, not here.
reddb-io/skills ships as a Claude Code plugin marketplace. Add the marketplace once, install the plugins you want, and Claude Code pulls new commits at session start when auto-update is on.
Inside Claude Code:
/plugin marketplace add reddb-io/skills
/plugin install reddb@skills
/plugin install reddb-cloud@skills
Use the skills as native slash commands or auto-loaded context whenever the user touches RedDB, the cloud dashboard, or one of our SDKs.
Force a refresh without restarting:
/plugin marketplace update skills
Remove:
/plugin uninstall reddb@skills
/plugin marketplace remove skills
ℹ️ Plugins here are versioned semver-style in each plugin's
plugin.json. Auto-update users get new content at their next session — no action needed from them.
Product: RedDB — the AI-first multi-model database. Tables. Documents. Graphs. Vectors. KV. Time-series. Queues. One engine.
What this plugin teaches — the full engine surface, with practical depth on every layer that bites in real use:
| Doc | What it covers |
|---|---|
SKILL.md |
When to invoke, transport-first thinking, picking a query language, parameter binding, destructive-action rules. |
CHEATSHEET.md |
One-screen reference: deployment modes, 7 data models, 6 query languages, WITH clauses, HTTP endpoints, JS SDK, RedWire, migrations, indexes, probabilistic structures, cheatcodes. |
COLLECTIONS.md |
Deep dive on every user-facing model: Tables, Append-Only, Documents, KV, Cache, Graphs, Vectors, Time-Series, Hypertables, Continuous Aggregates, Queues (WORK/FANOUT), Events, Metrics. Plus indexes + probabilistic. |
TYPES.md |
The full type system. Standard + native (network, geo, locale, financial — Money/AssetCode, identity, visual, security — Secret/Password, cross-model *Ref types). |
INFRASTRUCTURE.md |
Embedded · Server · Server in Docker · Primary + Replica. Bind contract, vault, maintenance scheduler, commit policies (local/remote_wal/ack_n/quorum), writer lease, replica state machine. |
AI.md |
Embeddings (WITH AUTO EMBED + /ai/embeddings), inferences (/ai/prompt templates), ASK with every knob (STRICT, STREAM, CACHE TTL, LIMIT, DEPTH, fallback chains), credentials/vault (env vars, /ai/credentials, red_config, resolution chain), 11-provider matrix incl. Anthropic-embeddings policy and in-progress local provider. |
RECIPES.md |
17 end-to-end patterns: production RAG, TTL sessions, append-only audit, cross-model "what do we know about X", vector + pre-filter, queue workers, hypertables + continuous aggregates, eventual-consistency counters, CDC consumers, safe migrations, geo nearest, embedded-in-Node, provider switching, RedWire ad-hoc, probabilistic analytics, MCP exposure, DR rehearsal. |
If you ever ask an agent "how do I do X in RedDB?" — this is what answers.
Product: reddb.io — the managed offering. Same .rdb file format, same query languages, same drivers as self-hosted; operated for you (provisioning, backups, scaling, upgrades).
What this plugin teaches (skeleton — deepens as the cloud surface matures):
- Choosing cloud vs self-hosted for a given workload.
- The 5 steps to a working cloud database (signup → org → DB → connection string → connect).
- Connecting with
@reddb-io/client(JS),psql/pgx/etc. (RedWire), or rawcurl(HTTP). - Auth tokens — where they live, how to rotate, per-env isolation.
- What the cloud manages vs what you still own (notably: bring your own AI provider keys).
- When to defer to the
reddbplugin — every engine-side question (schemas, queries, embeddings,ASK) is identical to self-hosted, so we don't duplicate that here.
One marketplace per scope:
| Scope | Repo | Audience |
|---|---|---|
| Products (this repo) | reddb-io/skills |
Anyone using a RedDB.io product — even occasionally |
| Engineering meta | reddb-io/red-skills |
Engineers building software with code agents |
Inside this repo, one plugin per product surface. Plugins start as skeletons and deepen with use. reddb is the depth example; reddb-cloud is the skeleton example. Both ship today, both are honest about where the surface is shallow.
Inside each plugin, the SKILL.md is the agent-facing primary directive. Everything else (cheatsheet, references, recipes) is consulted on demand from there. Keep SKILL.md short and load-bearing.
Before adding a plugin, sanity-check the scope: is it about a RedDB.io product surface? If it's a generic engineering workflow, it belongs in reddb-io/red-skills, not here.
- Pick a plugin slug that names the product (
red-graph,red-memory,red-cdc, …). - Scaffold the layout:
plugins/<slug>/ ├── .claude-plugin/plugin.json └── skills/<slug>/ └── SKILL.md - Write
plugin.json— copyplugins/reddb-cloud/.claude-plugin/plugin.jsonfor the minimal shape. - Write
SKILL.md— frontmattername+descriptionis what the agent matches against. Body uses the<what-to-do>/<supporting-info>convention. - Add cheatsheet, references, recipes as the surface matures. Skeletons are encouraged — start small, deepen when you have signal.
- Register the plugin in
.claude-plugin/marketplace.jsonand add a section under the Plugins headings above.
Skills must be in English in committed files. Chat with users can be in any language.
skills/ ← repo root + marketplace
├── .claude-plugin/
│ └── marketplace.json ← lists every plugin
└── plugins/
├── reddb/ ← the engine
│ ├── .claude-plugin/plugin.json
│ └── skills/reddb/
│ ├── SKILL.md ← primary directive
│ ├── CHEATSHEET.md
│ ├── COLLECTIONS.md
│ ├── TYPES.md
│ ├── INFRASTRUCTURE.md
│ ├── AI.md
│ └── RECIPES.md
└── reddb-cloud/ ← the managed cloud (skeleton)
├── .claude-plugin/plugin.json
└── skills/reddb-cloud/
└── SKILL.md
- 🎯 One plugin per RedDB.io product surface. If two products share a workflow, the workflow gets its own plugin — not a hidden coupling between two.
- 📐
SKILL.mdis short and load-bearing. Long reference material lives in sibling docs (CHEATSHEET.md,TYPES.md, …) and is read on demand. - 🇬🇧 English in committed files. Chat with users can be any language.
- 🪶 Skeletons are fine. Better to ship a small honest skill today than a deep speculative one in three weeks.
- 🚫 No generic engineering skills here. Those live in
red-skills. - 🔒 No secrets, no host-specific paths, no env values in committed files. Examples use placeholder keys (
gsk_xxx,sk-...) and RFC 1918 /example.comliterals.
Apache-2.0. See LICENSE.