Feature request: clarify or support Telegram slash aliases for user-defined skills

Summary

I am using Hermes with Telegram and repo-maintained skills synced into the local Hermes skills directory. Natural-language skill invocation works, but Telegram slash commands for those skills do not appear to be registered automatically. I would like to clarify whether this is intended behavior and, if not currently supported, request documentation or a feature for custom Telegram command aliases that map to user-defined skills.

Environment/context

• Hermes is being used as a local operator/gateway for a repo-driven agent workflow.
• Skill docs are synced locally into ~/.hermes/skills.
• The workflow uses skills named starttask, checktask, shiptask, status, and reviewpr.
• These skills map to local Foundry CLI commands such as:

python3 -m foundry task start TASK-009 --role backend --slug command-test --pull
python3 -m foundry task finish TASK-009 --dry-run
python3 -m foundry task finish TASK-009 --commit --push --draft-pr --message "TASK-009: short description"

Observed behavior

• /status returned Hermes Gateway status.
• /starttask returned unknown command.
• Natural-language invocation worked. This message:

Using starttask, for TASK-009 with role backend and slug command-test...

returned the correct Foundry command:

python3 -m foundry task start TASK-009 --role backend --slug command-test --pull

Expected/desired behavior

It would be useful to know whether user-defined skills are intended to be invokable as Telegram slash commands.

If yes, could the project document the registration, sync, or reload process needed to expose skills as Telegram commands?

If no, would the project consider supporting custom Telegram command aliases that map to skills?

Example desired aliases:

/starttask TASK-009 backend command-test
/checktask TASK-009
/shiptask TASK-009 "TASK-009: short description"
/reviewpr 7

Reproduction steps

1. Create or sync local Hermes skill docs into ~/.hermes/skills, including a starttask skill.
2. Use Telegram to send /status.
3. Observe that Hermes Gateway status is returned.
4. Use Telegram to send /starttask.
5. Observe that Hermes reports an unknown command.
6. Use Telegram to send a natural-language invocation such as:

Use the starttask skill for TASK-009 with role backend and slug command-test.

1. Observe that Hermes can use the synced skill guidance and return the expected local command.

Current workaround

Use natural-language skill invocation instead of Telegram slash commands:

Use the starttask skill for TASK-009 with role backend and slug command-test.
Use the checktask skill for TASK-009.
Use the shiptask skill for TASK-009 with message "TASK-009: short description".
Use the reviewpr skill for PR 7.

This works, but it is less phone-friendly than short command aliases and can be easier to mistype during operator workflows.

Why this would be useful

Phone and Telegram workflows benefit from short, predictable command forms. A user-defined alias layer would make it easier to operate repeatable local workflows without relying on exact natural-language phrasing.

For safety-sensitive workflows, aliases could also make intent clearer:

• /checktask means dry-run validation only.
• /shiptask means an explicit higher-power commit/push/draft-PR flow.
• /reviewpr means read-only PR review.

Proposed feature/documentation request

Please clarify one of the following:

1. User-defined skills are intended to be available as Telegram slash commands, and the docs should explain how to register, sync, reload, or expose them.
2. User-defined skills are not intended to be available as Telegram slash commands, and the docs should say natural-language invocation is the supported path.
3. Custom Telegram command aliases could be added as a feature, mapping Gateway slash commands to named skills with argument parsing.

If custom aliases are considered, a small config shape might allow users to define an alias, target skill, expected arguments, and safety level without changing Hermes runtime code.

Safety considerations

• Custom aliases should still respect Hermes permissions and any existing tool approval model.
• Commands should never auto-merge code.
• High-power commands such as shiptask should require explicit user approval and a commit message.
• Read-only commands such as checktask, project status, and PR review should remain read-only.
• Alias registration should avoid colliding silently with built-in Gateway commands such as /status.
• If an alias conflicts with a built-in command, Hermes should report the conflict clearly rather than overriding behavior unexpectedly.