Skip to content
Nx IDEDocs

Customization4 min read

Slash Commands

Reusable prompts in .nexgile/commands, with arguments

Slash commands bottle a prompt you’d otherwise retype — the pre-PR checklist, the “add an endpoint” recipe, the migration ritual — into a Markdown file you run by typing /name in chat. Project commands live in the repo, so the whole team runs the same workflow the same way; global commands follow you across projects.

The built-in command: /init

Section titled “The built-in command: /init”

Nexgile Code ships exactly one built-in command. /init analyzes your codebase and writes a concise, non-obvious-only AGENTS.md at the project root (about 20 lines: build/test commands, real conventions, gotchas), plus mode-specific starters under .nexgile/rules-code/, .nexgile/rules-debug/, .nexgile/rules-ask/, and .nexgile/rules-architect/. It merges in existing assistant rules (CLAUDE.md, .cursorrules, Copilot instructions) and, when re-run, prunes anything obvious so the files get shorter, not longer. Run it on day one of every project. Details in Rules Files & AGENTS.md.

Creating project commands

Section titled “Creating project commands”

Drop a Markdown file into .nexgile/commands/ in your project. The filename is the command name: review-pr.md becomes /review-pr. Optional YAML frontmatter adds metadata; the body is the prompt. Three practical examples:

.nexgile/commands/review-pr.md:

---
description: Review the current branch's diff like a strict senior engineer
mode: reviewer
argument-hint: optional focus area, e.g. "error handling"
---


Review the working-state diff against main.


1. Summarize what changed and why, in two sentences.
2. Flag logic errors, missing edge cases, and unhandled failures.
3. Check every new public function has a test; list the ones that don't.
4. Verdict: approve / request changes, with severity per finding.


Focus especially on: {{args}}

.nexgile/commands/add-endpoint.md:

---
description: Scaffold a REST endpoint following this project's conventions
mode: code
argument-hint: METHOD /path — e.g. "POST /api/orders"
---


Add the endpoint {{args}} to the API:


- Route in src/api/routes/, handler in src/api/handlers/, zod schema
  in src/api/schemas/ — follow the structure of src/api/handlers/users.ts.
- Wire it into src/api/index.ts.
- Add a happy-path and a validation-failure test in the handler's
  *.test.ts next to it.
- Run the test file and show me the result before completing.

.nexgile/commands/write-migration.md:

---
description: Create a reversible database migration
mode: db-migrator
argument-hint: what the migration should change
---


Create a migration for: {{args}}


- Use `pnpm migrate:create` to generate the file; never hand-name it.
- Both up() and down() are mandatory — down() must fully reverse up().
- No data-destructive statements without an explicit backfill note.
- After writing, run `pnpm migrate:up && pnpm migrate:down && pnpm
  migrate:up` against the local database to prove reversibility.

Save the file — the command is available immediately.

Frontmatter reference

Section titled “Frontmatter reference”
Field Purpose
description Shown in the command picker and passed to the agent with the command.
mode Mode slug to switch to when the command runs (e.g. reviewer, or one of your custom modes).
argument-hint Hint text telling users what to type after the command name.

Frontmatter is optional — a plain Markdown file is a valid command. If the frontmatter fails to parse, the whole file is treated as the prompt body.

Arguments and {{args}}

Section titled “Arguments and {{args}}”

Anything you type after the command name travels with the request: /review-pr error handling in the retry logic. Put {{args}} in the body where that input belongs, so the agent applies your arguments exactly where you intend — a focus area, an endpoint spec, a migration description. Commands without {{args}} still receive what you typed; the placeholder just anchors it.

Global commands

Section titled “Global commands”

Put the same files in ~/.nexgile/commands/ to make them available in every project. Good candidates: /standup (summarize recent work), personal formatting preferences, cross-project checklists. Symlinks are supported in both locations — you can keep one canonical file and link it into several places.

Precedence

Section titled “Precedence”

When names collide: project > global > built-in. A review-pr.md in the project’s .nexgile/commands/ shadows one in ~/.nexgile/commands/; a project or global init.md would even shadow the built-in /init. This lets a repo standardize a workflow over each developer’s personal variant.

Invoking commands from chat

Section titled “Invoking commands from chat”

Type / in the chat input to open the picker listing every available command (and mode) with its description; keep typing to filter, then select. A command reference works at the start of the message or after a space — /add-endpoint POST /api/orders — and its content is attached to the request rather than pasted into your input. If the command declares a mode, the task switches to that mode as it runs.

Managing commands in Settings

Section titled “Managing commands in Settings”

Open Settings → Slash Commands to see every command grouped by source (built-in, global, project). From there you can:

  • Create — the New Command dialog asks for a name (lowercase letters, numbers, hyphens, underscores; up to 64 characters) and a location (Project or Global), then creates the .md file and opens it for editing.
  • Edit — opens the command’s file in the editor.
  • Delete — removes the file after a confirmation. Built-in commands can’t be edited or deleted.

Letting the agent run commands

Section titled “Letting the agent run commands”

There’s also an agent-invoked path: the run_slash_command tool lets Nexgile Code execute a slash command mid-task — for example, running your /review-pr checklist after finishing an implementation. It’s gated behind the Run Slash Command experiment (Settings → Experimental, off by default), and each use shows an approval prompt naming the command, its source, and any arguments before the content is injected. See Settings & Feature Flags.

Section titled “Related”