---
name: plugin-management
description: "Install, remove, enable, and configure plugins and account settings via conversation."
---

# Plugin Management

Manage plugins and account settings at any time via conversation.

## Claude Official Plugins

External Claude Code plugins (Stripe, Playground):

- Install: `claude plugin install <name>@claude-plugins-official`
- Remove: `claude plugin uninstall <name>@claude-plugins-official`
- List installed: `claude plugin list`
- List available: `claude plugin marketplace list`

## Claude Anthropic Verticals

Three optional plugins from Anthropic's vertical marketplaces, registered by the installer alongside `claude-plugins-official`. None are auto-installed; the user picks each deliberately during onboarding or by name later.

| Plugin | Marketplace | Install | Caveat |
|--------|-------------|---------|--------|
| `kyc-screener` | `claude-for-financial-services` | `claude plugin install kyc-screener@claude-for-financial-services` | Outputs are draft work product for human review. UK estate agents under MLR 2017 are AML-regulated; compliance specialist owns sign-off. |
| `meeting-prep-agent` | `claude-for-financial-services` | `claude plugin install meeting-prep-agent@claude-for-financial-services` | Overlaps with the business-assistant calendar-prep flow with FSI-flavoured templates — pick one path deliberately. |
| `pdf-viewer` | `knowledge-work-plugins` | `claude plugin install pdf-viewer@knowledge-work-plugins` | Interactive in-app viewer (v0.2.0). Click-through replaces conversation for this surface — different integration shape from the chat-driven skills. |

Removal mirrors install: `claude plugin uninstall <name>@<marketplace>`.

## {{productName}} Plugins

Built-in plugins under `$PLATFORM_ROOT/plugins/`:

- Enable: call `plugin-toggle-enabled` with `pluginName` and `action: "enable"`. Activates the plugin's behaviour embed and MCP server from the next session. Plugins with scheduled behaviour (declared via `lifecycle` in PLUGIN.md frontmatter) are activated automatically by the platform heartbeat within one minute — no separate setup command needed.
- Disable: call `plugin-toggle-enabled` with `pluginName` and `action: "disable"`. Deactivates from the next session. Any scheduled Events owned by the plugin (`sourcePlugin` field) are cancelled automatically by the platform heartbeat.
- The tool refuses core plugins (admin, memory, docs, cloudflare) and refuses plugins not installed under `$PLATFORM_ROOT/plugins/`. Direct `Edit` of `account.json` is forbidden by IDENTITY.md doctrine — `plugin-toggle-enabled` is the only legitimate path.

## Premium Plugins

Premium plugins are purchased separately and delivered from a staging area to the active plugin directory. Two MCP tools handle all premium plugin operations deterministically — no filesystem commands are delegated to the agent.

### Browsing available premium plugins

Call `premium-list`. It returns structured data for every plugin in the staging area: name, type (standalone/bundle), description, purchase status, and delivery status (per sub-plugin for bundles). Present the results as a plain numbered list, one entry per plugin, naming the plugin, its type, its description, its purchase status, and (for bundles) the delivery status of each sub-plugin.

### Plugin info before purchase

When the user asks about a specific premium plugin (e.g., "tell me about the teaching plugin"), check the staging directory for both `PLUGIN.md` (standalone) and `BUNDLE.md` (bundle). For standalone plugins, read `$PLATFORM_ROOT/../premium-plugins/{name}/PLUGIN.md`. For bundles, read `$PLATFORM_ROOT/../premium-plugins/{name}/BUNDLE.md` and present the bundle description, sub-plugin breakdown, and what each sub-plugin covers. This works before purchase — it helps the user decide.

### Recording a purchase

`purchasedPlugins` is an entitlement-bearing field: the effective list derives from the Rubytech-signed entitlement payload, not from raw `account.json`. IDENTITY.md doctrine forbids any agent write to `account.json`. Direct purchase recording is therefore unavailable to the agent.

- **Production path:** the Rubytech-side issuance endpoint signs an updated entitlement payload after a Stripe purchase event and delivers it to `~/<configDir>/entitlement.json`. The verifier picks up the new payload at the next session start.
- **Pre-launch / dev path:** the founder runs `node platform/scripts/generate-entitlement-fixture.mjs sign --account-id <id> --email <e> --tier <t> --plugins a,b,c --out ~/<configDir>/entitlement.json` to produce a signed test payload. The agent does not invoke this script.
- **Personal-mode installs (`brand.json.commercialMode: false`, the default today):** purchasedPlugins is read from raw `account.json` via implicit-trust mode. Pre-launch the agent has no way to add purchases without operator intervention; this is intentional during the gap before signed-issuance ships.

If the user asks the agent to record a purchase, explain that their purchase is processed by Rubytech billing and the entitlement payload arrives on their device automatically — no agent action is required.

### Delivering a premium plugin

Call `premium-deliver` with `pluginName` set to the plugin name. The tool handles everything:

- Validates the plugin name and checks purchase status
- Auto-detects standalone vs bundle (BUNDLE.md vs PLUGIN.md)
- For bundles: copies each sub-plugin from staging to `$PLATFORM_ROOT/plugins/`
- For standalone plugins: copies the single plugin directory
- Skips already-delivered sub-plugins (idempotent)
- Verifies each copy (PLUGIN.md exists and parses)
- Updates `enabledPlugins` in account.json (only newly delivered names)
- Scans for public agent templates
- Returns a structured result with per-sub-plugin status and available templates

Report the tool's result to the user. If templates are found, present them and ask whether the user wants to create any now. For template creation, run `skill-load skillName=public-agent-manager` and follow the "Create from Template" instructions, passing the template directory path from the tool's result.

If the delivered plugin has specialist agents (files in `agents/` with the `{plugin-name}--{agent-name}.md` naming convention, distinct from template directories), load the specialist management skill and follow the premium plugin agent activation instructions.

### On-demand template listing

Call `premium-deliver` for the plugin — it re-scans templates without re-copying anything (idempotent). The `templates` array in the result contains each template's display name, description, suggested slug, and directory path. `premium-list` returns purchase and delivery status but does not scan templates.

### Disabling a premium plugin or bundle

For standalone plugins and individual sub-plugins: remove the name from `enabledPlugins`. If the plugin has an `agents/` directory, load specialist-management and follow the deactivation instructions. Plugin files remain in `$PLATFORM_ROOT/plugins/` (permanent ownership — never removed).

When the user says "disable {bundle-name}" (e.g., "disable real-agent"), read the `BUNDLE.md` from staging, iterate the `plugins` array, and remove each sub-plugin name from `enabledPlugins`. When they say "disable {sub-plugin-name}" (e.g., "disable estate-coaching"), remove only that name.

## Account Settings

When the user asks to change output style, thinking view, effort, context mode, or model, call `account-update` with the field and value. Changes take effect on the next session.

| Setting | Field | Values |
|---------|-------|--------|
| Admin model | `adminModel` | Any Anthropic model ID (e.g. `"claude-sonnet-4-6"`) |
| Public model | `publicModel` | Any Anthropic model ID (e.g. `"claude-haiku-4-5"`) |
| Output style | `outputStyle` | `"default"` \| `"explanatory"` |
| Thinking view | `thinkingView` | `"default"` \| `"expanded"` \| `"collapsed"` |
| Effort | `effort` | `"low"` \| `"medium"` \| `"high"` \| `"max"` \| `"auto"` |
