Docs / Item Types

Item Types

Everything you store is one of seven built-in types — or a custom type you define. The type decides how an item is formatted, how it downloads, and how your AI uses it.

Quick map:

Type	In one line	How the AI uses it
📝 Prompt	a fill-in-the-blank message	type `/`, fill the blanks, send
🧠 Skill	how to do a task	just ask — it reads & follows it
📏 Rule	an always-on standing order	sits in your project, always applied
📄 Doc	reference material	read on demand, when you ask
🧩 Template	the shape of a finished output (ADR, PRD, …)	referenced from a skill or prompt via `@aisd:<slug>`, inlined at read time
⚙️ Config	a setup / settings file	download & drop where it's needed
📁 File	any other file — with its own extension (.gitignore, .sh, …)	store & tag it; download or read on demand

📝 Prompts

A prompt is a message you'd send to an AI, saved once as a reusable template. Mark the parts you change each time with [brackets]:

Draft a cold outreach email from [sender] at [company] to [recipient] about [topic].

Those brackets become fill-in-the-blank fields. You reuse the prompt and fill the blanks, instead of rewriting it.

Default values. Give a field a default with =, e.g. [Environment = staging]. The fill-in form pre-fills it (still editable), and over MCP that argument becomes optional — the default is used when your agent doesn't supply a value. A plain field with no default stays a literal [Field] until it's filled.

While editing, you can mark any field required. Required fields show an * in the fill-in form and block Copy / Open in AI until they have a value — and over MCP they become required arguments, so your agent asks for them instead of running half-blank. (A field with a default is optional — the default covers it.)

Description. Give any item a one-line description — it's what your agent sees in the slash-command and resource lists, and it becomes the frontmatter of a downloaded command file.

Include another item with @aisd:<slug> — e.g. Follow @aisd:analyze-bug-template exactly. When the item is read (over MCP) or exported, the reference is replaced with that item's current content, so a thin command can delegate to a shared template you maintain in one place. It resolves to the copy in your nearest library (personal → team → company → the prebuilt library), and only ever to items you can read. Copy an item's handle from the chip by its title.

How you use a prompt:

In the app — open it, fill the fields, and copy the result, or Open in AI to open Claude/ChatGPT/Perplexity with it prefilled.
In your editor (over MCP) — mark it with / in the app and it shows up as a /aisd:… slash command that takes your input as arguments and fills the fields, asking for anything you leave out.

Bringing prompts in. Importing a Claude Code command file (or any file with $1 / $ARGUMENTS and YAML frontmatter) converts the positional args into [fields] and lifts its description automatically, so it lands as a first-class prompt.

🧠 Skills

A skill teaches your AI how to do a task — your code-review process, your way of writing release notes, a methodology. You don't fill it in; you point the AI at it.

How you use a skill:

Over MCP (recommended) — just ask in plain language: "do a code-review pass." The agent finds your skill and reads it. It works live, always your latest version, and you don't have to remember a command.
As a typed command — mark it with / in the app and it's a live /aisd:… command over MCP. Prefer a local, no-token copy instead? pull installs one as a file.

Unmarked, a skill is something the agent reads over MCP (just ask for it by name) — mark it / when you'd rather type it.

📏 Rules

Rules are standing orders your AI should always follow — "always use British spelling," "follow our TypeScript style," "never do X." Unlike a prompt or skill, you don't invoke a rule; it applies to everything.

A rule sitting in your library does nothing on its own. There are two ways to make it take effect, and both are explicit:

Download it into your project or user file — e.g. AGENTS.md or .cursor/rules/*.mdc in a repo, or a global config. From then on your tool loads it every session and the agent follows it automatically. "Project" scope applies to that repo; "user" scope applies across all your projects.
Ask for it over MCP — "follow my team's TypeScript rules." The agent fetches and applies it for that request. Per-task, not always-on.

📄 Docs

Docs are reference material — API notes, a style guide, background — that you want the AI to be able to read when relevant. You don't send a doc like a prompt; the agent reads it on demand, when you point it there ("check my API notes, then answer") or when it searches your library and finds it relevant.

A doc has no "always-on" mode. It's used only when the AI goes looking for it — which happens because you asked.

🧩 Templates

A Template is the shape of the output — what a finished ADR, PRD, release note, or postmortem should look like. Where a Doc is descriptive ("here's how our auth works"), a Template is prescriptive: "when you do this, emit it like this."

You don't run a template on its own. A skill or prompt points at one with @aisd:<slug>, and the template's current content is inlined for the agent at read time:

## Format

@aisd:adr-template

This is how you make our prebuilt items follow your house format. A reference resolves to your nearest copy — personal first, then your team/company, then ours. So copy a Template into your team library, edit it to match your standards, and every item referencing that slug — including our prebuilt skills — now emits your shape. No forking, no rewriting the skill.

The match is by name: keep the title the same as ours and your copy wins; rename it and it becomes a separate template instead of an override. Delete your copy and it falls back to ours.

Our prebuilt ADR Template, Release Notes Template, Postmortem Template, and PRD Template work exactly this way — the matching skills and prompts reference them rather than burying the shape inside themselves.

Bringing templates in. A markdown file with template in its name — adr-template.md, ADR Template.md — is imported as a Template, so our own downloads round-trip.

⚙️ Configs

Configs are setup and settings files — like an mcp.json. They're plumbing, not content the AI reads. You download a config and drop it where a tool expects it.

📁 Files

A File is the catch-all for anything that isn't a prompt, skill, rule, doc, template, or config — an ignore file (.gitignore, .dockerignore, .npmignore), a shell script, a snippet. Store it, tag it, and it's there to download or for the agent to read on demand. When you import files, ignore files land here automatically.

Every File picks its own extension. While editing, set the Extension field to whatever the file really is — gitignore, sh, agent, tar.gz — and it downloads as <title>.<that extension> instead of the default .txt. Imports set it automatically from the real filename, so a .dockerignore you drag in stays a .dockerignore on the way out. (Have many files of one kind? A custom type with its own extension is the better fit — the per-file extension is for one-offs.)

Custom types

If the seven built-ins don't fit, define your own type: give it a name, a format, and a file extension, and it behaves like the closest built-in. A custom type you create follows you into any team or company you administer.