No compliments / no praise. Don’t tell authors their work is good. Omit “Strengths.” Don’t include non-actionable “this part is correct” notes (the only exception: a brief “leave X as-is” guard if there’s real risk of them breaking a working piece while changing other things — and frame it as guidance, not praise).
No testing-context asides. Never mention how the finding was produced (no “we ran read-only”, “no funds moved”, etc.). State findings as facts about the plugin / API / contracts, e.g. “POST /x returns HTTP 500 on all endpoints,” “the API requires an object, not a string,” “Seaport calldata isn’t returned as hex.”
Cite specifics: field names, endpoints, file paths, section names, contract behavior. Link shared files (e.g. the tag vocabulary in ) when asking for an edit there.
Open with one neutral framing sentence (what’s needed before merge, no praise). Then group findings:
markdown
<one-line framing — e.g. "A few changes before merge:" or "There are structural and functional issues to resolve before this can be reviewed for merge.">**Required**- <blocking/major items — what's wrong + the concrete fix>**Minor**- <minor/nit items>
Use Required for blockers/majors, Minor for the rest. Call out “blocking” explicitly when an item makes the plugin unusable for the default wallet or unroutable.
If there are no required items, omit the Required section (don’t pad).
Sub-bullet multi-part items (e.g. several request-schema mismatches under one bullet).
Contribution scope (Required) — if the PR edits shared/registry files. Tell them to revert the SKILL.md plugins-table row and any references/plugin-spec.md edits to the Integration Types “Examples” cell, the “Existing Plugin Conformance” table, or the plugin count — maintainers register plugins when the program is ready. Preserve only a genuinely net-new tag-vocabulary addition. Limit the diff to plugins/<slug>.md (+ that tag line). Tailor: list exactly which files/edits to revert for this PR.
Promotional / steering language (Required). If the plugin copy contains yield/rate/performance claims, directional recommendations (“you should buy X”, “always deposit here”), default parameters steering toward specific tokens, or actions routing outside Base without clear user intent — request removal. State the specific text that needs to change.
API geoblock gap (Required) — for perps/prediction-market/gambling plugins. If the protocol’s frontend geoblocks US IPs but the API serves them, flag this as a blocker and ask the submitter to confirm whether API-level restrictions are planned or already enforced.
High-risk category note — for perps, prediction markets, privacy plugins. Note that plugins in these categories require additional review before inclusion as a native plugin. This is informational to the submitter, not a change request on the plugin itself.