Commands
The planned hyper command line, its command families and the trusted !hyper composer prefix, and why no command is executable reference yet.
On this page
Hypervibe plans one command line, hyper, and one prefix, !hyper, that reaches the same commands from a Rocket! or Lanes composer. This page shows how commands will be formed, which component presents each family, what the composer will run, and why nothing here is executable reference yet.
One program, hyper, will carry every command #
Every form below enters the same command system and reaches the same actions.
| Form | What it will do |
|---|---|
hyper | Opens your authorized workspace when run interactively; when its input or output is redirected, it prints usage or the result you asked for instead of starting a full-screen view |
hyper <domain> <verb> <target> | Runs one exact operation on a target you name; scope comes from explicit options and the selected context, never from a guessed lane name |
hyper run <workflow> <inputs> | Starts a named, versioned workflow; this form is reserved for starting workflows |
hyper exec <prompt> | Runs Rocket! without a full-screen view, with explicit inputs and output; it is not arbitrary shell execution |
hyper ext <namespace> <action> | Runs a command contributed by an extension package, which can never replace a built-in name |
!hyper followed by a command | The same commands, typed in a trusted Rocket! or Lanes composer |
hv, hypervibe | Compatibility names that enter the same command system as hyper |
The planned workflows are named for the work they do: code, research, delegate, diagnose, review, verify, compare, background, explore and prepare. In a composer, /code and the registered shortcut /hypercode reach the same Code workflow.
Help and version are designed to work without signing in, starting services or loading extensions.
Each command family names the component that presents it #
A family is a group of commands about one subject. Each is listed under the component that presents it, the product it is shown under. Presenting a command is not authority: the owner of each effect admits it and checks the grant again where the effect happens. The table shows the main families. The planned catalog has more, and a few commands in a family are presented by another component.
| Family | What it covers | Presented by | Standing |
|---|---|---|---|
hyper session, hyper turn, hyper model, hyper plan | Agent sessions and turns, model and effort choices, and plans | Rocket! | Planned |
hyper run | Starting a workflow such as code, research or verify | Rocket!, Lanes and Hypervibe | Planned |
hyper lane, hyper terminal, hyper layout | Lanes, terminal attachment and saved layouts | Lanes | Planned |
hyper workspace, hyper work | Workspaces, and starting, inspecting, cancelling, accepting or revising work | Hypervibe and Lanes | Planned |
hyper inbox, hyper message, hyper event | The inbox, including handing a decision to another person, team or role, plus addressed messages and events; Lanes carries the messages | Hypervibe and Lanes | Planned |
hyper inference | Inference usage, headroom, routes, cache and reservations | Throttle | Planned |
hyper build, hyper job, hyper artifact | Preparing and admitting builds, then a job's status, logs, artifacts and cancellation, and why it ended or is blocked | Reactor | Planned |
hyper fleet | Machines, machine teams, placement, draining, and policy canaries and rollbacks | Fleet | Planned |
hyper profile, hyper config, hyper grant, hyper policy | Settings, profiles, grants and policy | Hypervibe | Planned |
hyper auth, hyper device, hyper org, hyper team | Sign-in, devices, organizations and teams | Hypervibe | Planned |
hyper package, hyper connector, hyper skill, hyper tool | Extension packages, connectors, skills and tools | Hypervibe | Planned |
hyper eval, hyper outcomes | Evaluations, and outcomes for each class of work | Hypervibe | Planned |
hyper setup, hyper doctor, hyper update, hyper uninstall | Installation, diagnosis, update and removal; Reactor owns the installer that carries them out | Hypervibe | Planned |
hyper commands | The commands available here; hyper help is a compatibility form | Hypervibe | Planned |
!hyper runs only when you type it in a trusted composer #
A composer is the text box where you write to an agent in Rocket! or Lanes. Typing !hyper there at the start of a command, followed by a space or the end of the input, sends the rest to the command system. Its arguments are parsed directly, without shell expansion.
| Input | What happens |
|---|---|
!hyper and a command, typed at the start of a command | Parsed as a hyper command |
!hyperbole | Not a match; handled like any other ! input |
Another ! command | Literal shell input, never translated by a model |
!hyper inside pasted text, a code fence, a message, rendered content or tool output | Never runs, and is never rescanned later |
| Anything typed in a focused terminal | Hypervibe never intercepts it; the shell keeps its own syntax, and typing hyper there runs the real program |
The reason is that text never becomes authority. An agent's reply, a tool's output or someone else's message can contain any words, so containing a command must never be enough to act with your permissions. The same rule will cover @ references, which point to a file, an agent or a lane and are planned for a later release: only one typed or picked in a trusted composer is live.
One command registry will serve every surface #
The command line, the composer, the Commands list (the searchable list of actions you can take where you are), buttons and menus, native apps and agent tools are all designed to resolve a command to the same action. They differ in how you enter it, not in what it means or may do.
- Each action has a stable identity, an effect, an owner and a result type.
- Each invocation gets its own operation id. A retry or reconnection keeps it, and the owner looks up the first outcome before it acts again, so the effect is not repeated. The same id with a different request is refused as a conflict. A deliberate rerun gets a new id.
- Searching for a command selects it and never runs it.
- An agent's tool call is held to the same grants, costs and retry rules as a person's command.
- Extension packages add commands the same way, and none can shadow a built-in name.
No command is executable reference yet #
The command catalog records every entry as planned. It records no working implementation for any entry, and no settled format for any entry's arguments or results. An unsettled format is unfinished design, not permission to accept any input, and a generated menu item does not prove that a command works.
An entry becomes executable reference only when a qualification receipt exists for a named release, target and profile. Until then this page describes families and forms, not flags, defaults or examples.
Where to go next #
- Reference lists everything this section will hold.
- Rocket! describes the composer where
!hyperis recognized, and Lanes covers lanes, the inbox and messages. - Standings explains what makes a command Qualified.
- Glossary defines action, grant, receipt and the other words used here.
- Architecture shows which component owns each effect.