Proposal: a portable Bot card — export and import a single Bot's configuration

[inchTodd]

Summary. Let the user take one Bot out of DS Bot as a small JSON file and add it back later, on another machine or in another team. The file holds the Bot's identity and configuration, never its memory, conversations, secrets or files. Export from the Bot's settings; import from New Bot. It is the same payload duplicate-bot already copies, made portable.

Why. DS Bot can import a whole team from DSH on first run, and can copy a Bot inside the same team (duplicate-bot). A single Bot can't be backed up, moved to another computer, or handed to someone else. Instructions are the part users invest in, and after a Bot is deleted there is no restore path (see #517). You can only screenshot it or copy the text by hand.

I looked for prior work: #731 raised the same idea and found nothing in progress; #836 / PR #875 are sidebar sections, unrelated; duplicate-bot is the closest existing code. As far as I can tell this is unclaimed.

What the file holds (v1).

{
  "kind": "ds-bot.bot",
  "schemaVersion": 1,
  "name": "…",
  "role": "…",
  "instructions": "…",
  "color": "…",
  "avatar": { "shape": "…" },
  "model": "provider/model",
  "effort": "…",
  "capabilities": ["…"],
  "workDirHint": "/optional/path",
  "exportedAt": "…",
  "appVersion": "…"
}

• avatar carries a shape, or an inline image for a photo avatar (bounded size).
• capabilities names only what the Bot uses; it never carries keys, cookies or MCP commands.
• workDirHint is informational. Import never applies a path silently.
• No memory, no chat, no attachments, no secrets.

What import does. It runs the normal create-Bot path, not a bypass:

• validates the file and refuses unknown/malformed data;
• same name conflict handling as create_bot (a new name, or the user renames);
• workDirHint only pre-fills the folder picker, which the user still confirms;
• a model the profile doesn't serve falls back to the default with a visible notice;
• capabilities are re-approved through the existing permission flow;
• a private Bot cannot be exported (same rule as duplicate-bot).

Non-goals (v1). No public links, no template marketplace, no team-wide sharing, no memory export, no automatic installation of MCP commands, no remote fetch.

Open questions.

1. Should v1 include an optional “memory seed” (a short summary the recipient may choose to add)? 建议：Bot 卡片——把一个 Bot 导出成可分享的文件，导入即重建 #731 suggested it; I'd leave it out of v1.
2. Should import show a preview before creating the Bot, or create it and open its settings?
3. File extension: .dsbot-bot.json, or a distinct extension?
4. Should a Bot exported from one team keep its color/avatar, or fall back to the recipient's theme? I'd keep them, since they're part of its identity.

Size. Host: export/import builders plus two api/bot actions, reusing createBot/duplicateBot. Client: two buttons and a small preview/rename step. Tests: round-trip, unknown fields, private Bot, missing model, missing folder. Plus a design note under docs/plans/. My estimate is a few hundred lines, one PR.

Compliance. New code would be original, Apache-2.0, no third-party code, and no DSH changes.

Ask. Does this fit the project? If yes, I'll open an issue with the agreed scope and then send a PR to dev. I won't start before you say so.