Why the Obsidian Copilot Command System Needs a Rethink

[WetHat]

As Obsidian Copilot continues to mature, the stakes for getting its command system right are getting higher too. For AI to really help with note‑taking and knowledge management, it’s not just about having strong models. The way people actually work, needs to feel straightforward, adaptable, and frictionless.

On step in that direction would be a command system that makes it easy to understand what’s possible, discover the right tools, and seamlessly integrate AI into note-taking and knowledge management workflows. Menu‑commands could be much more than basic text tools. They have the potential to provide, context-aware editing that goes beyond simple text manipulation.

The Issue with the Command System Today

Obsidian Copilot offers two main ways to interact with AI-driven commands: the /-command (slash command) and the menu-command. Unfortunately, these two approaches behave quite differently, often leading to confusion.

• /-command:
  This mode shines for quick, context-aware snippets. It has access to @-tools and the active note (via {} or {activeNote}). However, but only the prompt configured in command settings is used. The configured model and its parameters are ignored. You can to select a model in the chat window, but it always uses the global model parameters. Prompt context can be primed manually (using the @ button in chat) or via embedded directives. For complex prompts, the chat input box can become cluttered, making it unclear whether user input is required or if the prompt is ready to execute. As a result, /-commands are best suited for short, focused tasks, such as those found in "Suggested Prompts":

• menu-command:
  Menu-commands, in contrast, do not have access to @-tools but can still interact with the active note. They allow for some model and parameter configuration (though fewer options than in global model settings). In theory, prompt context can be primed via embedded directives, but this is unreliable in practice (example below). Today, menu-commands are good at simple, single-turn editing tasks and offer convenient actions like copy, insert, and replace.

Same Prompt Different Results

The 'Make Takeaways' Prompt:

## Role
Act as  a Senior Content Analyst for academics and professionals, responsible to systematically examine provided content—such as notes, articles, reports, transcripts, or research papers—and distill it into takeaways

## Setup
- Required Skill: [[ExtractTakeaways]]
- Reference Materials: [[Obsidian flavored Markdown]]

## Directives
1. Set takeawaysNeeded: {{number of takeaways needed to cover all dimensions of the provided content}}
2. Set extractedTakeaways: {} |> ExtractTakeaways(listLimit=takeawaysNeeded,takeawayLimit=2,leadInLimit=5)
3. Complete and return only this template without wrappers
   ~~~
   > [!takeaway]+
   > {{extractedTakeaways}}
   ~~~

Results:

/-Command	Menu-Command
Perfect. Context loaded, Skill invoked all directives followed; But chat window reveals the prompt (useless noise for this use case)	Context not loaded. Output only useful because GPT-5.1 inferred prompt's intent. UI is focused on the editing task at hand

A Use-Case That Needs Attention

Obsidian Copilot is missing a critical use-case: complex editing tasks. These are workflows that require context and sophistication.

What’s Needed?

Clear Separation of Command Types:

• /-commands work best when they stay simple. Quick actions inside the chat, without extra setup.
• Menu-Commands as Project Extensions: Menu-commands should evolve into powerful project tools. This means granting them the same configurability as projects, plus access to @-tools and active note. For example, see issue setting/project system prompt support to link note template #1553.

[logancyang]

Thanks for writing this up! @zeroliu thoughts?