fix(discord): complete #18741 for /skill autocomplete and drop legacy 25x25 caps by teknium1 · Pull Request #18745 · NousResearch/hermes-agent

teknium1 · 2026-05-02T08:48:50Z

Summary

discord_skill_commands_by_category — the collector the live /skill Discord autocomplete calls — was lagging its sibling discord_skill_commands on two counts, both silently dropping skills users expected to see.

1. External-dir skills were filtered out

#18741 widened the flat discord_skill_commands collector to accept SKILLS_DIR + skills.external_dirs. It left the by_category variant still matching SKILLS_DIR only. That variant is the one _register_skill_group (gateway/platforms/discord.py) calls for Discord's /skill command, so external-dir skills stayed invisible in the Discord autocomplete despite showing up everywhere else (hermes skills list, the agent's /skill-name dispatch).

Fix: widen the accepted roots to match, and derive categories from whichever root the skill lives under so <ext>/mlops/foo/SKILL.md still lands in the mlops group.

2. Legacy 25×25 caps from the old nested layout were still being applied

PR #11580 refactored /skill to a flat autocomplete layout (Discord fetches options dynamically — no per-command payload concern). Its docstring promises "no hidden skills." But the by_category collector kept the old _MAX_GROUPS=25 × _MAX_PER_GROUP=25 caps from the nested /skill <cat> <name> layout, silently dropping anything past the 25th alphabetical category.

Real user impact: installs with 29+ category dirs (the tail — social-media, software-development, yuanbao, etc.) were losing entire categories from autocomplete, logged only as "N skill(s) filtered out of /skill (name clamp / reserved)".

Fix: remove the caps. hidden is retained in the return shape for backward compatibility and now reports only genuine 32-char name-clamp collisions against reserved names.

Test Plan

test_no_legacy_25x25_cap: build 30 categories × 30 skills each, assert all 900 are returned
test_external_dirs_skills_included: monkeypatch get_external_skills_dirs, assert external-dir skill appears grouped under its own top-level directory
Existing TestDiscordSkillCommandsByCategory tests (4) still pass
Full tests/gateway/test_discord_slash_commands.py + tests/hermes_cli/test_commands.py green (166 passed)

… 25x25 caps ``discord_skill_commands_by_category`` was lagging the flat ``discord_skill_commands`` collector on two counts. Both were actively dropping skills from Discord's ``/skill`` autocomplete dropdown. 1. External-dir skills were filtered out. #18741 widened the flat collector to accept ``SKILLS_DIR + skills.external_dirs`` but left this sibling collector — the one ``_register_skill_group`` actually uses on Discord — still matching ``SKILLS_DIR`` only. External skills were visible in ``hermes skills list`` and the agent's ``/skill-name`` dispatch but silently absent from Discord's ``/skill`` picker. Widen the accepted roots to match, and derive categories from whichever root the skill lives under so ``<ext>/mlops/foo/SKILL.md`` still lands in the ``mlops`` group. 2. 25-group × 25-subcommand caps were still applied. PR #11580 refactored ``/skill`` to a flat autocomplete (whose options Discord fetches dynamically — no per-command payload concern) and its docstring promises "no hidden skills." The collector kept the old nested-layout caps anyway, silently dropping anything past the 25th alphabetical category. On installs with 29 category dirs today (real example: tail categories ``social-media``, ``software-development``, ``yuanbao`` going missing) this was biting immediately. Remove the caps; ``hidden`` now reports only 32-char name-clamp collisions against reserved names. Tests: guard both behaviors. ``test_no_legacy_25x25_cap`` builds 30 categories × 30 skills each and asserts all 900 are returned. ``test_external_dirs_skills_included`` monkeypatches ``get_external_skills_dirs`` and asserts an external-dir skill makes it into the result grouped under its own top-level directory.

alt-glitch · 2026-05-02T08:59:36Z

Related to #11804 — both address the legacy 25x25 cap on /skill autocomplete. This PR also fixes external-dir skill visibility.

alt-glitch · 2026-05-02T09:00:40Z

Related to #11804.

#18759) Discord's per-command name limit is 32 chars. When two skill slugs share the same first 32 chars (or a skill slug clamps onto a reserved gateway command name), only the first seen wins — the second is dropped from the /skill autocomplete. The old behavior incremented a ``hidden`` counter silently, so skill authors had no way to discover the drop short of noticing their skill was missing from the picker. Not an actively-biting bug today (no collisions on the default catalog as of 2026-05), but a landmine the moment someone ships a skill with a long name. The earlier series in #18745 / #18753 / #18754 dropped the other silent data-loss paths in the Discord /skill collector; this one lights up the last remaining one. Fix: promote ``_names_used`` from a set to a dict keyed by the clamped name, mapping to the source cmd_key (or a ``"<reserved>"`` sentinel for names inherited via ``reserved_names``). On collision, log a WARNING naming both sides — the winner, the loser, the clamped name, and what to rename. Two phrasings: * skill-vs-skill — "both clamp to X on Discord's 32-char command-name limit; only the winner appears in /skill. Rename one skill's frontmatter ``name:`` to differ in its first 32 chars." * skill-vs-reserved — "collides with a reserved gateway command name; the skill will not appear in /skill. Rename the skill's frontmatter ``name:``." Tests: three cases in ``tests/hermes_cli/test_discord_skill_clamp_warning.py`` — skill-vs-skill collision (warning names both cmd_keys + clamped prefix), skill-vs-reserved collision (warning uses the distinct phrasing), and a no-collision negative (zero warnings emitted).

… drop legacy 25x25 caps (NousResearch#18745) ``discord_skill_commands_by_category`` was lagging the flat ``discord_skill_commands`` collector on two counts. Both were actively dropping skills from Discord's ``/skill`` autocomplete dropdown. 1. External-dir skills were filtered out. NousResearch#18741 widened the flat collector to accept ``SKILLS_DIR + skills.external_dirs`` but left this sibling collector — the one ``_register_skill_group`` actually uses on Discord — still matching ``SKILLS_DIR`` only. External skills were visible in ``hermes skills list`` and the agent's ``/skill-name`` dispatch but silently absent from Discord's ``/skill`` picker. Widen the accepted roots to match, and derive categories from whichever root the skill lives under so ``<ext>/mlops/foo/SKILL.md`` still lands in the ``mlops`` group. 2. 25-group × 25-subcommand caps were still applied. PR NousResearch#11580 refactored ``/skill`` to a flat autocomplete (whose options Discord fetches dynamically — no per-command payload concern) and its docstring promises "no hidden skills." The collector kept the old nested-layout caps anyway, silently dropping anything past the 25th alphabetical category. On installs with 29 category dirs today (real example: tail categories ``social-media``, ``software-development``, ``yuanbao`` going missing) this was biting immediately. Remove the caps; ``hidden`` now reports only 32-char name-clamp collisions against reserved names. Tests: guard both behaviors. ``test_no_legacy_25x25_cap`` builds 30 categories × 30 skills each and asserts all 900 are returned. ``test_external_dirs_skills_included`` monkeypatches ``get_external_skills_dirs`` and asserts an external-dir skill makes it into the result grouped under its own top-level directory.

NousResearch#18759) Discord's per-command name limit is 32 chars. When two skill slugs share the same first 32 chars (or a skill slug clamps onto a reserved gateway command name), only the first seen wins — the second is dropped from the /skill autocomplete. The old behavior incremented a ``hidden`` counter silently, so skill authors had no way to discover the drop short of noticing their skill was missing from the picker. Not an actively-biting bug today (no collisions on the default catalog as of 2026-05), but a landmine the moment someone ships a skill with a long name. The earlier series in NousResearch#18745 / NousResearch#18753 / NousResearch#18754 dropped the other silent data-loss paths in the Discord /skill collector; this one lights up the last remaining one. Fix: promote ``_names_used`` from a set to a dict keyed by the clamped name, mapping to the source cmd_key (or a ``"<reserved>"`` sentinel for names inherited via ``reserved_names``). On collision, log a WARNING naming both sides — the winner, the loser, the clamped name, and what to rename. Two phrasings: * skill-vs-skill — "both clamp to X on Discord's 32-char command-name limit; only the winner appears in /skill. Rename one skill's frontmatter ``name:`` to differ in its first 32 chars." * skill-vs-reserved — "collides with a reserved gateway command name; the skill will not appear in /skill. Rename the skill's frontmatter ``name:``." Tests: three cases in ``tests/hermes_cli/test_discord_skill_clamp_warning.py`` — skill-vs-skill collision (warning names both cmd_keys + clamped prefix), skill-vs-reserved collision (warning uses the distinct phrasing), and a no-collision negative (zero warnings emitted).