Marketplace — curated installers, in-Throne skill creation, and the review pipeline¶
Owner goal B.2 (2026-08-16), the plugin system's START-SMALL opener: gald3r plugin
(see plugins.md) already lets anyone install a git-cloned SKILL.md skill by
name or URL. gald3r marketplace builds three things on top of that:
- Curated installers — a hand-vetted catalog (not the open community registry) that
marketplace installresolves and installs with provenance. - In-Throne skill creation —
marketplace createscaffolds, validates, and reviews a new skill from structured input (what a future Throne UI form submits), producing a valid CRASH skill shape without hand-writing YAML frontmatter. - A malware-review pipeline with a per-skill change log — every marketplace install/update/create is scanned (secrets, dangerous exec patterns, and a prompt-injection screen) and logged, whether it passes or is rejected. A rejection always explains why.
Personality profiles (owner goal B.3, e.g. the owner's "Silicon Valley" profile) will ride these same rails once they're built — see Personality profiles: same rails, split-ready below.
Curated installers, with provenance¶
gald3r marketplace list
[ ] example-community-skill (community-curated) Placeholder catalog entry demonstrating the
"curated installer" shape for a well-known community skill author's catalog. Replace
`source` with a real, vetted repository before flipping `verified`.
[ ] example-gald3r-original (gald3r-original) Placeholder catalog entry demonstrating the
"original" shape -- a skill gald3r authors itself from the owner's design lists and adds
to the marketplace as same-or-better than an equivalent community skill.
[*] = curator-verified, safe to install without --allow-unverified
The shipped catalog (crash/sysdata/marketplace_catalog.yaml, embedded in the binary) currently
ships two deliberately-unverified placeholder entries proving the schema end to end — see
that file's own header comment. Populating it with a real, license-checked, security-reviewed
"Josh Pocock catalog class" of well-known community skills (INSTALLERS) and gald3r-authored
ORIGINALS from the owner's design lists is an editorial curation step for a human, not something
fabricated sight-unseen. An entry with verified: false is refused by install unless you pass
--allow-unverified.
gald3r marketplace install <catalog-name-or-git-url> [--allow-unverified] [--actor NAME]
gald3r marketplace update <name>
install resolves a catalog entry to its git URL (or accepts a raw URL directly, recorded as
source_type: url instead of source_type: catalog), clones it through the same PluginManager
plugin install already uses, then runs the review pipeline against the freshly-cloned
content before it counts as accepted. A REJECT verdict rolls the install back
(plugin uninstall) and explains why on stderr. update re-pulls and re-reviews; a REJECT there
cannot cleanly roll back a git pull, so it is logged and explained instead, with a nudge to
uninstall manually.
Every install/update writes a provenance record
({data-dir}/marketplace/provenance/<name>.yaml) recording where the skill came from
(source_type, source), who curated it, whether the catalog entry was verified at install
time, who installed it and when, and the most recent review verdict.
In-Throne skill creation, producing a valid CRASH skill shape¶
gald3r marketplace create \
--name my-cool-skill \
--description "Does a cool thing." \
--maturity beta \
--allowed-tools Read,Write \
--requires git \
--token-budget low \
--publish
published 'my-cool-skill' (valid CRASH skill shape, reviewed: pass) at
<data-dir>/marketplace/authored/my-cool-skill
This is the backend a Throne skill builder (or any other GUI) drives: structured fields in
(name, description, maturity, allowed tools, requirements, token budget, trust level, body text),
a validated SKILL.md + README.md pair out — "simple/fun enough for non-devs, deep enough for
devs to geek on" means a non-dev can fill in just --name/--description and get a working
scaffold with a placeholder body to edit later, while a dev can set every CRASH frontmatter field
from the command line (or, later, an equivalent structured API call).
Every create call runs through the same structural-shape validation and content-safety
review as an install. Reject one and nothing is written to disk — the rejection is still logged
(see below) with the reason. Omit --publish and the result lands in
{data-dir}/marketplace/drafts/<name>/ instead of .../authored/<name>/, so a work-in-progress
skill can be reviewed/iterated before it's treated as a real marketplace entry.
The malware-review pipeline¶
Every marketplace add/edit/update (install, update, create) runs two independent check
families over the submitted content:
- Static checks — SAST-flavored pattern scanning for hardcoded secrets/credentials (AWS
keys, API tokens, PEM private key blocks) and dangerous executable patterns
(
curl | sh-style remote-fetch-and-execute, PowerShellInvoke-Expression/-EncodedCommand,rm -rf /,shell=Truesubprocess calls, dynamiceval/exec). - The prompt-injection screen — the "T851 injection-screen lineage" the owner named: T851/
T852's
promptguardpackage established the discipline of flagging suspicious inbound text without ever treating it as instructions for GitHub-issue triage. This is the same discipline applied to skill bodies — "ignore all previous instructions", jailbreak-persona markers ("you are now DAN"), hidden zero-width Unicode characters, and directive-shaped HTML comments are all flagged this way.
A finding at BLOCK severity rejects the submission outright; WARN/INFO findings are logged
but do not block. Every review call is logged, pass or reject — a per-skill change log at
{data-dir}/marketplace/changelog/<name>.jsonl, one JSON line per event
(timestamp, action, actor, verdict, findings, and — on a rejection — the explained reason):
gald3r marketplace changelog my-cool-skill
2026-08-22T00:00:00+00:00 add pass actor=cli-user
You can also run the review pipeline standalone against any skill directory, without installing or creating anything:
gald3r marketplace review ./some/skill/dir
Personality profiles: same rails, split-ready¶
Owner goal B.3 (personality profiles — e.g. the owner's "Silicon Valley" profile) is specced,
not implemented, on these same rails; see the dated design note this doc links from for the
full spec. In short: gald3r pers (see verbs.md) already has its own
install/list/pick/save mechanism (crash/personality.py) — B.3's job is to give personality
packs the same three things B.2 gives skills: a curated catalog entry shape, a
pers create-style in-Throne authoring flow, and the identical review-pipeline + per-pack
change log gate. It is intentionally out of scope for this document's shipped code — split into
its own task once B.2 (this document) lands, per the owner's own framing.
Where next¶
plugins.md— the underlying git-clone install/update/uninstall mechanismmarketplace install/updateroute throughcrash.md— how a skill actually gets loaded and activated once installedverbs.md— the full verb catalog