Scenario: A skill folder with modeSlugs: [_none_] works as expected (excluded from mandatory_skill_check), but invoking it via slash command /skillname silently fails — resolveSkillContentForMode passes currentMode, and SkillsManager.getSkillContent filters it out because the skill doesn't belong to the current mode.
Root cause: getSkillContent at L192–196 only looks up skills scoped to currentMode, with no global fallback. When the user explicitly invokes /skillname, mode filtering is unnecessary — the intent is clear ("find this skill by name").
Proposed fix (2 lines): Add a global fallback when mode-specific lookup returns nothing — mode lookup still takes priority, fallback only activates when mode-specific fails. No breaking change. This pattern effectively treats skills as slash commands, laying groundwork for a unified command/skill system.
cc @hannesrudolph — you wrote the original skill/slash merge (PR #11834), this is a small edge case in the mode filtering.
Scenario: A skill folder with
modeSlugs: [_none_]works as expected (excluded frommandatory_skill_check), but invoking it via slash command/skillnamesilently fails —resolveSkillContentForModepassescurrentMode, andSkillsManager.getSkillContentfilters it out because the skill doesn't belong to the current mode.Root cause:
getSkillContentat L192–196 only looks up skills scoped tocurrentMode, with no global fallback. When the user explicitly invokes/skillname, mode filtering is unnecessary — the intent is clear ("find this skill by name").Proposed fix (2 lines): Add a global fallback when mode-specific lookup returns nothing — mode lookup still takes priority, fallback only activates when mode-specific fails. No breaking change. This pattern effectively treats skills as slash commands, laying groundwork for a unified command/skill system.
cc @hannesrudolph — you wrote the original skill/slash merge (PR #11834), this is a small edge case in the mode filtering.