Skip to main content

AgentBoot Delivery Methods — Analysis & Recommendations

How organizations install, configure, and use AgentBoot.

The short, factual version: AgentBoot compiles personas into platform-native formats (Claude Code, Codex, Copilot, and the officially supported cross-tool AGENTS.md output, plus community-tier formats like Cursor) and distributes them across an org's repo fleet. The shipped delivery channels today are:

  • agentboot sync — the hub writes generated files directly into target repos ("the repo already has it"); works for every platform.
  • Claude Code plugin — agentboot build emits a loadable plugin at dist/plugin/; orgs serve it from their own marketplace repo.
  • Managed settings — dist/managed/ output for MDM-pushed HARD guardrails (Claude Code only).

See Getting Started for setup and Org Connection for the hub-and-spoke model.

The rest of this page is strategy analysis, not a feature list. It evaluates delivery channels — including some that are design-intent rather than shipped — through the lens of the real adoption challenge: an org with power users, skeptics, and non-engineers. Where a mechanism is not yet implemented, the text says so.

The User Spectrum​

Every organization adopting agentic development has these user segments:

SegmentProfileWhat They NeedPriority
Power UsersAlready use Claude Code daily, have custom CLAUDE.md, write their own agentsComposable primitives, not hand-holding. Control and extensibility.HIGH
Willing AdoptersEngineers open to AI tools but haven't gone deepZero-config start, immediate value, gradual depthHIGH
Skeptics / Hold-outsEngineers resistant to AI tools, prefer their workflowProof of value without disrupting their workflow. Opt-in, not forced.MEDIUM
Non-EngineersPMs, designers, compliance, marketingGUI-first, no terminal, structured formsLOW (but in scope)
IT / Platform TeamDeploy tooling, enforce compliance, manage fleetCentralized control, MDM, audit trail, zero-touch deploymentHIGH

AgentBoot must serve all five — but through different channels, not one monolithic installer.

Delivery Methods​

What it is: AgentBoot packaged as a Claude Code plugin, installable from a marketplace (public or private). Bundles skills, agents, hooks, rules, and MCP servers into a single distributable unit.

How it works: agentboot build emits a loadable, spec-conformant Claude Code plugin at dist/plugin/. The org commits it to its own marketplace repo (a plain Git repo carrying a .claude-plugin/marketplace.json — see Org Connection), and developers install from there:

# User adds the org's marketplace (once)
/plugin marketplace add acme-corp/acme-personas

# User installs the org plugin
/plugin install acme

# Or org IT force-enables it via managed settings

The canonical public AgentBoot repo is agentboot-dev/agentboot — the registry's default public channel points there. A ready-made public plugin marketplace (installing the generic core plugin without building it yourself) is not yet published — see the roadmap phases below. Today the plugin channel means your marketplace serving your built dist/plugin/ output.

Plugin structure:

agentboot-plugin/
├── .claude-plugin/
│   └── plugin.json              # name, version, description
├── agents/
│   ├── code-reviewer/CLAUDE.md
│   ├── security-reviewer/CLAUDE.md
│   └── test-generator/CLAUDE.md
├── skills/
│   ├── review-code/SKILL.md
│   ├── review-security/SKILL.md
│   ├── gen-tests/SKILL.md
│   └── agentboot-install/SKILL.md # Interactive install wizard
├── hooks/
│   └── hooks.json               # Audit trail, compliance hooks
├── .mcp.json                    # Knowledge base, domain tools
├── .lsp.json                    # LSP servers (if any)
├── settings.json                # Default agent, permissions
└── README.md

Private marketplace for orgs:

The org creates a private marketplace repo with their customized AgentBoot config:

// .claude-plugin/marketplace.json
{
  "name": "acme-personas",
  "displayName": "Acme Corp AI Personas",
  "owner": { "name": "Acme Platform Team" },
  "plugins": [
    {
      "name": "acme",
      "source": "./plugins/acme",
      "description": "Acme-customized AgentBoot with HIPAA compliance",
      "version": "1.0.0"
    }
  ]
}

Engineers install with:

/plugin marketplace add acme-corp/acme-personas   # private GitHub repo
/plugin install acme

IT force-enables via managed settings:

{
  "enabledPlugins": { "acme@acme-personas": true },
  "extraKnownMarketplaces": ["https://github.com/acme-corp/acme-personas"]
}

Serves:

SegmentHow
Power UsersFull access to plugin internals; can fork/extend
Willing AdoptersOne command install; /agentboot:review-code works immediately
SkepticsIT can force-enable; value appears without opt-in effort
IT / PlatformCentralized marketplace; version pinning; managed settings

Pros:

  • Native CC distribution — no external tooling needed
  • Namespace isolation (/agentboot:review-code) prevents conflicts
  • Version-controlled via marketplace with semantic versioning
  • IT can force-enable via managed settings — zero developer setup
  • /reload-plugins picks up updates without restart
  • Settings.json in plugin sets default agent, permissions
  • Private marketplace supports enterprise authentication (GitHub, GitLab, Bitbucket)
  • Already the standard way CC users install extensions

Cons:

  • Claude Code only — doesn't help Copilot/Cursor users
  • Plugin skills are namespaced (/agentboot:review-code not /review-code)
  • Requires CC 1.0.33+ (but this is already old)
  • Plugin marketplace is relatively new; some orgs may not be familiar

Verdict: This should be the primary delivery method for Claude Code users. It maps perfectly to AgentBoot's plugin architecture (agents + skills + hooks + MCP + rules).

2. CLI Tool (agentboot)​

What it is: A Node.js CLI that scaffolds, builds, and syncs persona configurations. The current approach but needs refinement.

How it works:

# Bootstrap a new org personas repo
agentboot install

# Create hub with specific org
agentboot install --hub --org acme

# Build compiled output
agentboot build

# Sync to target repos
agentboot sync

# Generate a Claude Code plugin from your config
agentboot export --format plugin

# Generate cross-platform output
agentboot export --format cross-platform

Key insight: The CLI is the build tool, not the delivery mechanism. It produces artifacts (plugins, .claude/ directories, copilot-instructions.md) that are delivered through other channels.

Serves:

SegmentHow
Power UsersFull control over build pipeline; scriptable
Willing Adoptersagentboot install gets them started
IT / PlatformCI/CD integration; agentboot build && agentboot sync in pipeline

Pros:

  • npx means zero install — try it immediately
  • Scriptable for CI/CD pipelines
  • Platform-agnostic output generation
  • Can generate Claude Code plugins, Copilot instructions, Cursor config
  • Familiar pattern for Node.js developers

Cons:

  • Requires Node.js (not universal)
  • Terminal-only — excludes non-engineers
  • Another tool to learn for engineers who just want personas

Verdict: Essential for the build/admin workflow but not the end-user experience. Engineers interact with the plugin or .claude/ output, not the CLI directly.

3. Git Template Repository (Current Approach)​

What it is: The current AgentBoot repo is a GitHub template. Orgs create their private personas repo from it.

How it works:

gh repo create my-org/my-org-personas --template agentboot/agentboot --private --clone
cd my-org-personas
npm install
# Edit agentboot.config.json
npm run build
npm run sync

Serves:

SegmentHow
Power UsersFull repo control; can customize everything
IT / PlatformCentral governance repo; version-controlled

Pros:

  • Full ownership of the personas repo
  • Git-based governance (PRs, reviews, history)
  • Works without any AgentBoot runtime dependency
  • Familiar GitHub template workflow

Cons:

  • Higher friction than agentboot install — clone, configure, build, sync
  • Requires understanding of the entire system before getting value
  • End developers never see or interact with this repo
  • Template repos can't receive upstream updates cleanly

Verdict: Good for the platform team that manages governance. But it's the wrong entry point for individual developers. The template repo produces the plugin or .claude/ output that developers actually consume.

4. Managed Settings / MDM (Enterprise IT Channel)​

What it is: Organization IT deploys AgentBoot configuration to all developer machines via MDM (Jamf, Intune, JumpCloud, Kandji) or Anthropic's server-managed settings.

Two sub-channels:

A. Endpoint-managed (MDM):

/Library/Application Support/ClaudeCode/
├── managed-settings.json    # Hooks, permissions, forced plugins
├── managed-mcp.json         # Required MCP servers
└── CLAUDE.md                # Non-overridable instructions

Deployed via Jamf/Intune profile. Strongest enforcement — OS-level file protection.

B. Server-managed (no MDM required): Anthropic's server delivers configuration based on org membership. No endpoint deployment needed. Configured via admin panel at platform.claude.com.

How AgentBoot fits:

# CLI generates managed artifacts
agentboot export --format managed-settings

# Output:
# dist/managed/managed-settings.json
# dist/managed/managed-mcp.json
# dist/managed/CLAUDE.md

# IT deploys via MDM or uploads to Anthropic admin panel

Serves:

SegmentHow
SkepticsGuardrails and compliance hooks activate automatically — no opt-in
IT / PlatformZero-touch deployment; strongest enforcement; audit trail
All EngineersBaseline governance active on every machine

Pros:

  • Zero developer action required
  • Strongest enforcement available (OS-level protection)
  • Applies to ALL Claude Code sessions on the machine
  • Cannot be overridden by any user or project config
  • Server-managed option requires no MDM infrastructure
  • Perfect for HARD guardrails (PHI scanning, credential blocking)

Cons:

  • Only Claude Code (no Copilot/Cursor)
  • Heavy IT involvement for endpoint-managed
  • Managed settings are blunt — same config for all repos on machine
  • Server-managed is newer; some features may be limited

Verdict: Essential for compliance-first orgs. AgentBoot should generate managed artifacts as a first-class output. This is how skeptics and hold-outs get governed without opting in.

5. MCP Server (agentboot mcp-server)​

What it is: AgentBoot exposed as an MCP server that any MCP-compatible agent can consume. Provides persona listing, trait lookup, gotcha rules, and knowledge base access as MCP tools over JSON-RPC stdio. Implemented in Phase 8 (AB-140).

How it works:

// .mcp.json in any repo
{
  "mcpServers": {
    "agentboot": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@agentboot/mcp-server", "--config", "./agentboot.config.json"]
    }
  }
}

MCP tools exposed:

  • agentboot_review — invoke a reviewer persona with structured output
  • agentboot_list_personas — list available personas for current scope
  • agentboot_get_trait — retrieve a trait definition
  • agentboot_check_compliance — run compliance scan on input

MCP resources exposed:

  • agentboot:persona://code-reviewer — full persona definition
  • agentboot:trait://critical-thinking — trait content
  • agentboot:knowledge://compliance/hipaa — domain knowledge

Serves:

SegmentHow
Power UsersProgrammatic access; custom integrations
Copilot/Cursor UsersAgentBoot personas in non-CC agents
IT / PlatformCentralized persona serving; usage telemetry

Pros:

  • Cross-platform: works in Claude Code, Copilot, Cursor, Gemini CLI, any MCP client
  • Single source of truth — no sync needed; personas served live
  • Usage telemetry built-in (the server sees every invocation)
  • Enables the "AgentBoot as a service" model
  • MCP resources enable @agentboot:persona://code-reviewer in prompts

Cons:

  • Requires running process (stdio server or HTTP endpoint)
  • Higher latency than static files
  • More complex to deploy than a plugin
  • MCP support varies by platform (GA in CC and VS Code; preview elsewhere)

Verdict: The cross-platform bridge. When an org has both Claude Code and Copilot users, the MCP server ensures everyone gets governed personas. Also enables advanced integrations (CI/CD persona invocation, API access).

6. Direct .claude/ Sync (Current Approach, Simplified)​

What it is: AgentBoot's sync script writes compiled files directly to target repos' .claude/ directories. No plugin, no MCP server — just files in git.

How it works:

agentboot sync    # Writes .claude/ to all repos in repos.json
# Or, with sync.pr.enabled set in agentboot.config.json:
agentboot sync    # Opens a PR per repo instead of writing directly (requires the gh CLI)

Serves:

SegmentHow
All Engineers.claude/ files are there when they clone the repo; zero setup
IT / PlatformGovernance via PR review of sync commits
SkepticsFiles are present whether they want them or not

Pros:

  • Simplest mental model — files in a directory
  • Works offline (no server, no plugin install)
  • Version-controlled in the target repo
  • No Claude Code plugin system dependency
  • Works for any tool that reads .claude/ or copilot-instructions.md

Cons:

  • Sync creates noise in target repos (files they didn't author)
  • Merge conflicts when sync and manual changes collide
  • No live updates — requires re-sync for persona changes
  • Files can be modified in target repo (drift from hub)

Verdict: The fallback/bootstrap method. Works everywhere but lacks the polish of plugin-based delivery. Good for initial deployment and for repos that can't use plugins.

7. Cowork Plugins (Non-Engineers)​

What it is: Claude's desktop app (Cowork) has its own plugin system for non-technical users. Cowork plugins appear in a GUI with structured forms — no terminal required.

How it works: AgentBoot personas could be packaged as Cowork plugins that expose:

  • Structured forms for invoking reviews ("paste your PRD here → get review")
  • Compliance checking ("upload document → check for PII")
  • Knowledge base Q&A ("ask the domain expert")

Cowork plugins are the same format as Claude Code plugins but appear in the desktop GUI with form-based input rather than slash commands.

Serves:

SegmentHow
Non-EngineersGUI with forms; no terminal; role-specific plugins
Willing AdoptersGentle on-ramp; can graduate to CLI later

Pros:

  • Same plugin format as Claude Code — build once, deliver to both
  • Structured forms feel like filling out a brief, not writing code
  • Role-specific plugins (legal review, marketing copy, compliance check)
  • Enterprise org can manage Cowork plugins centrally

Cons:

  • Cowork is Anthropic-specific (no Copilot/Cursor equivalent)
  • Plugin capabilities more limited than CLI (no git, limited file access)
  • Non-engineers may not need the full persona governance system
  • Cowork plugin ecosystem is newer; fewer examples

Verdict: A bonus channel for orgs that want to extend persona governance beyond engineering. Same plugin, different surface. Low priority but comes almost free if we're already building CC plugins.

8. VS Code / JetBrains Extension Surface​

What it is: Claude Code runs inside VS Code and JetBrains IDEs. Plugins installed in the CLI are automatically available in the IDE extension. No separate IDE extension needed.

How it works:

  • Engineer installs Claude Code VS Code extension
  • Plugin installed via CLI (/plugin install agentboot) appears in IDE
  • Slash commands available in VS Code's Claude Code panel
  • Skills appear in the / autocomplete menu

Serves:

SegmentHow
Willing AdoptersIDE-first experience; never leave VS Code
SkepticsAI review appears in their existing IDE workflow

Pros:

  • No separate installation — CC plugins work in IDE automatically
  • Familiar IDE interface
  • Code context (open files, selections) available to personas

Cons:

  • Requires Claude Code extension (not standalone)
  • JetBrains support is partial (no / IntelliSense for slash commands)
  • Not a separate delivery method — it's the CC plugin surfaced in IDE

Verdict: Not a separate channel; it's where the CC plugin appears. But worth noting because the IDE is where most developers spend their time.

Multi-Channel Architecture​

                    agentboot.config.json
                           │
                    ┌──────┴──────┐
                    │  CLI Build  │
                    │  (agentboot build)
                    └──────┬──────┘
                           │
              ┌────────────┼────────────────┐
              │            │                │
    ┌─────────▼──────┐ ┌──▼────────┐ ┌─────▼──────────┐
    │ CC Plugin      │ │ .claude/  │ │ Cross-Platform │
    │ (marketplace)  │ │ (direct)  │ │ (SKILL.md,     │
    │                │ │           │ │  copilot, etc.) │
    └───────┬────────┘ └─────┬─────┘ └───────┬────────┘
            │                │               │
    ┌───────▼────┐    ┌──────▼──────┐ ┌──────▼──────┐
    │ CC + IDE   │    │ Any CC repo │ │ Copilot /   │
    │ + Cowork   │    │ (fallback)  │ │ Cursor /    │
    │            │    │             │ │ Gemini CLI  │
    └────────────┘    └─────────────┘ └─────────────┘
            │
    ┌───────▼────────────┐
    │ Managed Settings   │
    │ (MDM / Server)     │
    │ HARD guardrails    │
    └────────────────────┘
            │
    ┌───────▼────────────┐
    │ MCP Server         │
    │ (cross-platform    │
    │  live serving)     │
    └────────────────────┘

Phase 1: Foundation (Now → V1)​

ChannelActionEffort
Git TemplateAlready exists. Refine agentboot.config.json and build pipeline.LOW
CLIImplement agentboot install, build, sync, export --format plugin.MEDIUM
Direct .claude/ syncAlready designed. Implement Claude Code-native output.MEDIUM

Phase 2: Native Distribution (V1 → V1.5)​

ChannelActionEffort
CC PluginPackage AgentBoot output as a CC plugin. Create private marketplace template.MEDIUM
Managed SettingsGenerate managed-settings.json and managed-mcp.json. Document MDM deployment.LOW

Phase 3: Cross-Platform & Enterprise (V1.5 → V2)​

ChannelActionEffort
MCP ServerBuild @agentboot/mcp-server with persona invocation, trait lookup, compliance tools.HIGH
Server-Managed SettingsDocument integration with Anthropic's server-managed settings (no MDM).LOW
Cross-Platform OutputRefine copilot-instructions.md and generic SKILL.md output for non-CC agents.MEDIUM

Phase 4: Broader Reach (V2+)​

ChannelActionEffort
Cowork PluginsPackage review/compliance personas for non-engineer use via desktop GUI.LOW
Public MarketplaceSubmit core AgentBoot plugin to official Anthropic marketplace.LOW

Per-Segment Journey​

Power User Journey​

1. Discovers AgentBoot (GitHub, marketplace, word of mouth)
2. `agentboot install` → scaffolds org personas repo
3. Edits agentboot.config.json, writes custom personas/traits
4. `agentboot build && agentboot export --format plugin`
5. Publishes to private marketplace
6. Team installs via /plugin install
7. Power user extends with custom agents, hooks, MCP servers

Willing Adopter Journey​

1. Tech lead says "install the AgentBoot plugin"
2. /plugin marketplace add my-org/personas
3. /plugin install my-org-agentboot
4. Types /my-org-agentboot:review-code — gets structured review
5. "Oh, this is useful" → starts exploring other personas
6. Gradually becomes a power user

Skeptic Journey​

1. IT deploys managed settings via MDM (no developer action)
2. Compliance hooks activate automatically in every CC session
3. Developer notices audit trail messages but isn't disrupted
4. PR bot runs /review-code automatically (via CI, not the developer)
5. Skeptic sees review quality and starts invoking personas manually
6. "OK, this actually helps" → grudging adoption

Non-Engineer Journey​

1. IT enables Cowork plugin for their department
2. Opens Cowork desktop app → sees "Compliance Review" in sidebar
3. Pastes a document → fills out a form → gets structured compliance review
4. Never touches a terminal

IT / Platform Team Journey​

1. Evaluates AgentBoot → creates org personas repo from template
2. Configures agentboot.config.json with org structure
3. Builds and tests with pilot team (3-5 devs, 2-3 weeks)
4. Generates managed settings for HARD guardrails
5. Deploys managed settings via MDM
6. Creates private marketplace with org-customized plugin
7. Rolls out department by department
8. Monitors via audit hooks and structured telemetry

Non-Claude Code Delivery​

The methods above are CC-centric because CC has the richest extensibility surface. For orgs using Copilot, Cursor, Gemini CLI, or a mix of tools, AgentBoot delivers through different channels.

GitHub Copilot​

Delivery mechanisms:

  1. copilot-instructions.md — AgentBoot's cross-platform build generates .github/copilot-instructions.md which Copilot reads as always-on instructions. This is the equivalent of CLAUDE.md. Synced to repos via agentboot sync.

  2. Copilot agents (.github/agents/*.agent.md) — Custom agent definitions for Copilot. AgentBoot generates these from personas with traits inlined.

  3. Path-scoped .instructions.md — Copilot supports per-directory instruction files (.github/instructions/*.instructions.md with applyTo frontmatter). AgentBoot generates these from gotchas rules and domain layers.

  4. Prompt files (.github/prompts/*.prompt.md) — Copilot's slash command equivalent (developers type /review-code in VS Code Copilot Chat). AgentBoot does not generate these today; the generated .agent.md agents are the current persona invocation surface. Prompt-file generation is a possible future addition.

  5. Agent Skills (skills/{name}/SKILL.md) — The agentskills.io format is supported in Copilot CLI agent mode. AgentBoot's cross-platform SKILL.md output works here directly.

  6. Repository rules — Copilot can auto-review every PR via native repository rules. No Claude Code involved. The PR review persona is configured once in GitHub repo settings.

  7. Custom instructions (org-level) — Copilot Enterprise supports org-level custom instructions that apply to all repos. AgentBoot does not generate this artifact today — org-scope instructions land in the generated copilot-instructions.md and .instructions.md files synced per repo. Feeding Copilot Enterprise's org-level channel directly is a possible future addition.

  8. MCP servers — Copilot supports MCP in VS Code (GA) and CLI. AgentBoot's MCP server (agentboot mcp-server, implemented in Phase 8) provides live persona serving.

What Copilot lacks vs. CC:

  • Fewer hook types than CC — AgentBoot emits Copilot compliance hooks (.github/hooks/agentboot.json; exit-2 blocking is documented but not yet empirically verified for GA) and maps PreToolUse/PostToolUse/Stop, but SubagentStart is not in Copilot's event set, and command-hook timeouts fail open (a slow hook does not block)
  • No managed settings/MDM — no HARD guardrail channel
  • No per-persona model selection — Copilot chooses the model
  • No agent memory — no self-improvement reflections
  • No worktree isolation — no parallel reviewer execution
  • No context: fork — no reviewer isolation from generation context

Org connection for Copilot: The platform team runs agentboot sync to write generated files to target repos. Developers clone the repo and the Copilot instructions are there. No plugin install, no marketplace. It's the "repo already has it" model.

Cursor​

Delivery mechanisms:

  1. .cursor/rules/*.mdc — Cursor reads .mdc rule files from this directory. AgentBoot generates flat .mdc files with alwaysApply/globs frontmatter from always-on instructions and gotchas rules.

  2. .cursorrules — Legacy single-file instructions. AgentBoot can generate this as a flattened version of org + group + team instructions.

  3. Agent Skills (skills/{name}/SKILL.md) — Cursor supports the agentskills.io format. AgentBoot's cross-platform SKILL.md output works here.

  4. MCP servers — Cursor supports MCP. AgentBoot's MCP server (implemented in Phase 8) provides live persona access.

What Cursor lacks vs. CC:

  • No hooks — zero enforcement capability
  • No managed settings — no HARD guardrails
  • No agent/subagent system — personas are instruction-based only
  • No org-level distribution mechanism — per-repo files only

Org connection for Cursor: Same as Copilot — agentboot sync writes files to repos. No marketplace.

Gemini CLI​

Delivery mechanisms:

  1. GEMINI.md — Gemini CLI reads this file for project instructions. AgentBoot generates it from the same source as CLAUDE.md.

  2. Agent Skills — Gemini CLI supports the agentskills.io format.

  3. MCP servers — Gemini CLI supports MCP.

Org connection: Sync-based (files in repo).

Multi-Agent Organizations​

When an org has developers using different tools:

agentboot build
agentboot export --format all

dist/
├── claude/                # Full native output (.claude/ directory)
├── copilot/               # .github/copilot-instructions.md + scoped instructions
├── cursor/                # .cursor/rules/*.mdc flat rules
├── skill/                 # agentskills.io SKILL.md (cross-platform)
├── agents/                # AGENTS.md universal standard
├── gemini/                # GEMINI.md + .gemini/rules/ + per-persona persona.md
└── jetbrains/             # .junie/AGENTS.md + .aiassistant/rules/

The sync script reads each repo's platform field from repos.json and writes the appropriate format:

[
  { "name": "org/api-service", "platform": "claude", "team": "api" },
  { "name": "org/web-app", "platform": "copilot", "team": "web" },
  { "name": "org/ml-pipeline", "platform": "cursor", "team": "data" }
]

The MCP server is the only channel that serves all platforms identically — same persona definitions, same invocation, same output format. For orgs that want uniform governance regardless of tool choice, the MCP server is the primary delivery mechanism, with per-platform file sync as the secondary.

Key Design Decisions​

D-01: Plugin as primary, sync as fallback​

The CC plugin is the primary delivery method because it uses the native distribution mechanism, supports force-enable via managed settings, gets updates via /reload-plugins, and isolates via namespace. The direct .claude/ sync is the fallback for repos that can't use plugins or for cross-platform output.

D-02: CLI is a build tool, not a user tool​

End developers never run agentboot. They consume the plugin or .claude/ output. The CLI is for the platform team that manages the personas repo, runs builds in CI, and publishes to marketplaces.

D-03: Managed settings for compliance, not convenience​

Managed settings should only carry HARD guardrails — compliance hooks, credential blocking, audit logging. Personas and skills are delivered via the plugin or .claude/ sync. Mixing governance and convenience in managed settings makes both harder to manage.

D-04: MCP server is the cross-platform bridge​

When an org has Claude Code AND Copilot AND Cursor users, the MCP server serves all three from one live source, without each repo carrying compiled output. It's higher effort than PR sync, which reaches the same three platforms as files — choose MCP when you want a single live source rather than distributed artifacts.

D-05: Same plugin serves CC and Cowork​

A Claude Code plugin automatically works in Cowork (the desktop app). This means AgentBoot gets non-engineer reach for free when packaged as a plugin. Skills that make sense for non-engineers (compliance review, document analysis) surface in the Cowork GUI with structured forms.

D-06: agentskills.io listing export​

AgentBoot-compiled SKILL.md files are already in agentskills.io-compatible format. Export a skills-index.json for directory listing with:

agentboot export --format agentskills

This reads all built personas from dist/skill/core/, extracts metadata from each persona.config.json and SKILL.md frontmatter, and writes a single skills-index.json to dist/. Submit this file to agentskills.io for directory listing.

Sources​