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

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