Build and publish

Understand the full creator workflow from local pack to marketplace listing

This guide explains not just which commands to run, but how the CLI and the marketplace divide responsibilities so the workflow feels predictable instead of mysterious.

Use the quick start Open methodology

What you are really building

A pack is not just a README and not just a listing. It is a versioned installable package with a manifest, validated content, pack-specific installation and usage guides, and a marketplace presence people can access and manage.

What the CLI owns

The CLI owns both boundaries: `ctx pack init` for the upstream authoring workspace, and `ctx pack create` / `validate --path` / `publish --path` for the actual pack source and version publication.

What Creator Studio owns

Creator Studio is where you manage the marketplace-facing layer after publication: visibility, release notes, archive state, version history, and account context.

Walkthrough

From local workspace to published listing

This is the full creator workflow in the order most people actually need it.

1. Start with the right account context

Before publishing, confirm which marketplace account should own the pack. Account context affects ownership, permissions, and who can manage the listing later.

2. Initialize the authoring workspace

Use the CLI to create the upstream workspace for raw capture and wiki shaping. This keeps the recommended authoring flow clear before you create the actual pack artifact.

ctx pack init my-pack-workspace

3. Create the publishable pack source

Create the actual pack scaffold separately. That pack source is the bounded context with the manifest, installer, and content roots that validation and publication operate on.

ctx pack create my-pack --path .\my-pack-workspace\pack-source

4. Add and refine the pack content

Focus the pack around a repeatable process or body of knowledge. Use the authoring workspace for messy shaping, then move only the verified reusable material into the publishable pack source.

5. Validate before you publish

Validation should happen early and often. It is how you catch manifest mistakes, version issues, and structure problems before they become marketplace problems.

ctx pack validate --path .\my-pack-workspace\pack-source

6. Publish the version

Publishing is done through the CLI. The marketplace then becomes the system of record for the published artifact, version history, and access.

ctx pack publish --path .\my-pack-workspace\pack-source

7. Manage the listing in Creator Studio

After publish, move into Creator Studio to refine visibility, release notes, and lifecycle controls without replacing the CLI as the source of truth for publication.

Common mistakes to avoid

Treating Creator Studio as the place where publication happens instead of the CLI.
Publishing before validating the specific pack source path locally.
Using the wrong active account and then being surprised by ownership later.
Trying to cram too much unrelated material into the first version of a pack.

Troubleshooting and FAQ

I can sign in but I cannot publish

Check which active account you are operating from in the marketplace. Publishing permissions are account-based, not just user-based.

Validation is failing

Start by checking your manifest fields, version format, required pack docs, and content structure. Validation should be treated as part of the authoring workflow, not a last-minute gate.

The pack published but the listing needs work

That is expected. Use Creator Studio after publish to refine release notes, visibility, and listing presentation without changing the canonical artifact contract.

I am not sure whether this should be a pack yet

If the material is still messy, collect it first. The strongest packs come from a repeatable process or body of knowledge that is ready to be curated into a reusable product.

ctx pack install is targeting the wrong directory

Run pack install from the root of your git repo, or pass --repo-root explicitly. The CLI walks up the directory tree to find a context.yaml; if you are inside a parent repo that already has one installed, it will find that instead.