Shipping a bundle — skill + agent + MCP server in one publish

When a bundle makes sense

You almost always start with one entity. As soon as a real product lives on top, you realize the consumer needs more than one shape:

• The skill lives in their agent's memory as a playbook.
• The agent is the turnkey "I want this to just work" version.
• The MCP server is the tool surface their existing agent can mount.

Each of these is the right answer for some consumer. If you ship them separately, you fragment the discovery — three pages, three signing events, three places to keep documentation in sync.

A bundle ships all three under one repo label, signed in one event, cross-linked in dependencies, presented on a single bundle detail page.

The wizard at /publish/bundle

Five steps, four logical screens:

Step 1 — bundle metadata

• Repo label — the namespace this bundle lives under. Lowercase + hyphens, optionally one slash (acme/payments). Stamped on every member by the server; you don't repeat it per-member.
• Title (optional) — human-readable. Shown in the audit log.
• Visibility — public / draft / private. Applied to every member.

The form remembers your input — if you accidentally close the tab mid-wizard, the next visit restores the draft from sessionStorage and shows a toast.

Step 2 — members

A card per member. Default new bundle has two stub cards (one skill, one MCP server) but you can add agents or remove anything. Each card captures the entity-specific fields:

• Skill — id, version, description, capabilities, body markdown.
• Agent — same plus model_compatibility, system prompt OR service URL, agent_card_url.
• MCP server — same plus mcp_server_url, paste-able tools JSON.

Validation runs live. Each member shows its errors inline; the Next button stays disabled until everything passes.

Step 3 — review

A single page showing every manifest as it'll be submitted. The Graph tab from V5 renders here too — you see the bundle's relationships visually before you sign.

This is the last chance to catch an error like "the agent depends on payments-checkout but I named the skill checkout."

Step 4 — sign + submit

One click. The registry:

1. Validates every manifest against ManifestSchema server-side. Any single failure rolls the whole bundle back.
2. Resolves cross-bundle references (the agent's dependencies[].id pointing at the skill's id) so they bind to actual entities.
3. Signs the bundle with one Sigstore call.
4. Inserts each member as a published version under your handle.
5. Returns a bundle-id you can share or revisit at /b/<repo>.

If validation fails, you bounce back to step 2 with the offending field highlighted. No half-published state.

What the bundle gets you that single publishes don't

1. One bundle page. /b/<repo> lists every member, their trust tier, their evaluation scores, the graph of how they relate.
2. Cross-linked dependencies. The agent declaring it invokes the skill, the MCP server tool declaring it wraps the skill — these show up as edges on the graph and help consumers understand what they're pulling in.
3. Atomic publish. Either every member is up, or none of them are. No "the agent published but the skill failed" state to clean up.
4. Atomic versioning. Bumping the bundle bumps every member — or you can bump just one. The repo label is the unit of release.

Edge cases the wizard handles

• You decide mid-wizard not to ship one of the entities. Toggle it off; the wizard drops it from the bundle. Validation re-runs.
• You reference a skill that's also being drafted in the same bundle. Use the slug; the server resolves it to a fresh id at submit time. You don't have to publish the skill separately first.
• You refresh the page mid-wizard. sessionStorage restores everything. You'll see a toast: "Resumed your unfinished bundle."
• Submit succeeds but you spot a bug. Bump the version, fix the manifest, resubmit. The old version stays accessible at /s/<id>?v=<old> for downstream consumers.

When NOT to use the bundle wizard

• You're shipping one entity at a time and don't want them cross-linked. Use /publish directly.
• You're updating one member of an existing bundle. Use the per-entity owner toolbar from /me to bump just that member.
• You're testing locally. The CLI's amitte publish-local is faster for iteration.

For everything else — coherent multi-entity releases, especially those tied to a real product launch — bundle. Discovery, trust, and versioning all line up better that way.