Decentralized Skill + Code Marketplace — Research & Codebase Audit
Decentralized Skill + Code Marketplace — Research & Codebase Audit
Section titled “Decentralized Skill + Code Marketplace — Research & Codebase Audit”Status: Research + audit (pre-design). Feeds a forthcoming design doc and implementation plan.
Date: 2026-06-18.
Scope decision (user): Audit + research first, then design. Decentralization model = local-first + optional publish. Discovery targets = all four: repeated .vox/code blocks, repeated prompts/agent flows, overlap with existing MCP tools/skills (the SSOT problem), and external skills to import.
0. Problem statement
Section titled “0. Problem statement”We want a system that:
- Discovers locally — mines the codebase and session history for recurring code blocks and recurring prompts/agent flows, and proposes crystallizing them into reusable Vox snippets or
SKILL.mdskills. - Dedups against what already exists — when a new skill/tool overlaps an installed one (the MCP↔skill SSOT gap), suggest reuse instead of re-authoring.
- Agentically reviews + tags — reviews submissions in the absence of human review, attaching proper frontmatter/tags, as a quality floor (not the sole gate).
- Shares decentralized, opt-in — primary value is local; publishing is a deliberate push to a registry, with GUI support for browse/search/publish.
Skills are, in the user’s framing, “just good prompts” + optional code; code blocks are reusable Vox (but not exclusively Vox).
1. Codebase audit — what already exists (the SSOT spine is real)
Section titled “1. Codebase audit — what already exists (the SSOT spine is real)”The marketplace skeleton already exists; most of this initiative is new layers on top plus closing the MCP↔skill gap. Do not rebuild the spine.
1.1 Skill registry (authoritative SSOT)
Section titled “1.1 Skill registry (authoritative SSOT)”vox-skillsis a re-export shim overvox_plugin_host::skill_registry(crates/vox-skills/src/registry.rs:7).SkillRegistry(crates/vox-plugin-host/src/skill_registry.rs:80-347): in-memory + DB-persisted;install/install_bundle/uninstall/lookup/get/search(keyword over id/name/description/tags) /list/hydrate_from_db(Codexskill_manifeststable).RegisteredSkill(skill_registry.rs:54-73):manifest, optional rawbody,source=Plugin { plugin_id } | Bundle | OpenClaw { node_id }.
1.2 Manifest schema
Section titled “1.2 Manifest schema”SkillManifest(crates/vox-plugin-types/src/skill_manifest.rs:14-48):id, name, version, author, description, category, permissions, tools, dependencies, homepage, registry, hash (SHA-256), tags.SkillCategory(:78-97) — 13 named +Custom(String).SkillPermission(:109-126) —ReadFiles, WriteFiles, ShellExec, Network, DbRead, DbWrite, Secrets.- Note:
tools: Vec<String>already declares which MCP tools a skill exposes — the hook for SSOT linkage exists but is unvalidated.
1.3 SKILL.md parser
Section titled “1.3 SKILL.md parser”crates/vox-plugin-host/src/skill_parser.rs:53-159: AgentSkills-compliant YAML (name,description+[metadata]vox-*) and legacy Vox TOML; TOML-first then YAML fallback. Tolerateslicense,compatibility,allowed-tools(parsed, unused).- Native plugin skills (8): compiler, git, memory, orchestrator, rag, testing, testing-validate, v0 (
crates/vox-plugin-skill-*). External agentskills.io layout discovery:external_skills.rs:26-69(first-match-wins shadowing). - Native prompt-style skills also live in
crates/vox-skills/skills/superpowers/.
1.4 Marketplace client (no server yet)
Section titled “1.4 Marketplace client (no server yet)”SkillsRegistryClient(crates/vox-skills/src/registry_api.rs:23-141):search/download/publish(API-key) /get_manifestagainstSKILLS_REGISTRY_BASE = https://raw.githubusercontent.com/vox-foundation/vox/main/skills(lib.rs:44).- No server-side: no publish-validation pipeline, storage backend, indexing, or dedup.
downloads/starsare placeholder fields. No GUI surface.
1.5 Sandbox & trust model
Section titled “1.5 Sandbox & trust model”crates/vox-skills/src/sandbox/policy.rs:1-137:TrustLevel=Trusted | Community | Untrusted;ApprovalGuard::checkgates Community onapproved.resolve_policy:Trusted && !Shell → Permissive (host), elseContainer(OCI viavox-container, Docker/Podman;OpenClawSidecarSandboxfallback).- This local sandbox is the key differentiator (see §3.D-4): we can run review + capability analysis + dedup before execution, on the user’s machine.
1.6 Existing agentic review to reuse
Section titled “1.6 Existing agentic review to reuse”- Visual AI review (
vox-orchestrator-mcp/src/visus_review/mod.rs:1-86;vox ci gui-visual-review): SHA-256 screenshot cache → review only New/Changed; advisory, never gates. The cache-on-content-hash → review-only-changed pattern is directly reusable for skills. - Code review engine (
vox-code-audit/src/review/mod.rs:48-72):ReviewClientover OpenAI/OpenRouter/Ollama; Markdown/SARIF/Terminal output; 60+ static “TOESTUB” detectors. Default model Sonnet 4.6. Not currently a skill.
1.7 MCP tool registry
Section titled “1.7 MCP tool registry”vox-mcp-registrybuilt fromcontracts/mcp/tool-registry.canonical.yaml;SKILL_TOOLSincludesvox_skill_install/uninstall/list/search/info/parse/use/discover(crates/vox-mcp-registry/src/lib.rs:43-52).- Bridge
vox-orchestrator-mcp/src/plugin_skills_bridge.rs:12-53installs discovered plugin skills but does not validate that a skill’s declaredtoolsexist in the MCP registry, and offers no reverse index (which skills expose tool X).
1.8 Crate layering (where new code goes)
Section titled “1.8 Crate layering (where new code goes)”- Layers L0–L5 (
docs/src/architecture/layers.toml:71-189). Skill crates:vox-plugin-types(L1),vox-mcp-registry(L2),vox-plugin-host/vox-skills/vox-container/vox-code-audit/vox-orchestrator-mcp(L3),vox-plugin-skill-*(L4). - A new
vox-skill-marketplace(L3) fits thevox-code-audit → vox-cli-cipattern: depends onvox-plugin-host+vox-code-audit+vox-db; consumed by MCP/CLI (L5) + GUI.
1.9 Gap ledger (what is genuinely missing)
Section titled “1.9 Gap ledger (what is genuinely missing)”- MCP↔skill SSOT validation + reverse index (declared
toolsunverified). - Discovery/dedup engine — no clone/near-duplicate detection (no MinHash/SimHash/AST hashing anywhere).
- Submission auto-review for skills (review exists for code/GUI, not wired as a skill gate).
- Marketplace backend — publish-validation, storage, index, federation.
- GUI marketplace surface.
- Signing/provenance for skills (OpenClaw mesh has envelopes; skills do not).
- Real versioning — semver field exists, no commit-hash/env-tag model, no dependency resolution/cycle detection.
- Metrics/anti-abuse — placeholder downloads/stars; no anti-typosquat, no staleness demotion.
2. Prior art — agentic review, registries, distribution
Section titled “2. Prior art — agentic review, registries, distribution”2.A Agentic / automated code review as a gate
Section titled “2.A Agentic / automated code review as a gate”- Commercial reviewers (CodeRabbit, Qodo Merge/PR-Agent OSS, Greptile, Bito) converge on severity × category stratification. CodeRabbit’s own framing assumes a human gate and degrades at scale.
- Most reusable: Anthropic’s
claude-code-action+claude-code-security-review— emit severity + CWE + vulnerable snippet + ready fix with false-positive filtering. Same logic as/security-review. - Deterministic floor first: Danger JS (hard-fail rules), reviewdog (comment-on-changed-lines), linters/SAST — cheap, reproducible, hard to game.
- LLM gating patterns: multi-agent/adversarial ensembles beat single agents when detectors are conditionally independent (CodeX-Verify, arXiv 2511.16708); confidence thresholds (~0.6 intervene; ~0.95 stop debating).
- Trust recipe: deterministic floor → ensemble LLM with calibrated system-level confidence → gate only on high-confidence + high-severity → escalate the uncertain middle to a human → measure acceptance rate (not comment volume) as the KPI. Don’t stack overlapping reviewers (causes bulk-dismiss).
2.B Skill / prompt registries (what to standardize)
Section titled “2.B Skill / prompt registries (what to standardize)”- Claude Agent Skills (SKILL.md):
name/descriptionrequired;allowed-tools/disable-model-invocationoptional; no version/license field; git-only versioning; workspace trust dialog, no signing. - Official MCP Registry: JSON-Schema’d
server.json; REST/OpenAPI for downstream aggregators; federated subregistries; namespace auth (GitHub OAuth / DNS-TXT) — but explicitly separates metadata hosting from trust and delegates scanning downstream. - Smithery/Glama/mcp.so: browse only, no vetting (>1/3 of 8k servers had SSRF). Agensi: adds an 8-point automated security scan tier.
- LangSmith Prompt Hub / PromptHub: the only registries with real versioning — immutable content-hash commit + mutable env tag + diff (LangSmith); git-style branch/commit/merge/rollback (PromptHub). Borrow this.
- Lessons: separate metadata from trust; namespace auth solves authorship not safety; signing is absent everywhere (a differentiation gap to own).
2.C Decentralized / local-first distribution (composite of proven primitives)
Section titled “2.C Decentralized / local-first distribution (composite of proven primitives)”- Content-address every artifact (Cargo cksum, Nix narHash, IPFS CID) — integrity + dedup, host-independent.
- Serve via dumb static/CDN index or git-federated taps (Cargo sparse index, Homebrew taps) — anyone can mirror/host; publishing optional.
- Anchor canonical truth in an append-only transparency log (Go sumdb inclusion/consistency proofs, Sigstore Rekor) — untrusted hosts serve bytes; integrity/non-equivocation stay global.
- Sign for provenance: minisign/ed25519 (offline, local-first) or cosign+Sigstore (CI identity — JSR’s choice); SLSA for build provenance.
- Govern keys with TUF (role-based threshold signing; survives compromise/rollback).
- Anti-pattern: Deno raw-URL imports (host decentralization without content-addressing or a verifiable index) — Deno abandoned it for JSR.
2.D Rust crate stack (maturity-rated)
Section titled “2.D Rust crate stack (maturity-rated)”- Clone detection:
tree-sitter(AST normalize; mature) →simhash/gaoya(LSH candidate gen; gaoya niche) →strsim(ubiquitous) /tlsh2(fuzzy confirm; niche).probminhashfor weighted Jaccard. Avoidminhash-rs. - Content addressing:
blake3(CIDs; very mature);sha2only for OCI/Sigstore interop (note: manifesthashis currently SHA-256). - Signing:
minisign/rsign2(local-first, low risk);sigstoreoptional tier (pre-1.0);ed25519-dalek2.x (not 3.0 RC). - Storage/search:
tantivy(FTS) +redb(ACID embedded KV — prefer over stalledsled). - P2P (future):
iroh+iroh-blobs(1.0, 2026-06-15) for content-addressed sync;libp2ponly if a DHT is needed (pre-1.0). - Frontmatter:
gray_matter+serde_yaml_ng(never plainserde_yaml— unmaintained). Current parser usesserde_yaml/toml; migration candidate.
2.E Similar full attempts — failure modes to design against
Section titled “2.E Similar full attempts — failure modes to design against”- No marketplace combines auto-review + dedup at scale without spam/quality/security leakage. All mature ones converged on automated pre-screen + verification tiers + human review + user reporting.
- FlowGPT (pure community rating → quality collapse), GPT Store (list-first-moderate-later → spam + near-dup copycats), Hugging Face (real malware/pickle scanning still bypassed; flags-don’t-block; answer = safetensors “safe-by-construction”), npm/VS Code Marketplace (typosquat + auto-executing install hooks).
- Anthropic
claude-plugins-community— the direct analog — uses three tiers (community automated screen → Anthropic Verified human → official curated). They explicitly did not trust automation alone.
3. Synthesis → design constraints (carry into the design doc)
Section titled “3. Synthesis → design constraints (carry into the design doc)”- Tiered trust, not auto-review-as-truth. Auto-review is a floor; layer a human-verified badge + curated tier (mirror Anthropic’s three tiers). Map onto existing
TrustLevel(Untrusted/Community/Trusted). - Gate before listing (hold-then-publish), never publish-then-takedown.
- Review pipeline: deterministic floor (compile/lint/
vox-code-auditdetectors) → ensemble LLM review (reusevox-code-audit::review+claude-code-security-reviewshape: severity+CWE+fix+FP-filter) → gate on high-confidence high-severity → escalate middle → KPI = acceptance rate. Reuse the content-hash cache → review-only-changed pattern fromvisus_review. - Exploit the local-first edge: run review + capability analysis + dedup-against-installed in the existing
vox-containersandbox, pre-execution, on the user’s machine. Turns HF’s advisory-server weakness into a hard pre-execution gate — our differentiator. - Safe-by-construction: declarative manifest + explicit capability/permission declarations + no arbitrary code execution on install (kills the npm attack class). Scanner is bypassable → always pair with runtime sandboxing.
- Dedup at submission and discovery time: semantic (tree-sitter → simhash/gaoya → tlsh2/strsim) + lexical/name-collision (typosquat) detection; enforce unique, non-confusable names. Same engine powers local “repeated block/prompt” mining.
- Distribution: content-address (
blake3) → static sparse index + optional git-tap federation → append-only signed log (Go-sumdb/Rekor pattern) → sign withminisign(local) / Sigstore (CI) → TUF key governance. Keep P2P (iroh) as an optional transport behind a signed index, not the source of truth. Avoid raw-URL imports. - Versioning: borrow LangSmith’s immutable content-hash commit + mutable env tag + diff (no skill registry has real versioning — own it).
- Surfacing: do not rank by popularity (attack surface); weight by verification + provenance + freshness (last-updated, compiles-against-current); auto-demote stale entries.
- Close the MCP↔skill SSOT: validate skill
toolsagainstvox-mcp-registryat submission; build a reverse index (tool → skills); treat MCP tools and skills as two projections of one catalog.
4. Open questions for the design session
Section titled “4. Open questions for the design session”- Discovery trigger/UX: background daemon vs on-demand
voxcommand vs IDE/GUI nudge? How aggressive (advise-not-gate, per our auto-derivation hygiene)? - Mining source of truth: codebase only, or also session transcripts (prompts/agent flows)? Transcripts raise privacy/provenance questions before any publish.
- First sub-project: the four subsystems (local discovery+dedup engine / agentic submission review / decentralized distribution+signing / GUI) likely need their own spec→plan cycles. Which is the wedge? (Recommendation: the local discovery+dedup engine, since it is the local-first core, has no server dependency, and its similarity engine is reused by submission-time dedup.)
- “Not limited to Vox”: how language-agnostic must clone detection be at v1? (tree-sitter supports many grammars; scope to Vox first?)
- Registry identity: reverse-DNS + GitHub OAuth (MCP-registry model) acceptable, or tie to existing OpenClaw mesh identity/envelopes?
5. Source pointers
Section titled “5. Source pointers”Codebase: see file:line citations in §1. External prior art: Anthropic claude-code-action / claude-code-security-review / claude-plugins-community (three-tier); Official MCP Registry (modelcontextprotocol.io/registry); LangSmith Prompt Hub versioning; Cargo sparse-index RFC 2789; Go sumdb; Sigstore/Rekor + TUF + SLSA; Homebrew taps; JSR (Deno) post-mortem on raw-URL imports; Hugging Face pickle-scan bypass (ReversingLabs/JFrog); GPT Store spam (TechCrunch). Crates: blake3, minisign/rsign2, ed25519-dalek, tantivy, redb, tree-sitter, simhash/gaoya, strsim, tlsh2, probminhash, iroh/iroh-blobs, gray_matter/serde_yaml_ng.