Prompts Are a Shell, Not a Chat: Treating Abilities Like a 6th-Generation CLI

Chat asks. Shell commands. The difference is not politeness; it is grammar. A chat prompt is a bag of intent. A shell prompt is a structured invocation: a command, subcommands, positional arguments, flags, globs, and a runtime that can chain, branch, react, and converge. We have been building that shell inside CatGame for months without naming it. This post names it and argues that the next generation of programming language is not code in a file; it is a high-level command that an agent turns into a graph of skills, tools, and reactions.

From chat to command

Most users still talk to agents like they are talking to a person. "Can you look at these files and see if anything is wrong?" is a fine request if you want a conversation. It is a terrible request if you want a reproducible, auditable, chainable action. A shell command is better:

Can you look at these files and see if anything is wrong?

&roast --target code engine/physics --max-rounds 5

The second prompt is not rude. It is explicit. It names the ability (&roast), the target type (--target code), the path (engine/physics), and the convergence cap (--max-rounds 5). The agent does not need to guess what "look at" means or how hard to try. It has the same information a human reviewer would need in a code-review ticket, but it is packed into a single command line.

This is not a UI regression. It is a 6th-generation programming interface. We are using that term in-project to mean a language where the syntax is natural enough to write in one line, but the semantics are compiled into a branching graph of skills, workflows, and tool calls. It is not a replacement for Python or C++; it is the layer above them where intent becomes orchestration.

The grammar we already use

CatGame abilities and skills already follow a shell-like grammar. The only missing piece is a consistent mental model for writing prompts that way. Here are the four pieces:

Concrete examples from the repository today:

&work --target code engine/physics/broadphase.cpp --max-rounds 3
&roast --target frontier-post snes-wasm-60fps --max-rounds 5
&loop --max-iterations 10 --converge --work
&frontier-post write prompts-are-shell
&dream --trace /tmp/dreams_2026-08-20.zip
&ideas --about "runtime BRR verification"
/cic --fix placeholder-leak
/cic -i -j 0 -v .devin
/compact-instructions .devin/skills/frontier-post/SKILL.md
/compact-instructions --all
sn analyze spc --tool snes2asm data/sn/roms/snes/oem/Super\ Mario\ World.sfc
build.sh snes --rom hello_world --release
build.sh site --frontier

Some of these are & abilities, some are / skills, and some are native scripts. From the agent's point of view the grammar is the same: command, then subcommand, then arguments, then flags. The difference is only which instruction file the agent dispatches to.

What the parser is

In a normal shell, bash parses the command line and forks a process. In our system, the agent itself is the parser. It reads the prompt, maps it to the ability or skill described in .devin/abilities/ and .devin/skills/, and then executes the corresponding workflow. The instruction file is the man page, the prompt is the invocation, and the agent is the runtime.

The diagram is a simplification, but it captures the key idea: the prompt is the entry point, the ability is the graph, and the agent walks the edges based on return codes, convergence checks, and user reactions. This is reactive programming with a shell syntax.

What a 6GL prompt could look like

We are not there yet, but the user-facing target is clear. The user prompt in this very session—/compact-instructions * files in ./.agents/*.md -l -g—is a compact way to express a multi-step operation:

/compact-instructions * files in ./.agents/*.md -l -g

We can read this as a small program:

• /compact-instructions — invoke the compact-instructions skill
• * — select all matching targets in the current scope
• files in ./.agents/*.md — a glob-qualified selector
• -l — run lint pass
• -g — run guard pass

Today's /compact-instructions skill supports <file>, multi-file, and --all from .devin/skills/compact-instructions/SKILL.md. The -l and -g flags are present in the underlying scripts/lib/cic/cic.sh as --lint and --guard behavior, but not yet exposed through the compact-instructions prompt grammar as single-letter flags. The * and files in selectors are not implemented at all, and .agents/ is an illustrative path rather than a real directory. This is a roadmap example, not a shipped command.

The broader point is that the prompt is becoming a programming language statement: operator, quantifier, selector, and modifiers. The agent runtime is the interpreter. The instruction files are the standard library. The tools are the system calls.

Why this beats chat for engineering work

Chat is good for exploration. Shell is good for execution. Engineering work is mostly execution, and execution needs these properties:

The repository already treats prompts this way in practice. The &work ability is a session-level command. The &loop ability is a while-loop. The &roast ability is a bounded refinement loop. Each one is documented in .devin/abilities/ with an invocation block that looks like a man page. The only thing left is to stop pretending these are chat messages and start treating them as the commands they are.

The implementation surface today

This is not a future feature; it is already how the CatGame agent is invoked. The current state is a mix of implemented and partial:

The gap is mostly in the prompt parser, not the runtime. The runtime already understands abilities, skills, and shell scripts. A future pass on the CIC compiler could add a prompt-as-shell normalization step that turns a chatty prompt into a structured command line before the agent acts on it. That is one reason this concept lives next to the CIC compiler and the dictionary-minification work: both are about treating natural-language instruction as compiler input.

Caveats and limits

Shell prompts are not always better. Exploration, debugging, and design conversations need the looseness of chat. Forcing everything into a command line would make the agent worse at discovery. The goal is a shell-first, chat-fallback model: when the intent is clear, use a command; when the intent is unclear, use a conversation. The agent should be able to tell the difference and respond accordingly.

There is also a security concern. A shell grammar is powerful, and power needs boundaries. Every ability and skill is gated by .devin/rules/AGENTS.md, the crypt keeper, and the CIC security scanner. A prompt like &roast --target code does not bypass policy; it routes through the ability's rules, which route through the repository's policy. The command line is a user interface, not an override.

Related links and next steps

The shell model of prompts is a natural companion to the other agent-infrastructure posts. The CIC compiler treats instruction files as compiler input. The self-improving instructions post describes how abilities compress and improve themselves. The dictionary pass canonicalizes synonymous verbs so the parser sees the same command through different phrasing. The build loop is a concrete example of a long-running command with convergence and kill semantics.