Anthropic Knowledge-Work Plugins — what to adopt for IKA Concierge

Posture: Anthropic-published, open-source (Apache-2.0). File-based, no build step. Distributed via Anthropic's marketplace at claude.com/plugins (Cowork) and the claude plugin marketplace add anthropics/knowledge-work-plugins CLI command (Claude Code). 19.4k stars, 2.3k forks, active.

Scope: 11 role-shaped plugin bundles for knowledge-work job functions. Each plugin = plugin.json manifest + optional .mcp.json connector wiring + a commands/ folder of explicit slash commands + a skills/ folder of auto-activated domain knowledge.

Canonical structure:

plugin-name/
├── .claude-plugin/plugin.json   # Manifest (name, description, version, etc.)
├── .mcp.json                    # MCP server connectors
├── commands/                    # Explicit slash commands (/role:action)
│   ├── call-prep.md
│   ├── forecast.md
│   └── pipeline-review.md
├── skills/                      # Auto-activated domain knowledge
│   ├── account-research/SKILL.md
│   ├── draft-outreach/SKILL.md
│   └── competitive-intelligence/SKILL.md
├── CONNECTORS.md                # Human-readable connector docs
├── LICENSE
└── README.md

Installation model: marketplace-style. User picks a plugin → it lands in their Cowork or Claude Code instance → its skills auto-activate from context, its commands appear in the slash menu, its connectors offer to wire up.

Customization model: fork the repo, edit markdown, submit PR (community) or keep private (enterprise). README explicitly frames plugins as "generic starting points" meant to be tailored with company terminology, org structure, and workflows.

HR gap: no hr or people plugin. Our HR / People neuron stays IKA-original (or we build the first one and contribute back upstream).

Today the architecture page introduces four registries that hang off a neuron (in inheritance-down order): Integrations · Skills · Agents · Automations. Each has the same per-row schema (scope + overrides_parent + override_mode). What's missing is a bundle layer — the artifact a user picks once that installs all four at once.

Proposed entity

Link tables

• neuron_plugins — neuron_id, plugin_id, scope, overrides_parent, override_mode, installed_by, installed_at. Same shape as the other four neuron_* tables.
• plugin_skills — plugin_id, skill_id (the skills shipped by this plugin)
• plugin_commands — plugin_id, command_id (new entity, see below)
• plugin_integrations — plugin_id, integration_type (resolves to user's connected integration at install time)
• plugin_agents — plugin_id, agent_template_id
• plugin_automations — plugin_id, automation_template_id

Install semantics

Installing a plugin into a neuron is a transaction that fans out into five link-table writes (one each into neuron_skills, neuron_commands, neuron_integrations, neuron_agents, neuron_automations) plus the bundle row in neuron_plugins. All inherit-down by default; user can override individual components without uninstalling the whole bundle.

Uninstall semantics

Removing a plugin removes the bundle row and the five fanned-out rows. Components the user added separately (not via this plugin install) survive — distinguished by installed_via_plugin_id on each link table.

Anthropic's split between skills/ (auto-activated) and commands/ (explicit slash commands) is a clean categorical separation that our spec has been muddling. Examples from the current Per-neuron Skills table that are actually commands, not skills:

• /security-review, /qa, /codex, /learn — Operations / Engineering row
• skill-creator, skill-search — Universal row (the names sound like commands; they are explicit invocations)

Proposed schema

• commands — id, ika_id (NULL = global), name (e.g. call-prep, pipeline-review), plugin_id (NULL if standalone), descriptor_json, sha256, signature, license, vetting_tier, source_url.
• neuron_commands — neuron_id, command_id, scope, overrides_parent, override_mode, installed_by, installed_at. Same five-field inheritance shape.
• command_invocations — id, neuron_id, user_id, command_id, invoked_at, cost_tokens, outcome, trace_ref.

Inheritance update

The "Inheritance semantics" section grows from 4 link tables (neuron_integrations · neuron_skills · neuron_agents · neuron_automations) to 6 (add neuron_plugins · neuron_commands). All six share the same per-row schema. Plugin-install fans into the other five.

Why the split matters for the UX

Commands surface in the chrome — a slash-command palette, autocomplete on "/", visible in the per-neuron header. Skills don't have a UI footprint; they exist as system-prompt fragments the LLM draws on automatically. Mixing them today means the user can't tell which capabilities they can invoke explicitly vs which fire on their behalf.

Our 6 onboarding templates already declare default top-level neurons. Each Company-template neuron gets a recommended Anthropic plugin pre-installed (auto-allowed under Anthropic-shipped tier). Personal stays IKA-original; the rest get a mix.

Always-on at IKA root

• enterprise-search — cross-tool search across email/chat/docs is a universal capability, installs at the root neuron and inherits down everywhere.
• cowork-plugin-management → maps to our skill-creator + skill-search meta-skills (consolidate; see Watch below).

Anthropic's meta-plugin for authoring + customizing other plugins. Overlaps with our skill-creator (bootstrap draft) and skill-search (catalog search). Three open questions before specing v1 Plugin authoring UX:

1. What does their author workflow look like? Single command (/plugin:new)? Wizard? Scaffold + edit? Whatever shape converges most usage upstream is the shape we should mirror, so author-portability is preserved.
2. How do they handle versioning? Semver in manifest? Git tags? Catalog re-publish? Our skills.version field already exists; extending to plugins requires picking an upstream-compatible scheme.
3. How do they handle private vs public catalogs? Per-org plugin paths? Marketplace toggle? Our per-IKA private catalog already exists in spec (skills.ika_id NULL = global, else per-IKA); same shape extends to plugins.

Effort: 1-hour code-walk; decision: keep ours (draft → vet → publish; UI-driven) and import their authoring conventions only where they don't conflict. Defer v1 implementation until after Plugin entity + Commands entity land.

• Their lack of inheritance / scoping. Anthropic plugins install at the user's instance level — no neuron-equivalent. Our per-neuron scope + override machinery is a strict superset; never collapse it for the sake of "matching" upstream.
• Their lack of cost/budget governance. Plugins can call any LLM and any MCP server with no per-org cap. Our Token Stack + per-IKA cost cap stays the law of the land — wrapping all plugin invocations.
• Their lack of license enforcement. Several plugins reference MCP servers whose licenses are not declared in their manifests. Our license-required rule blocks ingest until the upstream PR adds it. Don't relax this.
• Their lack of sandboxing. Plugins run in-process in Cowork / Claude Code. We isolate via Firecracker (reusing Computer Use infra). Don't drop the VM boundary just because upstream doesn't have one.
• Sub-agents-in-prose. Their README implies sub-agents but doesn't formalize them. Our neuron_agents table is already richer; project plugin sub-agents into it.

Action plan

1. P1 — Plugin as 14th first-class entity. New table + neuron_plugins link table; manifest mirrors Anthropic's plugin.json. Anthropic catalog folded into the global catalog under anthropic_shipped vetting tier. ~1 day schema + ~1 day catalog ingest.
2. P2 — Command as 15th first-class entity. Split out from Skills. New table + neuron_commands link table. Migrate today's incorrectly-classified slash skills (/security-review, /qa, /codex, /learn) into commands. ~½ day.
3. P3 — Manifest compatibility. Speak .claude-plugin/plugin.json + .mcp.json on read + write. Lets any community plugin install into IKA; lets IKA-built plugins install into Cowork / Claude Code. ~½ day reader, ~1 day writer.
4. P4 — Six-template pre-install map. Update onboarding-template seed data: each Company-template neuron gets its Anthropic plugin pre-installed under the Anthropic-shipped tier. Personal stays IKA-original. ~½ day seed.
5. P5 — Inheritance semantics update. Extend the unified scope/override table to 6 link tables (was 4). One-line schema change + UX chip update. ~½ day.
6. P6 — cowork-plugin-management code-walk. 1 hour before specing v1 Plugin authoring UX.
7. P7 — Contribute back. Publish IKA's HR/People plugin + the 6 Personal plugins to the anthropics/knowledge-work-plugins marketplace once they're vetted. Net effect: IKA-original capabilities become free for the wider ecosystem; reverse-traffic into our marketplace listing.

Estimated effort

~4–5 days for P1–P5 (the core wire-format + entity work). P6 is 1 hour. P7 is post-v1.

What this unlocks

One-click install of any of Anthropic's 11 plugins into the matching IKA neuron. Marketplace flywheel: every plugin authored upstream becomes a candidate IKA capability (subject to our vetting). Lower onboarding friction: a new Company-template IKA arrives with 6+ proven role bundles already wired. Bidirectional marketplace presence: IKA plugins appear in Cowork + Claude Code, growing our distribution surface beyond direct sign-ups.

• Tier rename: the Anthropic-shipped vetting tier today refers to "official Anthropic Claude skills". Does it expand to mean "anything published in the official anthropics/* GitHub org including knowledge-work-plugins"? Recommendation: yes — same trust source.
• MCP credential reuse: a Slack connector wired for the sales plugin should be reusable by the marketing plugin in the same IKA. Today our integrations table stores credentials per integration type, and neuron_integrations projects per scope — so reuse is already correct. Confirm during P3 implementation.
• Plugin-level cost caps: should a Plugin row carry an optional monthly_token_budget? Lets the user say "spend at most $50/mo on the sales plugin". Today caps are per-IKA only. Defer to v1+ unless requested.
• Skill-evolution × plugin updates: when a plugin author publishes v1.2.0 of sales, what's the upgrade path for IKAs running v1.1.0? Manual / auto / opt-in? Default recommendation: auto-upgrade for Anthropic-shipped tier (hash drift alert still fires); manual for community-with-sig.