Core Concepts
Four ideas explain almost everything about how AIStorageDepot works. Read these once and the rest of the docs will feel obvious.
1. It's a store and a connector — not an AI
AIStorageDepot holds the things you feed your AI — prompts, skills, rules, docs, templates, and configs — keeps them typed, versioned, and searchable, and hands them to your tools on request.
It does not run your prompts, follow your rules, or act on your content. That is always your AI's job. We're the shelf and the delivery van, not the worker. This matters because it sets your expectations correctly: putting a rule in your library doesn't make an AI obey it — you still have to give the rule to the AI (by downloading it into your project, or by asking your agent to read it).
2. The seven item types
Everything you store is one of seven kinds, and the only real difference is how you use it:
| Type | What it is | How the AI uses it |
|---|---|---|
| Prompt | a fill-in-the-blank message | you type /, fill the blanks, send |
| Skill | how to do a task | you ask, and the agent reads & follows it |
| Rule | an always-on standing order | it sits in your project and is always applied |
| Doc | reference material | the agent reads it on demand, when you ask |
| Template | the shape of a finished output (ADR, PRD, …) | referenced from a skill or prompt via @aisd:<slug>; inlined when read |
| Config | a setup / settings file | you download it and drop it where a tool needs it |
| File | any other file — ignore files, scripts, snippets | you store & tag it (with its own extension); download or read on demand |
You can also define custom types with their own format and file extension. See Item Types for the full treatment of each.
3. Two ways your library reaches your AI
There are exactly two paths, and every feature is one or the other:
- Live, over MCP. You connect your library once as an MCP server, and your AI reaches into it on demand — searching it, reading your rules and docs, and offering the items you've marked with / as slash commands. Always your latest version. This is the recommended path for most people.
- Downloaded / pulled. You export an item as a file (or run the
pullcommand) to get a local copy on your machine — no token needed at runtime. Good for rules that live in a repo, configs a tool expects on disk, or working without a connection to our servers.
Most workflows use MCP for the live stuff and a download only where a file has to physically exist somewhere (a rules file in your repo, an mcp.json your tool reads).
4. Live vs. frozen
This is the trade-off between the two paths above:
- The live (MCP) copy is always your latest version. Edit an item and your next request uses the new version — no re-syncing.
- A downloaded / pulled copy is a frozen snapshot from the moment you grabbed it. It keeps working with no token and offline, but it won't reflect edits until you download or
pullagain.
Neither is "better" — they solve different problems. Live = current and low-maintenance; frozen = reliable and self-contained.
Libraries
Your items live in libraries (workspaces). You'll see a few kinds:
- Your personal library — just yours. Nobody else can open it, search it, or reach it, including us in the app.
- Shared libraries — a Team plan gives your team one shared team library; Company plans add multiple teams and a company-wide library (see Teams & Companies). A shared library is visible to the people in that team or company, and to nobody outside it.
- The prebuilt AIStorageDepot Library — a read-only, ready-made set of prompts, skills, rules, templates, and configs you can browse and copy from. Free for everyone.
A library is the unit of access: you can read exactly the libraries you're a member of, plus the prebuilt one. Nothing crosses accounts — another customer can't see your items or even tell they exist. The two deliberate exceptions are the prebuilt library above (ours, not yours) and any share link you choose to create. See Security & Reliability for how that's enforced, and its limits.