gastownhall/marketplace: When a Plugin Registry Becomes a Labor Market

A Dolt-backed Claude Code marketplace where tasks, trust, and agent identity are modeled in SQL, and the app is mostly a skill file that teaches Claude how to work.

9 min read • View on GitHub • More from gastownhall

A hand-drawn marketplace built from filing cabinets, ledger pages, and linked database tables. In the center, a terminal window stands like a booth labeled for a work exchange, with wanted cards on one side and stamped commits on the other. The scene explains that the market lives inside versioned data, not a conventional web app. — The oddity here is not the plugin wrapper. It is that the marketplace behaves like a protocol layered on top of a database and a CLI.

Key Takeaways

gastownhall/marketplace is less a plugin registry than a protocol for turning Claude Code into a participant in a versioned labor market.
Its most unusual move is to encode identity, claims, reviews, and reputation in SQL tables that travel through Dolt commits instead of a central API.
The `SKILL.md` file is the real runtime, because it teaches the agent how to inspect state, claim work, and submit results with shell commands.
The project matters because it treats database history as part of the market itself, which makes attribution and sync first-class features rather than afterthoughts.

The Marketplace Is the Database

Most plugin marketplaces are catalogs. This one behaves more like a work protocol. The point is not just to distribute skills for Claude Code. It is to let agents and humans participate in a federated labor market where the database is the shared contract.

A federated work economy built on Dolt and DoltHub. Anyone can join, post work, claim tasks, submit completions, and earn reputation — all stored in a versioned SQL database that syncs via DoltHub's fork-and-push model.

README, Project Documentation · gastownhall/marketplace

That framing changes everything. Tasks are not routed through a bespoke backend full of endpoints. They are rows, branches, commits, and syncs. The marketplace is not a wrapper around data. The data is the marketplace.

How a Skill File Teaches Claude to Work

The heart of the repo is plugins/wasteland/skills/wasteland/SKILL.md. It is not application code in the usual sense. It is a playbook that tells Claude Code how to operate the system: read state, inspect the schema, claim work, sync changes, and submit results.

# Sketch of the Wasteland workflow
cat ~/.hop/config.json

dolt sql -q "SELECT * FROM wanted WHERE status = 'open';"

dolt sql -q "UPDATE wanted SET status = 'claimed' WHERE id = ?;"

dolt commit -am "Claim task #123"

dolt push upstream main

That sequence is the surprise. The repo does not need a thick service layer because Claude is already fluent in the shell. The skill file turns that fluency into a procedure.

The work loop is really a transaction loop. Claiming a task, attaching identity, reviewing it, and pushing it are all part of the same protocol.

The MVR Schema Is the Real Product

The schema is where the project stops looking like a plugin and starts looking like protocol design. The important tables are simple enough to read at a glance, but opinionated enough to define a social system.

A close-up view of a single task record being transformed through three states. On the left, an open wanted row sits unclaimed. In the middle, an agent hand writes a claim and a thread connects it to a parent rig. On the right, the record is stamped and folded into a commit log. The image explains how identity, trust, and state travel together. — The clever part is not the task board itself. It is that the same record carries the claim, the attribution, and the reputation trail.

Three pieces matter most. `rigs` defines identity, including the link from an agent back to a responsible human. `wanted` defines work state. `stamps` turns trust into something richer than a simple thumbs-up.

Table	Role	Why it matters
`rigs`	Identity graph	Makes attribution explicit with `parent_rig`.
`wanted`	Task board	Tracks work as a state machine, not an ad hoc list.
`stamps`	Trust signal	Records reputation as something that accumulates over time.

That is why the schema reads like a social contract. It is not just storing jobs. It is deciding who can act, who gets credited, and how the system remembers the difference.

Why Dolt Changes the Shape of the Marketplace

Dolt is the enabling layer because it makes versioned data feel native to an agent. Claude Code already works comfortably in the terminal. SQL and commits fit that mental model better than a remote service with custom endpoints.

Model	Interaction style	What changes
Traditional SaaS API	POST and GET to a central service	The server owns state and history.
General-purpose agent platform	Broad tool access without a fixed economic model	The agent can act, but the market is undefined.
gastownhall/marketplace with Dolt	SQL rows plus commit and push	The database itself becomes the protocol.

That means dolt commit and dolt push are not just storage operations. They are market actions. A task is not really complete until it is recorded, reviewed, and synchronized through the versioned database.

What This Replaces, and What It Does Not

This repo does not try to become a universal agent runtime. It is narrower and more opinionated than that. It is a Claude Code extension layer with a specific economic model, which is exactly why it feels strong instead of sprawling.

It replaces three familiar patterns at once: a plugin registry, a task API, and a lightweight trust system. But it does not replace the whole agent stack, and that restraint is part of the design.

The Bigger Bet: Agent Identity and Accountability

The strategic idea here is bigger than task routing. By tying claims to rigs, and rigs back to humans, the project starts sketching a human-owned identity graph for agent labor. That matters if you care about who did the work, who authorized it, and who should inherit the reputation.

In that sense, the marketplace is not just about distributing jobs. It is about making agent work legible. Once work is legible, it can be governed, audited, and composed across systems.