Most people use Elyra by typing natural language. "Fix the auth module." "Add tests for the user service." That works, and it's the right default. But there are four single-character prefixes that unlock a different way of working — one where you control exactly what the agent sees and what it doesn't.

! — run a command, show the agent

!npm test

This runs npm test in your shell and sends the output to the agent as context. The agent sees everything — pass, fail, error traces, warnings.

Why this matters: instead of telling the agent "run the tests and fix what's broken," you run the tests yourself and the agent sees the real output. No interpretation layer. No "I'll run the tests for you" followed by a tool call. You already have the result.

!npm test -- --run test/auth.test.ts
3 tests failed. Fix them.

Two lines. The agent has the exact failure output and your instruction. No ambiguity about which tests, no wasted turn running them again.

This is especially useful for commands you run constantly:

!php artisan route:list --path=api
Add a PATCH route for updating user profiles, following the same pattern.

!cat .env | grep DB_
The database credentials are wrong. Update them for the staging environment.

!curl -s localhost:3000/api/health | jq .
The health endpoint is returning a 500. Fix it.

The output becomes part of the conversation. The agent can reference it, reason about it, and act on it.

!! — run a command, keep it private

!!git log --oneline -10

Same as !, but the output stays between you and your terminal. The agent never sees it.

This is for when you need to check something without polluting the context window. Every token in the agent's context costs money and affects quality. If you're just checking whether a branch exists or glancing at a log, the agent doesn't need to carry that information for the rest of the session.

!!git status
!!cat package.json | jq .version
!!ls src/components/

You see the output. You make a decision. Then you tell the agent what to do based on what you saw — in your own words, with only the relevant parts.

The difference between ! and !! is the difference between "here's a dump of 200 lines of test output, figure it out" and "three auth tests are failing because the session token format changed." The second is cheaper and often more effective.

/ — talk to Elyra, not the agent

/model
/tree
/goal npm run check
/rewind
/update

Slash commands control Elyra itself. They don't send anything to the LLM. They're free — zero tokens, zero latency.

The ones you'll use most:

Command What it does /goal npm run check Agent keeps working until the command passes /tree Navigate the session tree, switch branches /rewind Roll back conversation and files to a previous point /model Switch models mid-session /compact Compress conversation to free context space /update Update Elyra and restart without leaving

Extensions add their own. /workflow deploy runs a pipeline. /ext browses installable extensions. Type / and let autocomplete show you what's available.

@ — point at a file

@src/auth/service.ts What does the login method do?

The @ prefix fuzzy-matches a file in your project and includes its content in your message. Tab completes the path.

This is faster than asking the agent to read the file. The agent would call the read tool, wait for the result, then process it. With @, the content is already in the message — one round trip instead of two.

You can reference multiple files:

@src/auth/types.ts @src/auth/service.ts
Refactor the service to use the new AuthResult type from types.ts

Both files arrive in the same message. The agent sees them together and can reason about the relationship without separate read calls.

It works for images too:

@screenshot.png What's wrong with this layout?

Putting them together

Here's a real workflow that uses all four:

!!git diff --stat                          # Check what's changed (private)
!npm run check                             # Run type checker (agent sees errors)
Fix all the type errors                    # Agent works on the errors
/goal npm run check                        # Keep going until it passes

Four lines. The first checks the state without adding noise. The second gives the agent the exact errors. The third is the instruction. The fourth automates the loop.

Or a different pattern — investigating before acting:

!!php artisan route:list | grep user       # Check existing routes (private)
@app/Models/User.php                       # Include the model
Add a phone verification endpoint following the project's route conventions

You looked at the routes privately, decided what was needed, then gave the agent the model and a clear instruction. The agent didn't waste tokens reading route files — you already knew the pattern.

The mental model

Think of it as four channels:

The agent's context window is finite and expensive. These prefixes give you precise control over what goes in and what stays out. Use ! when the agent needs to see something. Use !! when it doesn't. Use @ when you already know which file matters. Use / when you're steering the tool, not the model.