Local-first Claude Code plugins: no keys, no network, open source

Local Plugins — Tue, 14 Jul 2026 13:30:56 +0000

I keep living inside Claude Code, and I kept wanting small, useful tools in
there that didn't phone home. Not another SaaS with a login and an API key,
just something that runs on my machine, does one job well, and that I can read
before I trust it.

So I packaged the workflows I actually use into a few open-source plugins and
put them in one marketplace. This is the first write-up.

What "local-first" means here

The rule I set for myself: a plugin should run entirely on your machine by
default. No account, no API key, no network call, nothing uploaded or
auto-posted. And if a plugin genuinely needs the network, it should be:

obvious,
isolated to a single module,
off by default, and
using your own key.

That way you can grep the code and see exactly what touches the outside
world. For a tool that generates your logo or your résumé, that inspectability
matters.

Two honest exceptions, called out up front: docpin fetches library
documentation from the web (always cited), and brand-forge has one opt-in
module that can call an image API for AI photography. Everything else is local.

What's in the suite

brand-forge — save a brand profile once (colors, fonts, voice), then generate on-brand logos, social templates, and doc/deck templates as SVG. The vector output is drawn by local code, so it's deterministic: the same profile always produces the same asset.
cv-forge — keep one résumé in the JSON Resume schema, generate a clean, ATS-friendly PDF from a local HTML template and your browser's print. No Node, no keys, no network.
content-multiplier — turn one idea into on-brand, multi-channel, multi-language content from a single command.
docpin — ground code against your installed version of a library by pulling version-matched, cited docs.
plus a couple more in the same spirit.

Installing

Everything installs through Claude Code's plugin system. In a session:

/plugin marketplace add localplugins/plugins
/plugin install brand-forge@localplugins

Then a natural request like /brand-make instagram post "We just shipped" uses
your saved brand and returns an editable SVG in output/.

A few design choices worth calling out

Deterministic generation over an LLM round-trip. brand-forge's logos and
templates are generated by plain code from your profile, not by asking a model
to draw them. That makes them reproducible, diffable, and editable, and they
don't drift between runs.

The network boundary is a single file. In brand-forge, the only module
that can reach the internet is the opt-in image generator. It's off unless you
set an env var and provide your own key, and the text of your asset is
composited locally as an SVG overlay so it never goes into the image prompt.
One file to audit, not a whole codebase.

Plugin anatomy. Each plugin is a normal Claude Code plugin: slash commands,
skills that trigger from natural requests, sometimes a SessionStart hook that
loads context, and in brand-forge's case two subagents (an art-director that
plans a multi-asset set, and a visual-guardian that checks output against the
brand for palette and contrast). If you're building your own plugins, they're
small enough to read as examples.

What this isn't

It's not a design tool that will out-polish a human designer, and it isn't
trying to be. It's a way to get consistent, on-brand, good-enough assets and
documents without leaving your terminal or signing up for anything. If you need
pixel-perfect art direction, use it for the scaffolding and finish by hand.

Try it

It's all MIT and open source, built with Claude Code itself:
https://github.com/localplugins/plugins

I'd genuinely like feedback on two things: what feels useful vs. gimmicky, and
where you think the line should be for what a local-first plugin is allowed to
do. Issues and comments welcome.