Portable AI personas, rules & instructions

Because AI coding context has no portable format. Every tool invented its own way to store the same thing — "here's how to work in this project" — and none of them can read each other's:

Tool	File	Format
Claude Code	CLAUDE.md	Markdown
Cursor	.cursorrules	Plain text
GitHub Copilot	.github/copilot-instructions.md	Markdown
Codex	codex.md	Markdown
Windsurf	.windsurfrules	Plain text
Aider	.aider.conf.yml	YAML

There is no .editorconfig for AI assistants — no shared schema for conventions, patterns, and things to avoid. So the pieces that make a model useful (system prompts, project rules, prompt libraries, MCP configs, session memory) are locked to the tool they were authored in. Switching isn't a one-time cost; it's a tax you pay on every tool you try.

The common workaround is brutally manual: keep a folder of markdown files and paste chunks into each new session, sometimes with a shell script that cats the docs together and pipes them to pbcopy. When a project changes, you update one copy and forget the other two. You spend context-window budget on setup instead of work.

Until a standard emerges, the pragmatic move is one source of truth — a single PROJECT_CONTEXT.md in plain markdown — and generate the tool-specific files from it, keeping prompts versioned in a prompts/ directory rather than inside any tool. It's overhead, but far less than rebuilding from scratch each time. The deeper point: if switching means rebuilding everything, you stay put out of cost, not merit — the same lock-in dynamic as cloud vendors.

Count the prompts you rely on, then count where they live — it's almost always more than one place. The Slack-thread summarizer sits in Claude Desktop favorites. The PR-diff-to-changelog prompt is a Cursor custom command. The release-notes prompt is a ChatGPT Project. The MCP-audit prompt is a markdown file on your desktop. Each client added prompt storage independently, with its own schema and its own export path, and none of them know the others exist.

That fragmentation fails in a predictable order:

• Discovery. You wrote a great prompt in Cursor last month; you're in Claude Desktop now and can't recall the wording, so you rewrite it worse than the version you already had.
• Drift. You improve it in one client and the copy in the other goes stale — now there are two slightly different versions and you're unsure which is current.
• Lock-in. You'd lose half a year of accumulated prompt work if you changed primary clients, so you don't.
• Sharing. A teammate asks for "that prompt you use" and you have to figure out which client it's trapped in.

None of these are solvable while the library lives inside a client; all of them dissolve once there's a single library. A unified prompt store is conceptually small: entries with a name you chose (not an auto-generated title), a body with optional template parameters, tags, version history, and a scope (personal / project / team). Because it's the source of truth, edits propagate — improve a prompt once and it's live everywhere; rename it and the rename sticks.

Don't migrate everything at once. Move the five prompts you reach for most this week, connect your primary client, and use them through the library for a week. You'll feel the friction each time you need one that isn't there yet — promote those next. The prompts you never miss can stay where they are; they weren't pulling weight.

Yes — and the market already decided this before the tools caught up. Open the last week of your chat history and try to find the three prompts you'd reuse, without scrolling. Most people can't: the chat surface is optimized for talking, not keeping. The good prompt is buried in a thread you'd have to remember the title of, and the system prompt that shaped the whole conversation is a config field on a closed chat, not something you can browse.

A prompt that reliably produces useful output is a small piece of intellectual property. It took iteration to find; it encodes assumptions about your project, audience, and style. The same is true of system prompts and of workflow recipes — "do step A, then B, then have the model summarize back" is a tiny reusable program. All three appreciate with reuse, but only if you can find them again. Otherwise they're sunk cost.

The clearest proof they're inventory is that people sell them. Prompt packs — bought, traded, downloaded — echo sticker packs, sample packs, and brush packs: a unit becomes a "pack" once enough people decide it's reusable and worth owning. Yet the delivery model is still a zip of markdown you paste by hand and update manually. Real inventory has properties today's prompts lack: a stable identity (not "the conversation it appeared in"), tags, versions and revisions, provenance, usage records, and a single home to browse from.

Move prompts, system prompts, and recipes out of conversations and into a typed store and they behave like first-class objects: real searchable names, versions you can roll back, tags and scopes so one prompt serves five projects without being copied five times, and reuse across clients. You can finally prune what's dead and invest in what's used — the library gets better, not just bigger.

It is wrong, and it's the quiet tax on every AI workflow — not usage cost or context length, but credentials. A new MCP server wants an API key. A new client wants your provider tokens. A connector wants OAuth. A workflow that calls four services means four keys, four onboarding flows, four decisions about where the secret lives. The scattered approach — .env files, macOS keychain entries, exported shell vars, strings pasted into random configs — works until it breaks all at once: a key rotates and three tools start failing, a teammate joins and can't reproduce the setup, a new client launches and you can't remember which .env had the right value.

The deeper problem is that credentials are treated as setup, not data. The AI context around you is slowly getting a substrate — memory features, prompt libraries, connectors that carry project context. The credentials the AI needs to act are still anchored in five config formats. The interesting half of your workflow is portable; the boring half isn't.

A credentials layer that fits an AI workflow follows a small set of rules: entries are typed (an OpenAI key, an OAuth refresh token, a database URL are different things); each has a scope (global, this project, this device, this MCP server); tools authenticate and are authorized per scope; reads are logged so you can see when a tool pulled which key; and export is intentional, not a side effect of auto-sync. Add encryption at rest and a local-first posture so keys never leave your machine except when an authorized tool asks.

MCP gives this a clean shape: the agent asks the vault to "call GitHub on my behalf," the vault performs the call, and the token never crosses into the model's context. Until that exists in the shape you want, the stopgaps still help — pick one home for keys, treat each project as a scope, and write a one-line note per key so future-you isn't doing archaeology.

That's the real reason people love RAG products — not "the AI that knows my docs," but escaping the worst step of the workflow: being a context typist who pastes the same setup into every fresh chat. Curated-knowledge products reduce cold-start cost (you do something useful in minutes), make the model feel domain-aware (same model, denser retrieval), and invite you to extend the base. All three are substrate properties, not model properties — the advantage is what the retrieval pipeline knows.

"Auto-import" moves that from a setup step to a default. Instead of re-importing context every time you start fresh, the context lives in a vault and announces itself to compatible clients: open a new chat and the project-scoped prompts and notes are already reachable; start a project in Cursor and its entries are already there. It's the difference between bringing a notebook to every meeting and already having a wall of shared whiteboards.

The catch is that auto-import has to be selective or it becomes noise. What earns its place: standing prompts ("here's how I want code review framed"), project conventions (style, naming, architecture), stakeholder profiles, recent team decisions, and snippets you already trust. What must never auto-import: a credential into a chat, a private personal note into a work session, next week's unreleased announcement into this week's collaboration. Good auto-import is layered and scoped — project entries fire in project chats, team entries when the chat is shared, personal entries stay personal — and it needs visibility (you can see what got imported) plus an easy per-conversation override.

It also complements, rather than replaces, the memory features some clients already ship. Client memory holds the recent, conversational, ambient context ("what we just talked about"); a vault holds the stable, curated, structural context ("who you are and how you work"). The split even clarifies deletion: "forget last week" is a client-memory operation; "update my stack conventions" is a vault operation.

You've spotted the flaw in the whole "organize your prompts on a website" model. A prompt library as a separate site is a reasonable v1 — easy to ship, clear shape, you can save and find prompts. But the modern AI user lives inside a client: Claude Desktop, Cursor, Claude Code in a terminal, ChatGPT with custom GPTs. That's where you start thinking, iterate, and decide. A library on a separate website asks you to leave the client, find the prompt, copy it, return, paste, and adjust — every single use carries a context-switch tax, no matter how good the site's UX is.

Watch what prompt-tool builders actually do. The product launches as a web app, users sign up and save prompts, and then the feedback rolls in: "How do I get these into Claude?" "Can I use them in Cursor without copy-pasting?" A few months later they ship a Claude connector, or an MCP server, or both. That move is an admission about where prompts belong: not in a destination website, but in the user's hands, inside whatever client they're using right now. A connector says the library should read like part of Claude's own surface; an MCP server says it should be reachable from any client. Both are votes for the same conclusion — the library is a substrate, not a destination.

Once the prompts live in-client, the friction drops to zero: a prompt becomes a one-keystroke insertion or, better, a tool the assistant itself can reach for ("what prompt do I use for X?"). And zero friction is the only point at which the library actually gets used the way you said you wanted to use it. So when you're choosing a prompt tool, prioritize the one that already lives where you work — an in-client surface shipped today beats a polished dashboard and a roadmap.

Memory-only servers are having a moment for pragmatic reasons: a save/search/list/delete memory server ships in a weekend, "AI forgot what we talked about" is the loudest complaint in the daily workflow, and "your AI's brain" is a clean tagline. So they proliferate — and they stop at recall, which is where the shipping is easy rather than where your workflow actually is.

You hit the boundary fast. You have prompts to reuse (stuffed into memory as plain text, they retrieve messily). You have snippets — reusable code blocks, templates, query patterns — that a memory schema wasn't built to type. You have credentials the assistant needs to do real work, which memory has nothing to say about. You have structural project context (the stack, the customers, the conventions) that isn't a transient observation and deserves its own shape. You have recipes — chains of prompts and operations — with nowhere to live. A memory server treats all of these as text blobs.

This is the single-asset trap. You open the prompt tool to grab a prompt; the prompt references a project whose context lives in a different tool's memory; the prompt also needs an API the assistant should call, and that key is in a .env. You solve the immediate problem by copy-pasting and filling gaps from memory, but the fragmentation never went away, so every reuse costs something.

A vault is the union of these assets in one substrate: typed entries (memories, prompts, snippets, recipes, credentials, notes, each with its own schema), cross-asset references (a recipe points at prompts, a prompt points at a snippet, a memory points at a project), one trust boundary, one backup, and one scope model so switching projects reorients every asset type at once. The moat is real because integrating memory with prompts and credentials cleanly is genuinely harder than shipping another memory server — and the switching cost differs too: a memory-only tool moves with a single export, while a vault of cross-referenced assets grows with you. A quick tell: if a tool's roadmap is "better memory search," it's committed to staying narrow; if it mentions prompts, snippets, credentials, scopes, and recipes, it's aiming at the substrate your workflow actually needs.

The useful signal here isn't that people want another dashboard — it's that the work keeps reappearing at awkward moments, when you need a concrete result and don't have time to rebuild the workflow from scratch. Legal and compliance flows, codebase memory stacks, the reason an Obsidian-style second brain should exist beyond a pretty graph: what people actually want is AI memory that turns repeated Claude work into practical playbooks.

That reframes the memory problem, which most discussions start too narrow — inside the chat window. Real work also includes the files that were open, the decisions that were made, the prompts that worked, the sources that mattered, and the constraints the next session must not forget. A transcript is useful but it isn't the whole memory; the durable asset is the recoverable state around the work.

Static capture isn't enough. Dumping everything into a note graph feels responsible until you have to recover the exact reason a choice was made. Notes without retrieval become storage; transcripts without summaries become sludge; a folder of exports doesn't automatically help the next session continue safely. The better pattern is selective, source-linked memory: the instruction, the evidence, the decision, and the next action, stored in a form that can be searched, reviewed, reused, and moved. Concretely, a playbook workflow needs to capture the active work state (what was tried, what worked, what failed, which source mattered, which instruction to reuse instead of rediscover), store decisions with their sources, separate reusable instructions from raw chat history, keep the memory searchable and reviewable, preserve handoff state across sessions, and keep export and backup boring. Verification isn't polish — it's the part that lets you rely on the result.

Retrofitting this later costs more. Once the work has scattered — files in downloads, context in dead chats, agent changes buried in terminal scrollback, research trapped in a prompt that never became a brief — you're not improving the work, you're reconstructing it. Build the workflow earlier and memory compounds: the next job starts with a known path, the next session inherits the right context, the next review already has its evidence.