Skip to content

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:

  1. Curated installers — a hand-vetted catalog (not the open community registry) that marketplace install resolves and installs with provenance.
  2. In-Throne skill creationmarketplace create scaffolds, 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.
  3. 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, PowerShell Invoke-Expression/-EncodedCommand, rm -rf /, shell=True subprocess calls, dynamic eval/exec).
  • The prompt-injection screen — the "T851 injection-screen lineage" the owner named: T851/ T852's promptguard package 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 mechanism marketplace install/update route through
  • crash.md — how a skill actually gets loaded and activated once installed
  • verbs.md — the full verb catalog