CLI: /<skill> unrecognized while $<skill> invocation works

Resolved 💬 2 comments Opened Feb 14, 2026 by darksheer Closed Feb 14, 2026

Summary

Custom skill invocation works via $<skill> (example: $prd), but matching slash command invocation (example: /prd) is unrecognized.

This creates confusion because users can see/install skills and in some docs/repos also see slash wrappers, but /skill fails in the CLI parser.

Environment

  • Codex CLI: 0.101.0
  • OS: macOS (Apple Silicon)
  • Repo has projected prompt wrappers and skills (template-style setup)

Reproduction

  1. Ensure a skill exists and is enabled (example prd).
  2. Invoke skill with $prd <text>: works.
  3. Invoke with /prd <text>: CLI returns:
  • Unrecognized command '/prd'. Type "/" for a list of supported commands.

Current behavior

  • $skill path works.
  • /skill path is rejected, even when prompts/wrappers and skill files are present.

Expected behavior

One of the following should happen consistently:

  • /<skill> should execute when a corresponding skill/prompt wrapper exists, OR
  • CLI should clearly state that custom slash commands are unsupported in this build and point users to $<skill>.

Why this matters

Users interpret installed skills and prompt wrappers as slash-invokable. The mismatch causes repeated setup/debug loops and uncertainty about whether installation failed.

Suggested fix

  • If custom slash commands are supported: wire parser/discovery to loaded skill/prompt metadata.
  • If not supported: add explicit UX guidance in /skills and slash help output:
  • Use $<skill> to invoke installed skills.
  • Distinguish built-in slash commands from custom skill invocations.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗