dotcontext-marketplace

The catalog of installable items for dotcontext — commands, MCPs, external CLIs, hooks, scripts, and skills users can opt into via the marketplace TUI.

What's in this repo

Path	Purpose
manifest.json	The catalog itself — 21 items, 16 in the starter pack
manifest.schema.json	JSON Schema for catalog validation
templates/	Files shipped to users on install (commands, agents, skills, scripts)
scripts/validate-manifest.sh	Pure-bash validator (jq optional)

How dotcontext consumes this

1. When the user opens the TUI (dotcontext no-args), the CLI fetches manifest.json from https://raw.githubusercontent.com/goca-se/dotcontext-marketplace/main/manifest.json and caches it under ~/.dotcontext/cache/.
2. When the user installs an item, dotcontext walks the bundle's files array and fetches each src path from the same base URL.
3. The lockfile (.context/.dotcontext-state.json local; ~/.dotcontext/state.json global) records what was installed and from where.

For local development of the marketplace itself, point dotcontext at your clone:

DOTCONTEXT_MARKETPLACE_ROOT=$PWD dotcontext      # in a regular terminal

Item types

Type	Description
command-bundle	A /slash-command plus any agents/skills it needs
skill	A .claude/skills/<name>/SKILL.md guide
mcp	A Model Context Protocol server entry (added to .mcp.json or ~/.claude/settings.json)
external-cli	A binary like gh, glab, installed via OS package manager
hook	A Claude Code event hook entry
script	A standalone script under .claude/scripts/

Contributing

Adding an item is a single-PR workflow. See CONTRIBUTING.md for the full recipe.

In short:

1. Edit manifest.json to add the entry
2. Add template files under templates/.claude/...
3. make validate-manifest
4. PR

Versioning

This repo is currently untagged. Each catalog item has its own version field. The CLI consumes the main branch by default; users can pin via the DOTCONTEXT_MARKETPLACE_BRANCH env var when running dotcontext.

A future min_cli_version field per item can gate items that depend on newer CLI features.

Relationship to the main repo

• This repo: what can be installed (catalog + content).
• goca-se/dotcontext: how it gets installed (the TUI, CLI, install handlers, lockfile, migration).

The split exists to keep the contribution bar low for casual catalog additions while letting the harness stay focused. See dotcontext ADR-020.