Skip to content
Zide Zide

Commands

You can use the Commands activity to browse and manage commands used with Zide Assist. A command is a prompt plus metadata: a display name, a command name to run it, an optional description, and optional inputs. Use commands for frequently used tasks.

To show the Commands activity, click its activity-bar icon or click Assist > Commands.

Click a command to display the following information.

  • Display Name: The name of the command.
  • Command Name: The command to run it in Zide Assist. The command name is based on the display name.
  • Description: A brief description of what the command does.
  • Inputs: Parameters the command accepts.
  • Prompt: The instructions sent to Zide Assist when the command runs.

Commands are organized into the Built-in, Global, and Project sections.

Built-in

The Built-in section displays read-only commands that ship with Zide. Built-in commands cannot be edited or deleted.

Global

The Global section displays user-created commands. Global commands are available in every project.

Project

The Project section displays project-specific commands. Project commands are scoped to the current repository and can be used by other members of that repository.

Create commands

To create a new command, complete the following steps.

  1. In the Commands activity, click New Command.
  2. Click New Global Command to create a global command or New Project Command to create a project command. A blank command is created in either the Global section or Project section.
  3. Enter the name of the command in the Display Name field. The display name is also the command name used to run it in Zide Assist.
  4. Optional: Enter the description of the command in the Description field.
  5. Optional: To add an input to the command, click New Input. Input types are text, textarea, bool, and enum.
  6. Enter the instructions Zide Assist should follow in the Prompt field.
  7. Optional: Click Enable multi-step processing to make the command a multi-step prompt. For more information, see Multi-step prompts.
  8. Click Save.

You can also copy an existing command to create a new command. To copy a command, click the Make Copy icon and then click either Copy to Global or Copy to Project.

Click Save to save the changes you made to a command. Click Revert to remove all unsaved changes to a command.

Click the Delete icon to delete the command.

Add inputs to a command

Inputs let a command collect values when it runs. When you run a command that has inputs, Zide shows a dialog that collects each value before the prompt is sent. A command with no inputs skips the dialog and runs immediately.

Each input has a type:

  • text: A single-line value.
  • textarea: A multi-line value.
  • bool: A checkbox that resolves to true or false.
  • enum: A dropdown restricted to a fixed set of choices.

You can give a default value to text and bool inputs: a text input pre-fills with its default and shows a reset control to restore it, and a bool input starts checked when its default is true. An enum input selects its first option unless the file sets a default (see Command files on disk). Textarea inputs do not take a default. For an enum input, define the list of choices in the Options field.

To add an input, click New Input while editing a command, choose a type, and enter a name and label. The name is how you reference the input in the prompt (see Use input placeholders in the prompt); the label is what the run-time dialog shows.

Use input placeholders in the prompt

Reference an input in the prompt body with a {{name}} placeholder, where name matches the input’s name. When the command runs, Zide replaces each placeholder with the value collected from the input dialog.

For example, a command with a text input named issue can use it in the prompt:

Investigate issue {{issue}} and summarize the root cause.

While editing a command, the editor lists the command’s inputs as clickable pills above the prompt. Click a pill to insert its {{name}} placeholder at the cursor. A pill is styled as unused until the body references it, which helps you spot inputs you have defined but not yet used.

In a single-step command, any input that has a value but is not referenced by a {{name}} placeholder is included in the prompt as a Parameters block, so the value still reaches Zide Assist. If every input with a value is referenced by a placeholder, no Parameters block is added. A multi-step command instead substitutes only the placeholders in each step, so an input value that no step references is not sent.

Run a command

To run a command, type a forward slash, /, followed by the command name into the Zide Assist message box and then click Send.

You can also send a file to Zide Assist from the Files activity:

  • Right-click a file and click Send to Zide Assist > As Prompt to send its contents as a prompt.
  • Drag a file into a Zide Assist tab to use the file as an attachment.
  • Drag a file into the Zide Assist message box.

Pass inline arguments

For a single-step command, you can type extra text after the command name, such as /fix #42 src/auth.js. Zide sends the command’s prompt and includes the trailing text as an additional context block below it. Inline arguments are passed through as-is; they are not substituted into {{name}} placeholders. Use inputs and placeholders when you need values inserted at specific points in the prompt. A multi-step command ignores any trailing text.

Set the model for a command

You can pin the model a command runs on by starting its prompt with a /model line. Zide applies the directive, then sends the rest of the prompt as the message:

/model claude-opus-4-8
Review this diff and flag correctness bugs.

This is useful when a command should always run on a particular model, such as a cheap model for quick triage or a strong reasoning model for review, instead of inheriting whatever model the tab happens to have. It is also the reliable way to pin a model for automated testing.

Prefer the exact model id (for example, claude-opus-4-8) rather than a display name. The id is matched in full, so it resolves to a single model every time. To find a model’s id, type /model (with a trailing space) in the message box and read the id shown at the end of each row.

Set parameters inline

You can set model parameters in the same line by appending key=value pairs after the model, without opening the picker:

/model claude-opus-4-8 temperature=0.7 reasoning=high

Everything up to the first key=value token is the model; each token from there on is a parameter. Because model names and ids never contain =, no special separator is needed, and names with spaces still work. Parameters are validated against the model’s own schema: an unknown key, or a value that is out of range or not an allowed option, posts a message and does not switch. To change parameters on the current model without switching, give only the parameters (/model temperature=0.5). The overrides apply to the session, the same as tuning them in the picker.

As you type, once the model you have entered resolves to a single model, the autocomplete suggests that model’s parameters as key= tokens with their legal values, so you can pick a parameter without remembering its name or range.

See a model’s parameters

To look up what a model accepts before setting anything, send /model on its own. Zide prints a summary of the currently selected model: each parameter with its type, its legal values (the options for a choice, or the range for a number), the schema default, and the current value when you have overridden it.

To summarize a different model without switching to it, use /model info followed by a model, matched the same way a switch is:

/model info claude-opus-4-8

/model-info is a top-level alias for the same thing (/model-info on its own summarizes the current model; /model-info <model> summarizes that model). The summary is read-only: it never switches the model or changes any parameter.

You can also toggle plan mode from a preamble line with /plan on or /plan off.

The following rules apply to these leading directives.

  • Leading lines only. Directives must be the first line or lines of the prompt. The first line that is not a directive begins the message body, and nothing below it is read as a directive.
  • Modifiers only. Only /model and /plan are allowed. Action commands such as /new, /compact, and /export are never run from a preamble line.
  • Sticky. A model or plan-mode change from a preamble persists for the rest of the conversation, the same as running /model or /plan on their own.
  • Last one wins. If you list /model more than once, the last one is used.
  • Stops on an unknown model. If the model id cannot be found, or is not available on your plan, Zide posts a message and does not send the command, rather than silently running on the wrong model.
  • Stops on an invalid parameter. A /model line may append inline key=value parameters (see Set parameters inline). An unknown key, or a value out of range or not an allowed option, posts a message and stops the send, rather than running with the parameter dropped.

To send a message whose body must literally begin with /model or /plan, start the line with a second slash (//model ...), start it with a backslash (\/model ...), or put a blank line above it. This preamble is especially handy in a hand-authored command file.

Command files on disk

Global and project commands are stored as plain Markdown files with YAML frontmatter, so you can create or edit them by hand as well as through the Commands activity. Hand-editing is useful for authoring at scale or when a command begins with a directive such as a leading /model line.

  • Global commands live in the commands folder of your Zide application data directory:
    • Windows: %APPDATA%\zide\commands\
    • macOS: ~/Library/Application Support/zide/commands/
    • Linux: ~/.local/share/zide/commands/
  • Project commands live in .zide/shared/commands/ at the root of the repository. Because they are committed with the repository, project commands are shared with everyone who works in it.

The file name without the .md extension is the command name you type after the slash. Built-in commands are not stored on disk and cannot be edited.

Each file has YAML frontmatter followed by the prompt body:

---
name: Fix Issue
description: Investigate and fix a GitHub issue
inputs:
  - name: issue
    label: Issue number
    type: text
    default: "#42"
  - name: scope
    label: Scope
    type: enum
    options:
      - backend
      - frontend
---


Investigate issue {{issue}} in the {{scope}} code and propose a fix.

Frontmatter fields:

  • name: The display name.
  • description: A short description.
  • inputs: A list of inputs, each with a name, label, and type (text, textarea, bool, or enum), an optional default, and options for an enum input.
  • mode, auto-submit, delay: Multi-step settings. For more information, see Multi-step prompts.

After editing files by hand, reload the Commands activity to pick up your changes.

Scope and shadowing

The same command name can exist in more than one scope. When names collide, the most specific scope wins in this order: Project overrides Global, and Global overrides Built-in. Running the command uses the winning definition; the shadowed commands are marked in the Commands activity so you can see that a higher-priority command of the same name exists.

This lets a repository tailor a shared command, or a global command replace a built-in, without renaming it.