What tripped me up getting a Claude Code plugin through the Claude plugin directory

Shivaa Tripathi — Mon, 02 Nov 2026 20:04:33 +0000

I maintain an open-source Claude Code plugin: marketing agents for B2B SaaS, plus a mod that adds a live pane to Claude Code. I submitted it to Anthropic's plugin directory on Oct 8. For about a week every version was refused before it was even scanned. On Nov 3 it passed the security scan and went to a human reviewer.

Here is what I would check before submitting, in the order I'd check it. Everything below either happened to my submission or comes from Anthropic's docs, which are linked.

1. `claude plugin validate` passing is not enough

Run it first, from the folder that contains your plugin folder:

claude plugin validate ./your-plugin

It only checks that your files are well-formed. The directory checks more: whether you have a README and a license, whether the name is taken, file sizes, what your hooks run. Use the Validate step in the developer portal (claude.ai/directory/manage) before you submit. The pre-submission checklist lists every finding and whether it blocks you.

2. Put a README inside the plugin folder

The plugin folder is the one that contains .claude-plugin/plugin.json. If your plugin lives in a subfolder of the repo, a README at the repo root doesn't count.

The checklist's rule: at least 40 words, in the plugin folder, and words inside code blocks don't count. Without it, validation blocks. The directory also shows this README as your listing's description, so write it for someone deciding whether to install.

3. Check your `.gitattributes` line-ending rules

This is the one that cost me a week. My repo had this:

* text=auto

*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf

The portal marked every new version "Refused before scanning" and pointed at .gitattributes. What fixed it:

* text=auto eol=lf

*.ps1 text eol=lf

# Must stay after every rule that matches them (including `*` above).
*.bat -text
*.cmd -text

Two notes:

This came from the portal's message on my own submission. The public checklist separately says export-ignore, export-subst and content-rewriting attributes like filter (Git LFS included) stop validation. Check for both.
After you push a fix, select Check for new commits on the plugin's page. Otherwise the directory waits for its next scheduled check.

4. If you have hooks or a mod, write down what each hook does

The checklist asks you to describe in the README everything the plugin runs, sends or fetches. I added a short section to the plugin README, one line per hook:

- `session.start`: registers the `/campaign-board` command and checks whether
  `brand-context.md` exists in your project folder.
- `tool.call` for `Write` and `Edit`: runs the call first, unchanged. Afterwards
  it reads the written text for `[NEEDS INPUT]` markers to show in the pane.
- `ui.render`: draws the pane.

My scan passed, and the version was then held for content policy review with the reason "This plugin includes a mod." The docs are clear that a hold isn't a rejection: a reviewer reads the version before it can go live, and every new listing gets a person's review anyway.

5. Bump `version` in plugin.json every time you ship

If plugin.json sets a version and you don't change it, people who installed keep their cached copy. Mine sat on 1.3.0 for two weeks, and installed copies missed 47 commits. Both the submit guide and the plugin versioning docs say to raise it with every release.

6. Tell users how to update

Updating takes two commands, then a restart:

claude plugin marketplace update <marketplace>
claude plugin update <plugin>@<marketplace>

The first one only refreshes the marketplace. On its own it doesn't update the installed plugin. Auto-update is off by default for third-party marketplaces, so put these two lines in your README.

7. Know what the portal statuses mean

From Track your directory submission:

Scanning: Anthropic is running the security scan. Nothing for you to do.
Needs changes: the newest version didn't pass, or couldn't be fetched. The page names what to change.
In review: a reviewer is checking it. If the version was held, the card names the category.
Approved: the version passed but isn't live yet. Approved doesn't mean people can install it.
Published: live in the directory.

Where mine is now

In review, held for the mod. I'll add the outcome here when the reviewer decides.

If you want a working example to copy from, the repo has the plugin-folder README with the hook list, the fixed .gitattributes, and a plugin.json that gets a version bump every release: github.com/shalintripathi/saas-marketing-agents

What is an AI SEO agent? A practical guide for 2026

Shivaa Tripathi — Mon, 20 Jul 2026 20:15:39 +0000

Originally published on organicos.shivaatripathi.com.

In short: An AI SEO agent is software that runs the search-optimization loop on your site continuously - observing performance, proposing changes, applying approved ones, and measuring outcomes - instead of producing a one-time audit. The useful ones keep a human in the approval path and remember what worked, so the site improves across runs rather than resetting each session.

Search-optimization tooling has spent a decade producing reports. You run an audit, it lists 200 issues, you fix a few, and the report is stale the moment your site or the SERP changes. An AI SEO agent is a different shape of tool: it does not stop at the report. It runs the loop - observe, decide, apply, verify, learn - on a schedule, and carries what it learned into the next run.

This matters more now than it did two years ago, because search itself has split. Buyers still type queries into Google, but they also ask ChatGPT, Perplexity, and Google's AI Overviews, and those engines cite sources by different rules. Optimizing for both at once, continuously, is more work than a person can do by hand and more judgment than a fire-and-forget script can be trusted with.

What separates an agent from an audit tool

It runs on a schedule and remembers. A point-in-time audit is blind to what it recommended last month and whether it worked. An agent keeps a per-site playbook, so a change that measurably helped becomes a reusable pattern and a change that did nothing gets retired.
It can act, not just advise. An agent can apply the fix - update a title tag, publish a draft - through your CMS, then verify the change actually landed on the live page.
It measures outcomes against what it shipped. Because it remembers what it changed and when, it can attribute a movement in clicks or citations to a specific edit, rather than guessing.

What an AI SEO agent optimizes for in 2026

The best-supported tactics are not the ones most SEO content repeats. A controlled experiment across 10,000 queries, the Generative Engine Optimization paper (KDD 2024), found that named expert quotes lifted a page's visibility in AI-generated answers by 40.9%, statistics paired with named sources by 30.6%, and inline citations by 27.5%.

Two more findings shape a modern agent's checklist. Vercel and MERJ, analyzing more than a billion AI-crawler requests, found that the major AI crawlers do not execute JavaScript - so a client-side-only page is invisible to them. And Seer Interactive found that 87% of SearchGPT citations matched Bing's top organic results, which means Bing indexation, not only Google's, is now load-bearing for AI visibility.

Why the human-in-the-loop design matters

The obvious fear with an agent that can edit your site is that it makes a bad change while you sleep. The answer is not to trust the model's judgment; it is to make unapproved changes impossible by construction. In a well-built agent, every write is gated on a recorded approval, enforced in code, not by convention. A change with no matching approval record simply cannot be applied.

This is also where honesty about limits belongs. Google's scaled content abuse policy treats mass-produced, low-value pages as spam. An agent that lets you dump fifty thin articles overnight is not helping you; it is helping you get penalized. The gate, and the human on the other side of it, is what keeps volume honest.

How to evaluate one

Does it run on a schedule and keep memory across runs, or is it a dressed-up one-time audit?
Can you verify its safety claims yourself, or are you asked to take them on faith?
Does it label weak tactics honestly? Adding schema markup, for instance, shows no measured lift in AI citations in controlled testing - a tool that sells it as an AI-visibility tactic is overselling.
Where does your data live, and does the tool phone home?

I build organic-os, an open-source implementation of this pattern as a free Claude plugin (MIT). It runs its own site in public, with a work log of every change and outcome. But the questions above apply to any agent you evaluate.

DEV Community: Shivaa Tripathi