publish

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

1. Shared preamble: Load references/quality/activation-preamble.md — context assembly, persona adaptation, deterministic routing rules.
2. Identify product: $ARGUMENTS as slug → workspace/{slug}/
3. Read .meta.yaml → verify state is "packaged"
4. Verify .publish/ exists with vault.yaml
5. Check CLI: which myclaude — if not found, show install instructions
6. Check CLI auth: run myclaude whoami — if "not logged in", show: "Not authenticated. Run myclaude login first." and stop.
7. 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).

1. 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.

1. 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:
2. Blocking: validate --json (Step 3) — abort publish if validation fails or CLI unavailable
3. Blocking: publish (Step 4) — cannot proceed without CLI. Show manual alternative: myclaude.sh/publish
4. Blocking: whoami (Step 5 pre-flight) — must be authenticated before publish
5. Silent-skip: search (Step 8 competitive context) — skip without warning on failure
6. Silent-skip: profile pull (Step 9 XP reminder) — skip without warning on failure
7. All queries except publish: append 2>/dev/null, 15s timeout
8. 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_publish:

1. Read creator-memory.yaml. If absent or malformed, skip silently (Phase 5b of /onboard

owns file creation).

1. Scan events[] for any entry with type == "first_publish". If one exists, skip this

event (idempotent).

1. If none exists, append:

```yaml

• date: "{ISO-8601 now UTC}"

type: first_publish slug: "{slug}" note: "First publish — {displayName} live at myclaude.sh/p/{slug}" ```

Procedure for first_celebration:

1. Compute pre_publish_count: count .meta.yaml files in workspace/*/ where

state.phase == "published" EXCLUDING the product being published in this invocation. Since Step 5 just wrote phase: "published", a Glob that captures the in-flight state would return 1, not 0 — subtract 1 to get the pre-publish count. Easier approach: read the in-memory value of .meta.yaml.state.phase before the Step 5 write, compute the count at that moment, and carry it forward.

1. If pre_publish_count == 0 (this publish is the Creator's first ever), proceed to

step 3. Otherwise, skip the celebration event entirely — it only fires on the first publish. The first_publish event already fired above if applicable.

1. Scan creator-memory.yaml events[] for any entry with type == "first_celebration".

Idempotent guard — if one exists, skip (this should be impossible given the count check above, but belt-and-suspenders).

1. If none exists, append:

```yaml

• date: "{ISO-8601 now UTC}"

type: first_celebration slug: "{slug}" note: "First celebration — WOW frame rendered for {slug}" ```

Validation and rollback. After each append, run python scripts/creator-memory-validate.py. On validation failure, roll back the append and surface an Engine-fault voice line at the end of Step 6's output, never blocking the publish:

"(Memory layer — failed to seed first_publish/first_celebration event. The publish itself is safe; only the memory echo is missing.)"

Voice register. Silent infrastructure. Step 5b does not render any line to the Creator — the celebration voice belongs entirely to Step 6. The payoff arrives on future Ritual of Return invocations, where /status Layer 2 can echo the memory grounded in the real date and slug.

Step 6 — Report

UX Stack (load before rendering report):

1. `references/ux