The store moved to `.kettle/` when the binary replaced the plugin's scripts, but six doc comments in the domain and the project layer still showed `.tea/` paths in their examples. The code was right and the prose was a version behind, which is the failure mode worth catching early: these are the comments somebody reads to learn where the store IS. The `.tea/` that remain are the ones that mean it — the legacy migration list and the tests that exercise it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
claude-skills — a Claude Code plugin marketplace
One repository, one marketplace, several plugins, and the kettle binary the
issue plugin is built on. Register the marketplace once and install whichever
pieces you want; each plugin is independent and carries its own manifest and
docs.
Installation
/plugin marketplace add https://git.noodles.cam/claude-skills/marketplace.git
Working from a local clone? Point at the directory instead:
/plugin marketplace add /path/to/marketplace
Then install what you need:
/plugin install kettle@claude-skills
/plugin install tdl@claude-skills
Use /plugin to enable, disable, or update them later.
kettle also needs its binary, which no plugin can install for you. Build it
from this repository (cli/go.mod requires Go 1.26; vendor/ is committed,
so the build needs no network):
cd cli && go build -o ~/.local/bin/kettle ./cmd/kettle
go install git.noodles.cam/claude-skills/marketplace/cli/cmd/kettle@latest
Put the target directory on your PATH and check with kettle help. A skill
that answers command not found: kettle is telling you exactly this.
What ships here
| Plugin | Commands | What it does |
|---|---|---|
kettle |
/kettle:init /kettle:auth /kettle:issue /kettle:sync /kettle:use /kettle:project |
Issues as local markdown, cleanly layered. Issues are units of work offline first and tracker rows second; the kettle binary does the work, and each skill's command reference is generated from the binary's own command registry so it cannot drift |
tdl |
/tdl:audit |
Three Dots Labs Go conventions as an enforceable rule set — audits a Go project against 63 CQRS/DDD/Clean-Architecture rules by severity, or scaffolds services, handlers, entities, repositories and Watermill adapters from templates that already follow them |
Layout
.claude-plugin/
marketplace.json the catalog — one entry per plugin, source is a
path into plugins/
cli/ the kettle binary: cmd/kettle + internal/*, its
own AGENTS.md, its own tests, vendored deps
plugins/
kettle/
.claude-plugin/plugin.json
agents/ hooks/ skills/
README.md AGENTS.md
tdl/
.claude-plugin/plugin.json
skills/
A plugin's root is its directory under plugins/, so ${CLAUDE_PLUGIN_ROOT}
resolves inside it and every path a plugin uses stays relative to itself.
Adding a plugin means adding a directory here plus one entry in
marketplace.json — nothing else in the repo needs to know about it.
cli/ is deliberately not inside a plugin: a binary is installed on a machine,
while a plugin is a directory Claude Code loads, and collapsing the two is what
put an earlier version's issue store inside a versioned plugin cache.
Development
cd cli && go test ./... # the binary's suite
cd cli && go build -o /tmp/kettle ./cmd/kettle
/tmp/kettle gen skills --out plugins/kettle/skills --check # docs vs binary
The second one is the invariant that keeps the plugin honest: everything a
SKILL.md says about a kettle command — its usage line, its flags, its
examples — is generated from the registry the binary is built from, between
<!-- kettle:gen --> markers. --check exits 1 when any of it is out of date;
run gen skills without it to regenerate. Prose outside the markers is never
touched.