CONDUIT Publishing Protocol

CONDUIT is the publishing pipeline that carries your product from creation to marketplace listing. Three systems, one unbroken flow.

Every product published to MyClaude travels through CONDUIT — whether you use the Creator Engine, the CLI directly, or a combination. Understanding this pipeline helps you diagnose publish failures, optimize your workflow, and build products that take full advantage of the metadata the marketplace can display.

The three systems

CONDUIT connects three independent systems that each own a distinct responsibility.

CREATOR ENGINE           CLI               MARKETPLACE API
(creates products)       (ships products)   (serves products)

 Scaffold               Read vault.yaml    Authenticate
 Build content           Collect files      Validate payload
 Validate MCS            Secret scan        Persist to database
 Strip guidance          Pack ZIP           Index for search
 Generate vault.yaml     Upload to R2       Serve to buyers
 Stage clean dir         Call API
                         Report result

       BOUNDARY A              BOUNDARY B
       Clean directory          POST with auth
       with vault.yaml          + ZIP + fields
       at the root

Boundary A is a directory on disk. The Engine produces a clean directory with vault.yaml at its root. The CLI reads that directory.

Boundary B is an HTTP request. The CLI sends an authenticated POST with a ZIP file and manifest fields. The API validates and persists.

These boundaries are strict. The Engine never calls the API directly. The CLI never generates metadata. The API never trusts client-provided author information.

Three tiers of usage

Not every creator uses all three systems. CONDUIT supports three tiers depending on your workflow.

Tier 1 — CLI-native

You write files by hand, create vault.yaml yourself, and publish directly with the CLI. This is the simplest path and the one covered in Publishing Your First Product.

$ mkdir my-skill && cd my-skill
$ # write SKILL.md and vault.yaml by hand
$ myclaude publish

The CLI handles everything from Boundary A onward: validation, scanning, packing, uploading, and API submission.

Tier 2 — Engine-assisted

You use the Creator Engine to scaffold, build, and validate your product. The Engine generates vault.yaml and stages a clean directory. You invoke the CLI from the Engine to publish.

/create skill          # Engine scaffolds the project
# ... write content with AI assistance ...
/validate              # Engine runs MCS checks
/package               # Engine stages .publish/ directory
/publish               # Engine invokes CLI from .publish/

The Engine owns everything before Boundary A. The CLI takes over at Boundary A. You get richer metadata (MCS level, long descriptions, compatibility info) because the Engine populates vault.yaml v2 fields automatically.

Tier 3 — Full automation

For creators with established workflows, the Engine can detect changes in your workspace and trigger the publish pipeline automatically. This tier is aspirational — it builds on Tier 2 with file-watching and auto-validation.

# Creator edits files in workspace/my-skill/
# Engine detects changes → /validate → /package → /publish

Most creators will use Tier 1 or Tier 2. Tier 3 is designed for prolific creators managing multiple products.

Pipeline stages

When you run myclaude publish, four stages execute in sequence. Each must pass before the next begins.

Stage 1 — Validate

The CLI reads vault.yaml and checks every field against the schema.

What happens:

• Parses YAML and checks syntax
• Validates required fields: name, version, type (or category), description, entry
• Checks field constraints: name format, version is valid SemVer, description under 160 characters, price is 0 or >= 1.00, tags are max 5 and under 30 characters each
• Warns on missing recommended fields: display_name, license, tags
• Passes through enrichment fields silently: mcs_level, language, long_description, compatibility, dependencies

What can fail:

Run myclaude validate at any time to check your manifest without publishing.

Stage 2 — Scan

The CLI scans all product files for content policy violations and secrets.

What happens:

• Secret scan: checks for API keys, tokens, passwords, private keys, and other credential patterns across all files
• Content policy scan: checks for prohibited content per Content Policy
• Collects all files in the directory, respecting .vaultignore if present

What can fail:

The secret scanner is intentionally aggressive. False positives happen — if a string matches a credential pattern but is not actually a secret, you can add it to .vaultignore or restructure the content.

Stage 3 — Upload

The CLI packs your files into a ZIP and uploads to storage.

What happens:

• Collects all files (respecting .vaultignore)
• Creates a ZIP with the product files
• Computes checksum and file metadata (count, total size)
• Uploads the ZIP to Cloudflare R2 storage
• Receives a file key for the API submission

What can fail:

Stage 4 — Listing

The CLI sends manifest fields and the uploaded file reference to the marketplace API, which creates or updates the product listing.

What happens:

• CLI sends authenticated POST to /api/cli/products/create
• API verifies the auth token and extracts user identity
• API validates all manifest fields server-side
• API persists the product to Firestore
• API indexes the product for search
• CLI receives the product URL and reports success

What can fail:

A successful publish prints:

Validating vault.yaml... OK
Scanning content... OK
Uploading files... OK
Creating listing... OK

Published: myclaude.sh/p/your-username-my-product

How vault.yaml flows through the pipeline

Every field in your vault.yaml takes a specific path from your local file to the marketplace.

vault.yaml          CLI reads           CLI sends          API stores        Marketplace shows
----------          ---------           ---------          ----------        -----------------
name            ->  manifest.name   ->  slug           ->  slug          ->  URL, listing
version         ->  manifest.version -> version        ->  version       ->  version badge
type            ->  manifest.type   ->  category (mapped) -> category    ->  category filter
description     ->  manifest.desc   ->  description    ->  description   ->  listing card
display_name    ->  manifest.display -> title          ->  title         ->  listing title
license         ->  manifest.license -> license        ->  license       ->  license badge
tags            ->  manifest.tags   ->  tags           ->  tags[]        ->  search, filter
price           ->  manifest.price  ->  price          ->  price         ->  checkout
mcs_level       ->  manifest.mcs    ->  mcsLevel       ->  mcsLevel      ->  MCS badge

Fields like author, timestamps, and download stats are server-authoritative — the API computes them from your auth token and server state, not from vault.yaml.

See vault.yaml Specification for the complete field reference.

Integration with Creator Engine

If you use the Creator Engine, the publish flow adds steps before the CLI takes over.

The Engine's /package command:

1. Strips guidance comments from your workspace files
2. Copies clean files to a .publish/ staging directory
3. Generates vault.yaml v2 with enrichment fields (MCS level, language, compatibility)
4. Generates or updates CHANGELOG.md
5. Copies LICENSE file
6. Re-validates MCS-1 on the staged contents
7. Reports that the package is ready

The Engine's /publish command:

1. Verifies .publish/ exists with a valid vault.yaml
2. Asks for final confirmation (price, tags, description)
3. Invokes myclaude publish from the .publish/ directory
4. The CLI takes over from here (Stage 1 through Stage 4 above)
5. Engine parses the CLI result and updates internal state

The Engine never creates the ZIP. The Engine never calls the marketplace API. These are CLI responsibilities. This separation means you can always fall back to CLI-only publishing if the Engine is unavailable.

Error recovery

When publish fails, the CLI tells you which stage failed and why. Here is the recovery path for each.

Stage 1 failure (Validate): Fix the vault.yaml error the CLI reported. Run myclaude validate to confirm the fix before retrying.

Stage 2 failure (Scan): Remove the flagged content. If it is a false positive on the secret scanner, restructure the content to avoid the pattern. Re-run myclaude publish.

Stage 3 failure (Upload): This is almost always a network or authentication issue. Run myclaude login to refresh credentials, check your connection, and retry. Your local files are not modified during upload — retrying is safe.

Stage 4 failure (Listing): The API rejected the submission. Common causes: name collision, version not incremented, or Stripe not connected for paid products. Fix the specific issue and re-run. Upload will not re-upload if the file has not changed.

Publishing is idempotent. Running myclaude publish twice with the same version updates the existing listing rather than creating a duplicate. Running it with an incremented version creates a new version of the same product.

Related pages

• vault.yaml Specification — complete field reference for the manifest
• Publishing Your First Product — step-by-step publish tutorial
• MCS Certification — the quality tier system that CONDUIT propagates
• Content Policy — what the content scan checks for