Tag every plugin entered in the Hermes Agent Plugin Hackathon (Nous Research, Nov 4 to 11, 2026) by kind, so the public scoreboard of the IMD swarm's judging can be filtered by it. Fifteen seats each tag one slice of the same public results file. The tags help readers find plugins of a kind; they change no score.

The answer

Hermes Agent Plugin Hackathon: plugins by kind

This covers the tag results for the Hermes Agent Plugin Hackathon (Nous Research, Nov 4 to 11, 2026). The plugins were tagged by kind so the public scoreboard of the IMD swarm's judging can be filtered by kind. The tags change no score.

Sources and method

The sources are the fifteen slice results .imd/reads/artifacts/item-tags-00 through item-tags-14 (also at artifacts/goal/items/tags-NN/result.json). Each one is JSON of the form {"slice": n, "tags": [{"pr", "name", "tags"}]}. Every figure below comes from counting those files. Nothing else was used.

Plugins counted: 1,464 entries across the 15 slices (slice sizes 97, 91, 81, 96, 99, 107, 102, 87, 98, 110, 101, 94, 103, 105, 93 for slices 00–14). No plugin name appears twice, and every entry has one or two tags. None is empty, so no slice result is missing or blank.
PR numbers vs plugins: there are 1,442 distinct PR numbers. Eight PRs each hold several plugins, for example PR 153370 (7 plugins in slice 10), PR 149641 (6 in slice 01) and PR 153040 (5 model-forge* plugins in slice 10). The counts below are per plugin, not per PR.
Main tag: the results do not label a main tag. I took the first-listed tag as the main one. Tag order is not alphabetical (307 of the 605 two-tag entries are in alphabetical order, 298 are not), so the order looks deliberate. Still, this is my reading, not something the files state.
Tags used: 23 tags. 859 plugins have one tag and 605 have two.
Not checked: the full public results file was not provided. So I could not confirm that the 15 slices together cover every entered plugin.

How many plugins got each tag as their main tag

Main tag	Plugins (main tag)	Share	Of these, tagged only this	Plugins carrying the tag at all
safety	140	9.6%	83	185
dev	134	9.2%	79	205
memory	103	7.0%	71	117
media	101	6.9%	61	123
automation	91	6.2%	56	118
desktop	85	5.8%	52	169
business	84	5.7%	45	101
research	81	5.5%	55	119
models	66	4.5%	48	90
proof	63	4.3%	30	101
marketing	61	4.2%	44	77
monitoring	59	4.0%	31	94
multi-agent	54	3.7%	19	83
money	46	3.1%	29	68
hardware	45	3.1%	19	52
crypto	41	2.8%	16	55
games	41	2.8%	20	53
devices	36	2.5%	21	48
messaging	35	2.4%	22	61
sandboxes	29	2.0%	16	41
voice	29	2.0%	19	45
health	22	1.5%	17	26
undo	18	1.2%	6	38
Total	1464	100%	859	2069 tag uses

"Plugins (main tag)" counts plugins whose first tag is this one. "Tagged only this" counts plugins whose single tag is this one. "Carrying the tag at all" counts plugins that have the tag in either position. The middle column sums to 1,464 plugins. The last column sums to 2,069 tag uses, which is 859 plus 2×605.

The slices disagree on nothing, because each plugin was tagged in exactly one slice. No plugin was tagged twice, so there was nothing to reconcile.

The ten plugins hardest to place

The results hold only a name and tags for each plugin. There is no description, confidence or "hard to place" flag. So I picked these ten with a rule anyone can re-run on the files:

Take the two-tag plugins whose tag pair occurs only once among all 1,464 plugins. There are 47.
Rank them by how often their two tags would meet by chance: (uses of tag A × uses of tag B) ÷ 1,464.
Keep the top ten. These are plugins that sit across two common kinds which no other entrant combines, so either main tag is arguable.

Each "why" is reasoned from the tags and the name only, since the files hold nothing else.

plagio (PR 151422, slice 12; media, dev): it is the only plugin tagged both media and dev (123 and 205 uses). It reads as part creative tool and part developer tool.
odoo-prod-guard (PR 149142, slice 12; business, safety): it is the only business+safety pair (101 and 185 uses). It guards a business system (Odoo), so the scoreboard could list it under the domain or the guard. It also shares its PR with two other plugins.
developh (PR 151277, slice 02; marketing, dev): it is the only marketing+dev pair (77 and 205 uses). The name points to developers, while the main tag says marketing.
playbox-witness (PR 153141, slice 06; safety, multi-agent): it is the only safety+multi-agent pair (185 and 83 uses). It is a safeguard that is also about running several agents.
imprint (PR 153978, slice 03; research, media): it is the only research+media pair (119 and 123 uses). The name fits either kind, and the tagger chose research first.
onbrief (PR 153685, slice 10; marketing, safety): it is the only marketing+safety pair (77 and 185 uses). Two kinds that seldom overlap had to share one plugin.
tupliq-launchpad (PR 153731, slice 11; money, dev): it is the only money+dev pair (68 and 205 uses). A "launchpad" could be a builder's tool or a funding tool, and money was put first.
stageglass (PR 153194, slice 14; desktop, marketing): it is the only desktop+marketing pair (169 and 77 uses). It splits between the surface it runs on and what it is for.
thumbs-fix (PR 153796, slice 01; dev, messaging): it is the only dev+messaging pair (205 and 61 uses). The name suggests a fix to a chat or reaction feature, so it is either developer work or messaging.
leitmotif (PR 153412, slice 07; monitoring, media): it is the only monitoring+media pair (94 and 123 uses). The name is musical but the main tag is monitoring, and it is the least obvious name-to-tag match of the ten.

The next ones on the same ranking are contract-hunter (crypto, dev), minicpm-ocr (research, models) and reset-rescue (models, automation).

Two more kinds of plugin are hard to place but are not ranked above, because the rule does not measure them:

Bundled PRs: for example, PR 153370 holds seven plugins in six different main-tag kinds (dev, media, business, games), so filtering by PR and filtering by kind give different results.
Single tags: 859 plugins got only one tag, which may hide a second kind.

Per-plugin tags are left out on purpose, as the brief asks. They are in the fifteen source files above.

report.md

The swarm

finishedran 10 minItems, page by page →

Items15 of 15 back
The plane split the request into 15 items. Started under a minute after the job was posted.
Item by item
Write-upAgent #1866made 1 file
I wrote the report to artifacts/goal/writeup/report.md (6,467 bytes, under the 12,000 limit). It has a table of how many plugins got each tag as their main tag, then the ten plugins hardest to place, one line each on why. Per-plugin tags are left out. Every figure was counted by script from the 15 result files.

What the results show

Plugins: 1,464 across all 15 slices, using 23 tags. 859 have one tag and 605 have two. None is empty, none is missing, and no plugin was tagged by two seats, so no slices disagree.

Main tags: safety leads with 140 plugins, then dev with 134 and memory with 103. Undo is last with 18.

PRs: there are only 1,442 PR numbers, because eight PRs each contain several plugins. The report counts plugins, not PRs, and says so.

Two judgement calls, both stated in the report

Main tag: the files don't mark one, so I used the first-listed tag. About half the two-tag lists are not in alphabetical order, which suggests the order was chosen deliberately.

Hardest to place: the files give only a name and tags, with no descriptions or difficulty flag. I picked the ten with a rule anyone can re-run: plugins whose tag pair appears only once in the whole set, ranked by how common both tags are. The "why" lines are reasoned from the name and tags alone, and the report says that.

What I couldn't check: the full public results file wasn't provided, so I can't confirm the 15 slices cover every plugin entered. The report says this too.

A few odd dotfiles (such as .bashrc and .mcp.json) now show as untracked in git. They aren't my files: they are empty placeholders the sandbox adds, not real files in the repository. My only output is the report, which git is set to ignore.
ran onclaude · claude-opus-5-5 · 9 turns · 1m 22s · 18 in · 7.5K out · 243.3K cached
submission12907c450fd294b5c97d54ea4cb9bac3712b8b3cdd2d695df00c5ebe4a5b9705
devicea0f4c3f900dedd4aabe971a8242dd59ceecfd9066905b2db612ba57cc277e451
started from0243d7da4a4337ae8b16bcdf15bb4ead736fd68f
bundlenone
verifiedrebuilt and matched · verifier 0.1.0 ·
made · 1 file
artifacts/goal/writeup/report.md · 6.5 KB
may write
artifacts/goal/writeup/**
JudgeAgent #1505found 2 medium, 4 low, 1 info
The review is finished: no high-severity defects, two medium and four low, all written to .imd-findings.json. The report is usable as it stands; nothing here needs a rewrite.

The fifteen slice files were not in my tree, so I could not recount the figures from source. I checked that every total in the report agrees with its own table and spot-checked the cited PRs against public GitHub.

Medium

"Ten plugins hardest to place" (lines 58–67): four of the ten reasons are guesses from the name that the cited PR contradicts.

tupliq-launchpad (PR 153731): the report calls it possibly "a funding tool"; the PR says RevenueCat revenue metrics plus Play Store changelog drafting.

thumbs-fix (PR 153796): the report says "a fix to a chat or reaction feature"; the PR says a Telegram thumbs-down triggers a reviewed edit of the skill behind a bad reply.

leitmotif (PR 153412): the report calls it the "least obvious name-to-tag match"; the PR says it plays a musical motif for every tool call so you can hear the agent, which matches both tags.

developh (PR 151277): the report says "the name points to developers"; Developh is the name of a Lisbon studio offering website audits.

Bundled PRs bullet (line 73): "seven plugins in six different main-tag kinds (dev, media, business, games)" states six and lists four. The PR's own entry list (four of the seven are audio or video tools) suggests the count is the error.

Low

Main tag (line 11): "307 of 605 alphabetical, 298 not, so the order looks deliberate" does not follow, since a 50.7/49.3 split is what arbitrary order gives. The table is sorted by this reading, while a filter returns the "carrying at all" count: desktop is 169 by filter but shown sixth at 85.

PR numbers vs plugins (line 10): PR 149641 is given as holding 6 plugins, but the PR lands about 14 entries copied from eleven original PRs. The report does not say where the rest are, which is a concrete place to test the coverage gap it admits on line 13.

Table note (line 44): "The middle column sums to 1,464" names the wrong column; it is the second, "Plugins (main tag)".

Tag table (lines 19–41): the 23 kinds are never defined, so a reader cannot tell hardware from devices, or know what proof and undo cover.

What held up

Slice sizes sum to 1,464, and the three count columns sum to 1,464, 859 and 2,069 (= 859 + 2×605).

All 23 shares are correctly rounded and sum to 100.0.

The top-ten order and the three runners-up match the stated rule when recomputed from the table.

PRs 153370 (seven plugins), 153040 (five model-forge packages) and 149142 (three, including odoo-prod-guard) say what the report says, and the PRs for the ten ranked plugins are each that plugin's catalog PR.

This is recorded as a seventh, info-level entry in the file. I left path, line and snippet empty on every finding, as the reference asks for deliverable findings; line numbers and quoted text are in each description. No repository files were changed.
ran onclaude · claude-fable-5-2 · 14 turns · 3m 59s · 15 in · 21.6K out · 262.9K cached
submissionfb7c9b78c9f5a0123ded4322c9c92585bf0b0bbe5a0b2a106b95319747f179d8
device93c37f17670e4d982c10b72df46740cbf62f916f96c4f04e932b48262a78a8d4
started from0243d7da4a4337ae8b16bcdf15bb4ead736fd68f
bundlenone
medium"Ten plugins hardest to place": several of the reasons are name guesses that the cited PRs contradict
Section "The ten plugins hardest to place" (report lines 58-67) gives a reason for each plugin that is, by the report's own statement (line 56), "reasoned from the tags and the name only". Each entry cites a PR number, and those PRs are public (github.com/NousResearch/hermes-agent/pull/) and say what the plugin does. For at least four of the ten, the stated reason does not match what the cited PR says, so a scoreboard reader is told something untrue about an entrant's work.

(a) Item 7, tupliq-launchpad, PR 153731: the report says "A 'launchpad' could be a builder's tool or a funding tool, and money was put first." The PR says it is "RevenueCat revenue & subscription metrics for your apps plus git changelog drafting for Play Store releases". It is not a funding tool; the money/dev split is revenue metrics versus release notes.

(b) Item 9, thumbs-fix, PR 153796: the report says "The name suggests a fix to a chat or reaction feature". The PR says a thumbs-down reaction on Telegram to a bad reply makes the plugin name the skill behind the reply, draft an edit to that skill and apply it after approval. It repairs skills, not a reaction feature.

(c) Item 10, leitmotif, PR 153412: the report says "The name is musical but the main tag is monitoring, and it is the least obvious name-to-tag match of the ten." The PR title section is "Leitmotif: hear what your agent is doing": every tool call becomes a musical motif so loops, errors and pending approvals are audible. Name and both tags match the plugin directly; it is not an unobvious match.

(d) Item 3, developh, PR 151277: the report says "The name points to developers, while the main tag says marketing." The PR says Developh is the name of a design and development studio in Lisbon, and the plugin runs free website audits (PageSpeed/Lighthouse) and has a request_contact tool that sends the studio a project inquiry. The name is the vendor's name, not a pointer to an audience.

The other six reasons (plagio, odoo-prod-guard, playbox-witness, imprint, onbrief, stageglass) are consistent with their PRs. This fails the goal's sources test: the claims have no source, and the source the report itself names by number says something else.
Open https://github.com/NousResearch/hermes-agent/pull/153731, /pull/153796, /pull/153412 and /pull/151277 and read the first paragraph of each description.

Expected: each reason in report lines 60, 64, 66 and 67 matches what the PR says the plugin does.

Actual: 153731 is RevenueCat revenue metrics plus Play Store changelog drafting (report: "a funding tool"); 153796 turns a Telegram thumbs-down into a reviewed edit of the skill behind the reply (report: "a fix to a chat or reaction feature"); 153412 plays a motif for every tool call so the user can hear the agent (report: "least obvious name-to-tag match of the ten"); 151277 is a studio named Developh offering website audits (report: "The name points to developers").

Fix by replacing each reason with one line from the PR description, or by dropping the name-based guesses and keeping only the tag-pair fact.
mediumBundled PRs bullet: "six different main-tag kinds" is followed by a list of four
Report line 73, under the bullet "Bundled PRs", reads: "PR 153370 holds seven plugins in six different main-tag kinds (dev, media, business, games), so filtering by PR and filtering by kind give different results." The sentence states six kinds and then names four. One of the two is wrong, and the report gives no way to tell which.

The PR itself (github.com/NousResearch/hermes-agent/pull/153370) lists the seven entries as skill-workshop (build and guard skills), pagecast-director (cast narration of books), creator-studio (lesson videos, podcasts, captions), live2d-rigger (rig a Live2D character), game-lab (game modding and localization), watch (stream anime, films and TV in mpv) and case-trail (case-history research).

Four of those seven are audio or video tools, which makes six distinct main kinds among seven unlikely and points to the count, not the list, being the error. The figure is stated but its own text does not give it.
Read report line 73 and count the kinds inside the brackets: dev, media, business, games = 4.

The sentence says "six different main-tag kinds".

Expected: the count and the list agree.

Actual: 6 stated, 4 listed.

To settle it, take the seven entries with pr = 153370 in item-tags-10 (the report places all seven in slice 10, line 10), collect the first tag of each, and count the distinct values; state that number and list exactly those tags.
low"Main tag" rests on tag order, and the evidence given for it (307 vs 298) does not show the order is deliberate
Report line 11, "Main tag", says: "Tag order is not alphabetical (307 of the 605 two-tag entries are in alphabetical order, 298 are not), so the order looks deliberate." A 307/298 split is 50.7% to 49.3%, which is what an arbitrary or random order would give. It shows only that the tags were not sorted; it says nothing about whether the first tag was meant as the main one.

The report does add "this is my reading, not something the files state", but the whole table is sorted by this reading, and its "Plugins (main tag)" and "Share" columns depend on it. The goal is a scoreboard filter, and a filter on a tag returns every plugin carrying it, which is the last column. The two orders differ: by plugins carrying the tag, desktop is third (169) and dev is first (205), while the table puts safety first (140 main) and desktop sixth (85 main).

A reader who filters by desktop gets 169 plugins, about twice the 85 and 5.8% the table leads with.
Compute 307/605 = 50.7% and 298/605 = 49.3% from line 11: expected, for the claim "so the order looks deliberate", a split far from half; actual, a split at half.

Then sort the table (lines 19-41) by its last column: dev 205, safety 185, desktop 169, media 123, research 119, automation 118, memory 117.

Compare with the printed order: safety, dev, memory, media, automation, desktop.

Either say plainly that the main-tag counts are an assumption without the alphabetical argument, or lead with the "carrying the tag at all" column, which is what the filter returns.
lowPR 149641 is given as a PR holding 6 plugins; the PR itself lands about 14 entries, and coverage of the slices is unconfirmed
Report line 10, "PR numbers vs plugins", gives "PR 149641 (6 in slice 01)" as an example of a PR that holds several plugins. The PR (github.com/NousResearch/hermes-agent/pull/149641, "Catalog: land 11 reviewed entries whose forks refuse maintainer pushes") is a maintainer copy of other people's PRs.

Its table lists local-mcp, makernice, adwave, habitude, onda, serpkite, blackbox, belive-aihub, adaption, cliproxyapi-provider, cpa-status, ethics-filter, soul-finder and hermes-band, each with its original PR number (#148013, #148442, #148637, #148671, #149062, #149160, #149163, #149509, #149559, #148480, #149362). So the results file carries 6 of roughly 14 entries under this PR number, and the report does not say where the others are.

Either they sit under their original PR numbers, in which case the same batch is split across two numbering schemes and "1,442 distinct PR numbers" and "Eight PRs each hold several plugins" do not describe submissions the way the sentence implies, or they are not in the slices at all. Line 13 already admits that coverage of "every entered plugin" was not checked; this is one concrete place where that gap can be tested.

I could not test it myself because the fifteen slice files were not supplied to this review.
Open https://github.com/NousResearch/hermes-agent/pull/149641 and read the entry table: 11 rows, about 14 entry names.

Then search the fifteen item-tags-NN files for those 14 names and note the pr value on each.

Expected from line 10: the PR holds 6 plugins.

Actual per the PR: about 14 entries.

Report which of the 14 names are present, under which PR number, and which are absent; if any are absent, line 9's "1,464 entries" is not every entered plugin and the report should say so next to the total.
lowTable note names the wrong column: "The middle column sums to 1,464 plugins"
Report line 44, the note under the main-tag table, says: "The middle column sums to 1,464 plugins." The table has five columns: Main tag, Plugins (main tag), Share, Of these, tagged only this, Plugins carrying the tag at all. The middle column of the five is "Share" (sums to 100%).

The middle of the three count columns is "Of these, tagged only this" (sums to 859). The column that sums to 1,464 is the second, "Plugins (main tag)". The totals themselves are right; the note points the reader at the wrong column.
Add the columns in lines 19-41.

"Plugins (main tag)": 140+134+103+101+91+85+84+81+66+63+61+59+54+46+45+41+41+36+35+29+29+22+18 = 1,464.

"Of these, tagged only this": 83+79+71+61+56+52+45+55+48+30+44+31+19+29+19+16+20+21+22+16+19+17+6 = 859.

Expected: the note names the column that gives 1,464.

Actual: it says "the middle column", which is Share or the 859 column.

Change it to "The 'Plugins (main tag)' column".
lowThe 23 kinds are listed without a word on what each means
The goal says the tags "help readers find plugins of a kind". The table (report lines 19-41) lists 23 tags and the report never says what any of them covers. Several cannot be told apart or read from the name alone: hardware (45 main, 52 carrying) against devices (36 main, 48 carrying); money (46/68) against crypto (41/55) against business (84/101); and proof (63/101) and undo (18/38), which are not ordinary category words.

A reader choosing a filter has no way to know which of hardware and devices to pick. The report says the slice files hold only names and tags (line 50), so if the tag meanings were set in the tagging brief they should be quoted from it, and if they were not, the report should say that the kinds are undefined.
Search the report for a definition of hardware, devices, proof or undo: each appears only as a table row (lines 33, 36, 28, 41) with counts.

Expected: one line per tag, or a pointer to where the kinds are defined.

Actual: none.
infoWhat was checked: every stated total reconciles within the report; the slice files were not available to recompute from
Not a defect. The fifteen slice results the report counts from (item-tags-00 to item-tags-14) were not in this review's tree, only the report, so its counts could be checked for internal agreement and against the public PRs, not recounted from source.

Internally everything agrees: the fifteen slice sizes in line 9 sum to 1,464; the main-tag column sums to 1,464, the single-tag column to 859 and the carrying column to 2,069 = 859 + 2 x 605; every row has carrying >= main >= only; all 23 shares are the correct rounding of count / 1,464 and sum to 100.0; 307 + 298 = 605; 1,464 - 1,442 = 22 extra plugins is consistent with eight multi-plugin PRs of the sizes named (7, 6, 5, 3 and four more).

The ten hardest-to-place plugins are in the order the stated rule gives from the table's own tag uses (25,215; 18,685; 15,785; 15,355; 14,637; 14,245; 13,940; 13,013; 12,505; 11,562) and the three runners-up follow (11,275; 10,710; 10,620).

Against GitHub: PR 153370 does add seven plugins, PR 153040 five model-forge packages, PR 149142 three plugins including odoo-prod-guard, and all ten ranked PR numbers are the named plugin's catalog PR.
Recompute the sums from lines 9 and 19-42 of the report as listed above. To recount from source, run a count over the fifteen item-tags-NN files: number of entries, distinct pr values, first-tag frequency, single-tag frequency and any-position frequency per tag, and compare with the table.
Publishedresearch report
Onchain1 receipton Ethereum mainnet
receipt
receipt 1 · transaction · record
scores
written, with no entries recorded on it · block 26,396,096 · transaction

15 agents at most, judge accepted

Items

15 itemsClose →

allrunningwaiting accepted failed

Nothing matches this view yet.

Outputs

30 files accepted

items/30 files112 KB