One tab, two separate features, chosen with the toggle at the top.

Instructions are standing guidance. You write them once and they travel with your messages, without you doing anything.

Commands are prompt templates you pull in deliberately by typing /.

The difference is who decides. An instruction is something you always want true — never use unwrap() outside tests. A command is something you want on demand — review this diff and list the problems.

Both are plain markdown files under ~/.semantix/, never inside your source tree, so nothing here ends up in your repository.

Instructions

The global instruction#

One always-on box at the top of the tab, applying in every project on this machine — including when no project is open. It's the right home for how you like to be worked with: your tone, your review standards, the things you never want done.

Write into the box and press Save. There's no autosave; the button lights up when there's something to save.

Stored at ~/.semantix/USER/instructions.md — the file is the instruction, no wrapper, so you can edit it in any editor.

Project instructions#

Below it, a list scoped to the open project — the conventions of this codebase rather than of your work generally.

Add instruction asks for four things:

Name becomes the filename: letters, digits, dot, dash, underscore, up to 64 characters, and it can't start with a dot. It can't be changed later either — to rename, delete and recreate.

Type is the choice that matters:

• Auto — included in every message you send, automatically, forever.
• Manual — sits idle until you attach it from the / menu, exactly like a command.

New instructions default to Manual, so a new one does nothing until you say otherwise. Both are editable afterwards.

Description is a one-line summary for the list and the / menu.

Instruction is the body, in markdown, with a Write/Preview pair and a fullscreen editor. It's required — Create stays greyed out until there's something in it. (Commands are laxer: an empty command saves fine, and then contributes nothing.)

A worked example — name rust-style, type Auto:

## Rust style
- No `unwrap()` outside tests — return `Result` and use `?`.
- Every public fn gets a doc comment with one usage line.
- Prefer `tracing::info!` over `println!`.

That file lands in ~/.semantix/WORKSPACE/<project-id>/instructions/rust-style.md, with the description and type in frontmatter.

What "auto" actually does#

Every time you send a message, Semantix collects your global instruction and every auto instruction in the project, and hands them to the model as standing guidance alongside what you typed.

Three consequences worth knowing:

It happens on every message, not just the first of a conversation. There's nothing to refresh.

An edit takes effect on your very next message, in conversations already in progress.

You never see it. No chip, no bubble, nothing in the transcript. The only evidence an instruction is working is the model's behaviour, which makes a quiet failure hard to notice — see the note below.

Auto instructions you edit by hand are picked up the same way, on your next message.

Slash commands

Reusable prompt templates. Add command takes a name, a scope, a one-line description and a body.

Scope decides where it's available:

• Workspace — this project only. ~/.semantix/WORKSPACE/<project-id>/commands/
• User — every project on this machine. ~/.semantix/USER/commands/

With no project open you can still add a command, but only a User one — the Workspace option is disabled.

<project-id> is your project's full path with the separators flattened to dashes — /home/moti/projects/myapp becomes home-moti-projects-myapp.

An example — review-pr, workspace scope:

Review the working-tree diff. For each finding give:
1. file:line
2. what's wrong
3. the minimal fix

Ignore style nits. Flag anything that can panic or lose data.

Using one#

Type / as the first character of an empty composer. The menu opens immediately.

• Keep typing to filter — it matches anywhere in the name, so pr finds review-pr.
• ↑ ↓ move, Enter or Tab picks, Escape closes. Clicking works too.
• Each row shows a badge: WS for workspace, USR for user, and a purple INSTR for a manual instruction — those appear in the same menu.

One entry is built in rather than yours: while Claude Code is the active model, /claude appears (badged WS, like a workspace command). Picking it opens the Claude settings panel instead of attaching anything.

Picking one turns it into a chip above the input and clears what you typed, on the assumption that /review-pr was the whole thing you'd written. Then type your actual message and send. You can attach several at once, and × on a chip detaches it.

What gets sent#

The command's body is placed in front of your message:

<command body>

<what you typed>

Several commands stack in the order you attached them, your text last. The transcript shows the chip and your typed text, not the expanded body — but the model receives the full version, and later turns in the conversation still see it.

Because commands work on your message rather than as standing guidance, they behave identically on every model.

There are no arguments#

The body is inserted literally. There's no $ARGUMENTS, no $1, no {{placeholder}} — no substitution of any kind.

That's less limiting than it sounds, because your typed message lands directly after the body. Write the body to read as an instruction and let your message be the target:

/review-pr → then type: focus on the auth module

Editing them by hand#

Every command is a markdown file whose filename is the command name, with an optional description: in frontmatter and the body after it. Drop a .md file into either commands folder and it's a command.