Expose Custom Invokable Prompts as Slash Commands in Continue CLI

[babblebey]

I’d love the ability for custom prompts marked invokable: true in prompts to automatically show up as slash commands in continue-cli (and optionally in the VS Code UI). I’m coming from using spec-kit (https://github.com/github/spec-kit), which provides a disciplined workflow around generating and refining project specs (spec.md, plan.md, tasks.md), enforcing a project constitution, and running structured analysis loops. Spec-kit already supports multiple AI agents (Copilot Chat, Claude Code, etc.) by giving each environment a consistent set of “commands” like /spec, /plan, /tasks, /analyze, etc.

The whole value there is repeatability: you don’t copy/paste giant prompts, you trigger well-scoped operations with stable semantics. When trying to adopt that same ergonomics with Continue, I can create prompts with frontmatter and mark them invokable, but they aren’t accessible as /command entries in the CLI. That breaks the muscle memory and makes Continue feel like it treats my domain prompts as second-class compared to built-ins.

What I’d like: Since I already have my prompts modelled after the style spec-kit creates for its supported agents (I had an issue doing this as reported in #8078, but i worked around it); then I could just run /analyze in continue-cli. Arguments would get passed into a reserved placeholder like $ARGUMENTS or like the natural language that follow the prompts in the ID, and the command would appear alongside built-ins when I type / or run a help listing. That would let spec-kit users script things like: run /analyze --json before committing, or chain /spec → refine → /plan → /tasks in a consistent loop—all without manually opening prompt files.

Here's what I am doing as workaround

screen-capture.13.webm

Why this matters:

• It enables Continue to participate cleanly in ecosystems that are already command-oriented (spec-kit being one example, but others could emerge).
• It lowers friction for teams standardizing internal prompt libraries (shared conventions, less drift).
• It improves parity with agents that already expose slash-triggered workflows, making it easier for teams to switch or use Continue as a primary interface.

A minimal first phase would be: register all invokable: true prompts (support both .prompt and .md once the extension recognition issue is addressed), derive a safe command id (explicit id or slugified name), allow /id key=value argument passing, provide /help or /commands output that lists them, and warn on missing required args with a non-zero CLI exit code (useful for scripting). Anything beyond that—namespacing via group, optional JSON output flag, live reload on file change, argument type hints—could come incrementally.

There’s real leverage here: it makes custom operational prompting feel native instead of bolted on. Happy to clarify use cases, test a draft implementation, or iterate on a frontmatter schema if helpful. Let me know if this direction aligns and what constraints might shape an initial version.

[babblebey]

Now, I see this

• Add invokable rule support to cli #8077

[bdougie]

I found some existing items that might be related. Let me know if these are helpful:

#	Title	Status
#7101	Add a way to refer to some file with a prompt-based template	🟢 Open
#7568	Prompts as Markdown files do not work	🟢 Open