Tagged, Iconed, and Submitted to the Claude Directory

Why Care?

Until today, installing the kit meant knowing our GitHub repo and adding it as a marketplace by hand. Once it's approved, Context V will be listed in Claude's plugin directory, where people browsing for plugins can find it. It shows up as Context V: Context Vigilance Kit , with an icon that looks like us.

Getting there turned up a lesson worth sharing: an automated security scanner reads every image you ship as if it might be code, and with enough pixels, chance wins.

What's New?

v0.2.0, the first tagged release. The first week of work is collected in the v0.2.0 release notes and published as a GitHub release . main and master were brought up to date with development first, so context-v.dev and the GitHub Pages copy both show the latest landing page.
A listing icon. .claude-plugin/icon.png is our bearded engineer from the OG image, redrawn by Ideogram as a tight, high-contrast woodcut head that still reads at 32 px.
A display name. The plugin is still cv , so every /cv: command works, but the listing reads "Context V: Context Vigilance Kit".
Submitted for review , with a GitHub push webhook so new versions reach the directory within minutes.

Update, same day: the webhook is live. The repo now has a push webhook pointing at Anthropic's directory API, and its first delivery, GitHub's test ping, succeeded. Without it, the directory checks master about every six hours. With it, GitHub notifies the directory on every push, so a new version is picked up within minutes. Setting it up was all in the browser. The portal hands you a payload URL and a secret, and both go under the repo's Settings → Webhooks : content type application/json , push events only. The secret stays with GitHub, which uses it to sign each notification so the directory knows the push really came from this repo. Nothing in the plugin changed. A webhook only reports pushes; the directory still publishes a new version only when version in plugin.json goes up.

The listing icon: woodcut variant 04.

Picking an Icon

The OG illustration ("Keep Calm w/ Context Vigilance") was the obvious source, but at icon size its lettering and detail blur into a gray square. A crop on the engineer's head held up better. Ideogram did better still.

We ran two batches. A text-only prompt gave four clean, flat emblems that could have been any construction app's logo. Remixing the OG image itself kept the woodcut linework, and all four came back framed tight on the face. Variant 04, on a black background with the cable at the temple, still read as our engineer at 32 px.

The other seven were too good to throw away. They're kept on ImageKit and listed in the brand README , with the prompts and seeds to regenerate them.

What the Scanner Taught Us

The directory's validator runs a security scan over everything in the plugin folder, and our plugin folder is the whole repo, website included. Most of what it flagged was expected:

Finding	What it actually was	What we did
Credential read plus data sent	The site's OpenPanel analytics, in `splash/`	Left for the reviewer: the plugin never runs it
Name resembles `github.com/cv`	A two-letter name	Added a display name
Hook "can approve" tool calls	Our frontmatter check, which only ever blocks	Informational
`.npmrc` sets a registry	The site's public JSR registry	Informational
Image body contains a download-and-execute shell pattern	Random bytes	See below

That last one is the story. We first committed all eight icon candidates as PNGs. The scanner reads printable text inside images, and in one file's compressed pixel data, a run of bytes happened to look like a … | sh command. So we stripped all metadata and re-encoded every PNG: zero pixels changed, and the files got 5–20% smaller. The next scan flagged a different file. In a few megabytes of compressed data, some chance match is close to certain.

The fix was to stop shipping images the plugin doesn't use. The eight candidates moved to the CDN as JPEGs, and the plugin now ships one image, its icon. The lossless originals stay in git history at 3ccfe60 .

The lesson for anyone shipping a plugin from a repo that is also a website: the plugin folder is everything the scanner sees. Each image is one more chance for a false positive.

What's Next?

The review itself: an automated scan, then a person looks at the three remaining holds. Once it's approved, we click Publish.
master is now release-only. The directory watches it, and plugin updates ship only when version in plugin.json goes up. Day-to-day work stays on development and goes to main for the site. master moves only for a tagged release.
Maybe: move the plugin into its own subfolder so the site isn't part of the bundle. Worth it only if reviewers keep tripping over splash/ .
The site doesn't render changelog/releases/ yet. Its loader reads only top-level changelog/*.md .