/publish

name: publish
description: >-
  Publish a packaged product to myclaude.sh via the CLI. Shows summary,
  requires confirmation, runs myclaude validate + myclaude publish.
  Use when the creator says "publish", "ship it", "go live", or after /package.
argument-hint: "[product-slug]"
allowed-tools:
  - Read
  - Bash(myclaude *)
  - AskUserQuestion

Publisher

Publish a packaged product to the MyClaude marketplace via CLI delegation.

**When to use:** After /package has staged .publish/ directory.

**When NOT to use:** If product hasn't been packaged yet (run /package first).

---

Activation Protocol

0. **Shared preamble:** Load `references/quality/activation-preamble.md` — context assembly, persona adaptation, deterministic routing rules. 1. Identify product: `$ARGUMENTS` as slug → `workspace/{slug}/` 2. Read `.meta.yaml` → verify state is "packaged" 3. Verify `.publish/` exists with vault.yaml 4. Check CLI: `which myclaude` — if not found, show install instructions 5. Check CLI auth: run `myclaude whoami` — if "not logged in", show: "Not authenticated. Run `myclaude login` first." and stop. 6. Read `creator.yaml` → load author metadata. If missing — "Creator profile not found. Run `/onboard` first." and stop. 6b. **Load proactives:** Load `references/engine-proactive.md` — wire #1 (pipeline guidance: after publish, suggest /status to track installs), #14 (feedback loop: after publish, suggest checking install data next session), #18 (WOW moment for first publish). 7. **Load voice identity**: Load `references/quality/engine-voice-core.md`. Load the full `references/quality/engine-voice.md` only when composing the publish celebration (Step 6) — that is a peak moment. Use publish celebration format: "Published to myclaude.sh — live now." + install command + distribution vector note. Brief, proud, specific. 7b. **Exemplar load:** Load `references/quality/exemplar-outputs.md` sections E8 and E9 only — the first-publish celebration and nth-publish compact. Your celebration MUST carry the same Frame + emotion calibration: full ceremony for first/significant publishes, compact ✦ line for expert nth publishes. Adapt to creator journey position. 8. **CLI contract:** Load `references/cli-contract.md` for unified error handling. This skill has mixed severity — the most critical CLI surface in the pipeline. Severity map:

• **Blocking:** `validate --json` (Step 3) — abort publish if validation fails or CLI unavailable
• **Blocking:** `publish` (Step 4) — cannot proceed without CLI. Show manual alternative: `myclaude.sh/publish`
• **Blocking:** `whoami` (Step 5 pre-flight) — must be authenticated before publish
• **Silent-skip:** `search` (Step 8 competitive context) — skip without warning on failure
• **Silent-skip:** `profile pull` (Step 9 XP reminder) — skip without warning on failure
• **All queries except publish:** append `2>/dev/null`, 15s timeout
• **Auth detection:** use contract's auth flow pattern (whoami → check exit code + "not logged" in output)

---

Core Instructions

PUBLISH FLOW

**Step 1 — Summary**

Display what will be published:

Ready to publish:

  Name:     {displayName}
  Slug:     {slug}
  Type:     {type}
  Version:  {version}
  Price:    {price == 0 ? "Free" : "$" + price}
  License:  {license}
  MCS:      {level} ({score}%)
  Files:    {N} in .publish/

Publish to myclaude.sh? (yes/no)

**Step 1b — Type-Specific Constraints**

If `type` is `claude-md`, append this note to the summary display before asking for confirmation:

Note: Rules files (.claude/rules/) cannot be auto-installed via the plugin system.
Buyers must manually copy the rules file to ~/.claude/rules/ or .claude/rules/ in
their project. Include this instruction in your README.md.

**Step 1c — Version Bump Guard**

Read `.meta.yaml → history.version` AND check if this slug+version combination was already published:

• Glob `workspace/{slug}/.meta.yaml` → read `state.published_at` and `history.version`
• If `state.phase == "published"` AND `history.version` matches the current version in `.publish/vault.yaml`:
• BLOCKING: "Version {version} is already published. Bump the version in `.meta.yaml → history.version` (e.g., 1.0.0 → 1.0.1) before re-publishing. This prevents 71+ users from receiving a silent no-change update."
• If `state.phase != "published"` (first publish): proceed — no version check needed.

**Step 2 — Confirmation**

Wait for explicit "yes" from creator. Do NOT proceed without confirmation.

**Step 3 — CLI Pre-flight**

cd workspace/{slug}/.publish && myclaude validate --json 2>/dev/null

Parse JSON result. If exit code != 0 or JSON parse fails, report: "CLI validation failed or unavailable. Verify manually or run `/validate` first." and abort.

**Step 4 — Publish**

cd workspace/{slug}/.publish && myclaude publish

Report CLI output verbatim.

**Step 5 — Update State**

On success:

# .meta.yaml updates
state:
  phase: "published"
  published_at: "{ISO timestamp}"
  version: "{version}"

**Step 5b — Seed creator-memory publish milestones (silent, idempotent)**

After the `.meta.yaml` state update succeeds, write up to two events to `creator-memory.yaml`: `first_publish` and `first_celebration`. Both are idempotent — each type writes exactly once across the Creator's entire history, ever.

**Why two events?** `first_publish` records the infrastructural milestone ("the Creator has now shipped something to a marketplace"). `first_celebration` records the emotional peak ("the WOW frame rendered, the ✦ arrived, the identity shifted"). On the very first publish they happen in the same second and look redundant, but they are semantically distinct: a future version of /publish could suppress the WOW frame (e.g., `--silent` or a re-publish scenario) without suppressing the milestone. Keeping them as separate events lets the memory layer express "shipped" separately from "celebrated".

**Procedure for `first_publ