Skip to content
OpenCharly

marketplace

Recipe card from the charly-internals plugin (Development — contributor internals).

marketplace — how the skill corpus is generated, refreshed, and consumed

Section titled “marketplace — how the skill corpus is generated, refreshed, and consumed”

The corpus is GENERATED; the refs list is the ONE input

Section titled “The corpus is GENERATED; the refs list is the ONE input”

The opencharly/marketplace repo’s root (family dirs: internals/, build/, check/, core/, vm/, automation/, kubernetes/, local/, image/, pod/, …) is the GENERATED corpus. Every SKILL.md carries a GENERATED by charly marketplace generate — DO NOT EDIT banner; agent definitions under <family>/agents/ are HAND-AUTHORED (no banner). candy/charly-marketplace/charly.yml is the refs list: @github.com/opencharly/<candy-repo>:v<CalVer> pins for every standalone candy repo that owns skill:/hook:/marketplace: entities. It is the ONE generation input — change a skill at its SOURCE, never the generated copy.

The ownership split (post cutover)

Section titled “The ownership split (post cutover)”

The charly repo owns NO skill: entities (its candy/ dir was emptied by the de-submodule cutover). Each family lives in its standalone owning candy repo:

Family Owning repo
internals layer-charly-internals (+ layer-charly-internals-extra for strict-policy, vm-spec, and the agents roster)
build layer-charly-build
check layer-charly-check
kubernetes layer-charly-kubernetes
image layer-charly-image
core pod-charly-core
automation pod-charly-automation
local layer-charly-local
pod layer-charly-pod
hooks / marketplace verb / hook: entities pod-charly-hooks

A skill edit lands in the OWNING repo’s candy skill: entity (e.g. layer-charly-internals/charly.yml), then the marketplace refs list is bumped and the corpus regenerated. Never hand-edit a generated SKILL.md or a marketplace family dir.

Regeneration

Section titled “Regeneration”

charly -C <marketplace-checkout> marketplace generate --root <marketplace-checkout> --out <marketplace-checkout>

  • The marketplace verb is an out-of-process command plugin: it enters the CLI grammar only inside a project whose charly.yml declares it on a discover: path (the marketplace repo’s own charly.yml exists for exactly this).
  • The charly binary must support the marketplace repo’s config schema (2026.240.1943-era as of this writing); a binary built from a recent charly checkout works, an old one fails with config schema ... is newer than this charly supports.
  • Regeneration on a clean tree is a NO-OP for the committed corpus (hand-authored files sit outside the known paths); a diff means a refs/source change is in flight.

The drift gate (deploy.yml is the SOLE OWNER of generation)

Section titled “The drift gate (deploy.yml is the SOLE OWNER of generation)”

The marketplace repo’s deploy workflow builds the pinned charly, regenerates the ENTIRE corpus, and FAILS if the committed corpus does not match — including UNTRACKED regenerated files (git status --porcelain, not just git diff --exit-code). A refs bump must therefore ship its regenerated corpus in the same PR, or the gate trips on the next run.

The daily refresh (refresh.yml)

Section titled “The daily refresh (refresh.yml)”

Daily 04:41 UTC (+ manual dispatch): scripts/refresh-refs.sh advances every @github pin in the refs list to its repo’s newest tag, regenerates, and opens a chore: refresh the refs list PR; it skips if one is already open. The content is NOT unreviewed — each pinned repo validated its own change before tagging; the refresh republishes landed work (it exists because hand-written CalVer pins go stale silently and the drift gate stays green regardless).

Per-harness vendoring — the corpus is a CACHE, not a live source

Section titled “Per-harness vendoring — the corpus is a CACHE, not a live source”

Claude Code clones the marketplace as charly-plugins; Codex registers it by GitHub source; kimi installs it as one plugin; pi installs it as a git package (.pi/pi-claude-marketplace/ + state.json with commit-SHA versioning). Updating the marketplace repo is NOT updating an installed plugin: each harness caches per committed state, so a landed fix stays invisible until the harness refreshes its marketplace and re-installs the plugin at scope.

Cross-References

Section titled “Cross-References”

When to Use This Skill

Section titled “When to Use This Skill”

Invoke before editing any skill source, bumping a refs-list pin, running charly marketplace generate, reviewing a refresh/drift failure, or answering “why is my skill/agent stale in my harness”.