[FEATURE] Plugin directory: let authors add notes for the reviewer when resubmitting

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The Claude plugin directory (claude.ai/directory/manage) gives a plugin author no way to tell the reviewer what changed when resubmitting a plugin after "Not approved".

What happened with the ArcKit core plugin (tractorjuice/arckit-claude, plugins/arckit):

1. v6.16.4 was marked Not approved. The Review tab showed the automated findings, but no written reasons under "Requested changes".
2. We fixed the findings in three changes (removed a permission-granting hook, moved a credential read to an OAuth MCP server, trimmed the package) and released v6.17.0.
3. On the Review tab, Resubmit for review sent the plugin straight to review. No form opened, so there was nowhere to explain which findings were fixed, which were false positives (for example, a curl … | sh string that only appears in documentation, or a file flagged for reading a credential that only builds URLs), and which remain by design.
4. The resubmission went in against the old, rejected version (v6.16.4). The directory hadn't yet detected the new commit (its scheduled check runs about every 6 hours). "Check for new commits" then picked up v6.17.0 about a minute later. Nothing on the resubmit step said which version would be reviewed.

So the reviewer sees the same automated findings with no context, and can't tell which were addressed or why some can't be changed.

Proposed Solution

• A "Notes for the reviewer" field on "Resubmit for review", and ideally on the first submission too: free text, stored with the version, shown to the reviewer next to the findings.
• Show which version will be reviewed on the resubmit step, and offer "Check for new commits first" when the tracked branch has moved since the last scan.
• When a version is Not approved with no written reasons, say so plainly, and point the author to where they can ask.

Alternative Solutions

• Per-finding responses ("fixed in <commit>", "false positive: …", "by design: …") next to each finding.
• A documented contact channel for directory submissions.

Today, the only workaround we found is to put an explanation in the plugin's README and hope the reviewer reads it.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

A plugin is held for "Hook grants permission". The author narrows the hook to read-only access of the plugin's own files, the one thing plugins can't pre-approve natively. They replace two other hooks with updatedInput rewrites that grant nothing. They resubmit with a note that says exactly that, and the reviewer approves in one pass instead of two.

Additional Context

Observed on 29–30 September 2026. The overlays in the same marketplace, 16 plugins, went through without needing notes; the core plugin is the one with policy holds, which is where a note matters most.