Built-in slash commands (e.g. /goal) should be case-insensitive, or the "Unknown command" error should suggest a close match
/goal (and likely other built-in commands) match on an exact, case-sensitive string. Typing /GOAL or /Goal returns a generic Unknown command: /GOAL with no indication that a differently-cased version exists and works.
This is easy to hit in normal use (typing a command name in caps for emphasis, or via voice dictation that capitalizes it) and hard to self-diagnose: since built-in commands aren't file-based, there's nothing on disk to find while troubleshooting, and the failure looks identical to "this command doesn't exist at all."
It also can't be worked around locally. I checked the hook lifecycle looking for something that fires before slash-command dispatch and could normalize case: UserPromptExpansion fires only after a command is already matched (and can only block it, not rewrite it), and UserPromptSubmit fires after dispatch has already happened. Nothing intercepts the raw input before the CLI decides whether it matches a registered command, so there's no hook-based or settings-based fix available to users today.
Requesting either:
- Case-insensitive matching for built-in commands, or at minimum
- A "did you mean
/goal?" suggestion in the unknown-command error when a near-miss on case is detected
Either would remove a confusing, silent failure mode that currently has no user-side workaround.