Settings → Instructions. One page, three sections stacked top to bottom: the global instruction, the project's instructions, and slash commands.

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 page, 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; an unsaved marker appears beside the button while 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. With no project open the list reads Open a project to add project-scoped instructions and Add instruction is greyed out.

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, a two-way toggle beside the name:

• 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, and each row in the list wears an auto or manual badge.

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

Instruction (markdown) is the body, 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 greyed out. Each row in the list wears a ws or usr badge.

<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.

Two entries are built in rather than yours. /handoff is always there: picking it doesn't attach anything — it writes the note the next session starts from, and needs memory switched on. While Claude Code is the active model, /claude appears too, and opens the Claude settings panel.

→ Handing a session off

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.