[Feature] Multiple skill instances per account (e.g. several Gmail or Notion connections)

[senamakel]

Summary

Allow multiple instances of the same skill (same package, e.g. Gmail or Notion) under one user account, so people can connect several mailboxes, workspaces, or accounts in one OpenHuman install and use them together.

Problem

Today skills are effectively keyed in a one-active-per-skill-id model: a single Gmail (or Notion, etc.) connection per skill package. Users who need more than one real-world account (work + personal Gmail, multiple Notion workspaces, duplicate integrations) cannot model that without workarounds.

Who it hurts: Power users, teams, and anyone consolidating tools in OpenHuman who already use multiple accounts with the same provider.

Constraints: Each instance needs isolated storage (SQLite/data dirs), credentials/OAuth state, and clear identity in the UI and agent layer so tools and memory do not cross wires. Backend proxy and OAuth flows may need a stable instance id (or equivalent) alongside skill id. Performance and security (token scope, auditability) must stay sound as instance count grows.

Solution (optional)

High-level directions (exact design TBD):

• Model: Introduce a first-class skill instance (or connection) entity: skill_id + instance_id (or slug), user-visible label, and per-instance data/credential paths.
• Core/runtime: Registry and lifecycle support multiple QuickJS (or future) runtimes per skill_id, or one runtime with multiplexed instance context—pick one approach and document it. Per-instance skills_data_dir and state keys already suggest a path: extend layout to skills_data/<skill_id>/<instance_id>/ (or similar).
• UI: Skills screen and setup flows allow Add connection for the same skill type; list, rename, disconnect per instance; agent/settings pick default or ask when ambiguous.
• Agent/tools: Tool calls and prompts must resolve which instance to use (explicit parameter, default instance, or disambiguation). May touch about_app capability catalog and agent prompts.
• Backend: If OAuth or proxy URLs are per-integration today, extend contracts so multiple integrations map to one account without conflating tokens.

Tradeoffs: more UX complexity, larger test matrix, migration for existing single-instance users (default instance preserves behavior).

Acceptance criteria

• Multiple instances — User can add at least two distinct instances of the same skill type (e.g. two Gmail or two Notion connections) and both remain active with separate credentials/data.
• Isolation — Data, SQLite, and tokens for instance A do not leak to instance B; tools cannot accidentally target the wrong instance without an explicit or resolved choice.
• UI — Clear listing, naming, and removal per instance; setup wizard can be completed independently per instance.
• Agent — Agent or tool layer can target the correct instance (by default, explicit selection, or documented disambiguation rules).
• Migration — Existing single-instance installs upgrade cleanly (e.g. implicit default instance).
• Docs — Architecture or user-facing note on multi-instance behavior and limits.

Related

• Skills runtime and registry (openhuman skills domain, QjsSkillInstance, workspace skills/ layout).
• OAuth/proxy flows if integrations are backend-scoped.
• src/openhuman/about_app/ capability catalog if user-visible capabilities change.