/create-command

description: Create a new obsidian-second-brain command via interview - zero markdown editing required
category: meta
triggers_en: ["create command", "new command", "add a command", "scaffold a command"]
triggers_de: ["erstelle einen Befehl", "neuer Befehl", "Befehl hinzufügen", "Befehl-Gerüst erstellen"]
triggers_es: ["crea un comando", "nuevo comando", "añade un comando", "hazme un comando nuevo", "arma un comando"]
triggers_pt: ["crie um comando", "novo comando", "adicione um comando", "gere um comando"]
triggers_zh: ["创建一个新命令", "新增 Obsidian 命令", "帮我写个命令", "生成命令模板"]

Use the obsidian-second-brain skill. Execute `/create-command $ARGUMENTS`:

This command runs a short interview, then writes a new `commands/<name>.md` file that the build pipeline picks up automatically. The user never touches frontmatter, never edits a template, and never copies an existing command file.

**Hard rule:** You MUST use the AskUserQuestion tool for every question in this flow. ONE question per call. Wait for the answer before the next question. Do not batch.

The optional argument is a free-text seed describing what the command should do (e.g., `summarize my notion pages and save to vault`). If given, use it to pre-fill suggestions in the interview. If empty, the first question opens with "what problem do you want to solve?".

Fast path (skip the interview when the seed already answers it)

If the seed argument is detailed enough to fill every field yourself - the intent is clear AND you can confidently derive a name, category, trigger phrases, the step outline, and whether it writes to the vault - do NOT run the six-question interview. Instead:

1. Draft the complete spec (name, category, triggers, 3-5 steps, vault-write yes/no) from the seed. 2. Present it in ONE AskUserQuestion tool call as a single confirm-or-adjust gate: option A "Create it as specced" (show the name + one-line behaviour), option B "Let me adjust" (falls back to the full interview). Include the proposed name in the option label so the user sees it. 3. On "Create it as specced", validate the name (Phase 2 checks: regex `^[a-z][a-z0-9-]*$`, and `commands/<name>.md` does not already exist), then jump straight to Phase 8 (generate the file) and Phase 9 (confirm).

Only the truly under-specified seeds need the full interview. A seed like "summarize my notion pages and save to vault as AI-first notes, call it obsidian-notion, research category" is enough to fast-path. When in doubt, run the interview - one confirmation is fine, but never invent behaviour the seed did not state (see the anti-fabrication rule).

---

Phase 1 - Intent

Ask ONE question via the AskUserQuestion tool:

> "What problem do you want this new command to solve?" (free text)

Read the answer. Confirm understanding back in one sentence before proceeding.

---

Phase 2 - Naming

From the intent, propose 3 candidate kebab-case names. Names should be lowercase, hyphenated, and start with `obsidian-` (vault-management commands) OR a topic prefix (research toolkit uses `research-*`, social uses `x-*`/`brand-*`) OR just a verb (`create-*`, `import-*`).

Use the AskUserQuestion tool (single-select) with 3 options plus "Other" implicit:

> "Which name should I use?" > - `<candidate-1>` > - `<candidate-2>` > - `<candidate-3>`

After the user picks, validate: 1. Check that `commands/<name>.md` does NOT already exist (use Read; if it succeeds, the name is taken - go back and re-ask) 2. Confirm the name passes the regex `^[a-z][a-z0-9-]*$`

---

Phase 3 - Category

Ask via the AskUserQuestion tool (single-select, 4 options):

> "Which category does this command belong to?" > - `vault` - daily writing, capture, find (note creation, retrieval, kanban) > - `thinking` - synthesis, decisions, learning, reviews > - `research` - bring external sources into the vault > - `meta` - vault setup, health, structure, tooling

---

Phase 4 - Trigger phrases

Generate 3-5 natural-language trigger phrases the user might say to invoke this command (not slash-form). Examples from existing commands: `"save this"`, `"deep research"`, `"weekly review"`. Avoid duplicating triggers already used by other commands (read all `commands/*.md` frontmatter `triggers_en:` once and warn on collisions).

Ask via the AskUserQuestion tool (free text, default to your suggested set):

> "Trigger phrases the user might say to fire this command, comma-separated:" > Default: `<suggestion-1>, <suggestion-2>, <suggestion-3>`

---

Phase 5 - Behavior outline

Ask via the AskUserQuestion tool (free text):

> "Describe what the command does in 3-5 numbered steps. Plain English, no code."

Use the answer as the spine of the command body.

---

Phase 6 - Vault writes? (AI-first compliance gate)

Ask via the AskUserQuestion tool (single-select):

> "Does this command write notes to the user's Obsidian vault?" > - `yes` - output must apply the AI-first rule (frontmatter, preamble, wikilinks) > - `no` - read-only, informational, or external-write only

If `yes`: the generated command body MUST end with the AI-first rule footer (see Phase 8).

---

Phase 7 - External APIs?

Ask via the AskUserQuestion tool (multi-select):

> "Does this command call any external APIs?" > - Perplexity Sonar (web research) > - xAI Grok (X posts, x_search tool) > - YouTube Data API > - Other (free text) > - None - purely operates on the vault and conversation

If any are selected, the generated body should include a setup line referencing `~/.config/obsidian-second-brain/.env` and the relevant key (e.g., `PERPLEXITY_API_KEY`).

---

Phase 8 - Generate the file

Build the new command file. The exact format MUST be:

---
description: <one-line, sentence-case, ends without period>
category: <vault | thinking | research | meta>
triggers_en: ["<trigger 1>", "<trigger 2>", "<trigger 3>"]
triggers_es: ["<disparador 1>", "<disparador 2>"]
---

Use the obsidian-second-brain skill. Execute `/<name> $ARGUMENTS`:

<one-sentenc