← LuvusCONTENT HISTORY

Update to Luvus

Snapshot Sep 30, 2026 · 23:14 UTC · version 0.4.2

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Control Luvus through its local CLI and UHP. Use only for a line beginning with `=target message`, an explicit request naming Luvus, a request to delegate to a named live Luvus agent or pane, or an explicit Luvus operation involving sessions, workspaces, tabs, panes, agents, files, Git, DIFF, worktrees, tasks, leases, modules, themes, Luvus Bar, configuration, UI, integrations, or Luvus UHP. Do not use for ordinary coding, file edits, Git operations, tests, task planning, generic agent work, or parallelization unless the user explicitly connects the request to Luvus. Being inside Luvus does not trigger this skill by itself. Inside Luvus use the inherited session; outside use the installed production Luvus command and configured session.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 207
    },
    {
      "relative_path": "references/advanced-control.md",
      "size_in_bytes": 4141
    },
    {
      "relative_path": "references/uhp-control.md",
      "size_in_bytes": 5216
    }
  ],
  "name": "luvus",
  "skill_md_contents": "---\nname: luvus\ndescription: \"Control Luvus through its local CLI and UHP. Use only for a line beginning with `=target message`, an explicit request naming Luvus, a request to delegate to a named live Luvus agent or pane, or an explicit Luvus operation involving sessions, workspaces, tabs, panes, agents, files, Git, DIFF, worktrees, tasks, leases, modules, themes, Luvus Bar, configuration, UI, integrations, or Luvus UHP. Do not use for ordinary coding, file edits, Git operations, tests, task planning, generic agent work, or parallelization unless the user explicitly connects the request to Luvus. Being inside Luvus does not trigger this skill by itself. Inside Luvus use the inherited session; outside use the installed production Luvus command and configured session.\"\n---\n\n# Luvus\n\nUse Luvus's semantic CLI and UHP to delegate work, control the live workspace,\nand build explicit harness integrations. The skill adds no service, event loop,\nor polling process.\n\n## Route `=target` delegation first\n\nTreat `=target message` as Luvus delegation only when `=` is the first\nnon-whitespace character on a line, `target` contains no spaces, and a message\nfollows it. Do not treat equations, assignments, or `=` in prose as delegation.\nCodex skill invocations keep their `$skill-name` syntax.\n\nExamples:\n\n- `=reviewer inspect this diff` sends `inspect this diff` to the agent named\n  `reviewer`.\n- `=7 run the migration` addresses pane 7.\n- `=codex add tests` addresses the unique agent named or kinded `codex`.\n\nFor every delegation line:\n\n1. Run `luvus agent send <target> \"<message>\"` directly without `--wait`.\n   `agent send` resolves live names, numeric pane ids, and unique agent kinds\n   authoritatively. Do not run `agent list` first.\n2. On success, accept the returned pane, agent, name, and status, tell the user\n   where the work was sent, and end the turn. Do not reread or poll.\n3. Only after `not_found` or `ambiguous_target`, run `luvus agent list` once to\n   show the live choices. Never guess or retry a different target without the\n   user's choice.\n4. For any other error, report it without listing agents. Never absorb or\n   perform the delegated task locally after delivery fails. Start an agent only\n   when the user clearly requested it.\n\nPlain-language delegation requests follow the same workflow. Never delegate\nmerely because another agent could help.\n\n## Select exactly one session\n\nNever run bare `luvus` because it launches or attaches the TUI. Examples below\nsay `luvus` for readability. Substitute the client selected here.\n\n### Inside a Luvus pane\n\nWhen `LUVUS_ENV=1`, control the inherited session:\n\n- Require `LUVUS_BIN_PATH`, `LUVUS_SOCKET_PATH`, and `LUVUS_PANE_ID`.\n- Invoke the exact `LUVUS_BIN_PATH`. Let it use the inherited socket.\n- Keep `LUVUS_PANE_ID` as the caller and default split anchor.\n- Never replace the inherited socket or binary with a default, a PATH lookup,\n  or another Luvus session.\n\nAct on the inherited session only because the user is already inside that\nsession and explicitly asked for delegation or control.\n\n### Outside Luvus\n\nUse the installed production Luvus client:\n\n- Resolve `luvus` once with the current shell's command lookup, such as\n  `command -v luvus` on Unix or `(Get-Command luvus).Source` in PowerShell.\n- Invoke that exact resolved path for the rest of the request. This supports\n  Luvus installed by Cargo, Homebrew, `install.sh`, or another PATH-managed\n  installation.\n- Preserve an explicitly configured `LUVUS_HOME` or `LUVUS_SOCKET_PATH`.\n  Preserve `LUVUS_SESSION` too. When the user explicitly names a server\n  session, pass `--session <name>` directly to every related Luvus command.\n  Do not list sessions first, and do not silently fall back to `default`.\n  Otherwise let the installed release binary use its production default at\n  `$HOME/.luvus/luvus.sock`.\n- Never substitute `LUVUS_BIN_PATH` or a repository build for a missing\n  installed command.\n- Only after an attempted Luvus action cannot run because command lookup finds\n  no `luvus` client, report that Luvus is not installed and stop. Offer one of\n  the supported commands: `curl -fsSL https://luvus.dev/install.sh | sh`,\n  `brew install RizRiyz/luvus/luvus`, or `cargo install luvus`. Do not show this\n  guidance preemptively or for socket, permission, server, or other command\n  failures. Do not imply Luvus is available until a later lookup succeeds.\n- Start the production server only when the user asked to start or use Luvus\n  and starting it is a normal required step.\n\nIn the Codex app, local socket access may require permission outside the\nworkspace sandbox. Request that permission for the selected Luvus client. Do\nnot describe an unapproved sandbox failure as an offline server. Only report\nthe production server offline after an approved command cannot connect.\n\nUse the same selected binary and socket for the entire request.\n\n### Manage named server sessions\n\nA named session is an independent Luvus server and PTY tree, not a workspace.\nUse these commands only when the user explicitly asks to inspect or manage\nserver sessions:\n\n```sh\nluvus session list\nluvus session attach <name>\nluvus session stop <name>\nluvus session delete <name>\nluvus --session <name> pane list\n```\n\n`session attach` launches or attaches the TUI. Never run it merely to test\nwhether a session exists. `session stop` ends every pane in that named server.\nBefore deletion, list sessions once, require the exact stopped name, and obtain\nclear authorization. Never delete `default` and never substitute workspace\ncommands for server-session commands.\n\n## Use the fast command path\n\n- Run the requested semantic command directly. Do not prepend routine `help`,\n  `ping`, status, or list calls.\n- For delegation, call `agent send` directly. Treat `agent list` as recovery\n  only after `not_found` or `ambiguous_target`.\n- Use `help` only when syntax is uncertain or a command is unsupported.\n- Reuse live IDs, names, and results already returned in the thread.\n- Trust a successful mutation response that identifies its target. Do not\n  immediately reread the same state unless the response is incomplete.\n- Prefer one broad list over one status call per item.\n- Use bounded Luvus waits instead of shell sleeps or polling loops.\n\nMost commands return JSON with `.result` or `.error`. Parse exact IDs, indices,\npaths, names, and statuses from those results. Never infer a target from sidebar\nposition.\n\n## Choose the CLI or UHP deliberately\n\nUse the semantic CLI for ordinary Luvus control and delegation. It is the\nshortest path for one action and should not be replaced with raw protocol or\nterminal input.\n\nUse Universal Harness Protocol 1.0 only when the user explicitly asks for a\nLuvus API, harness integration, capability or schema discovery, sequenced\nevents, fenced snapshots, revision-safe automation, delegated access, or\nterminal-backend streaming. For that work, discover the installed server\ninstead of assuming support from documentation or a release number:\n\n```sh\nluvus uhp capabilities\nluvus uhp schema\nluvus uhp snapshot\n```\n\nThese discovery calls are an exception to the no-preflight rule because they\ndefine the live protocol contract. Do not run them before routine CLI actions.\n`luvus uhp proxy` forwards one newline-delimited JSON request from stdin to the\nselected local server. Validate the method and parameters against the installed\nschema before sending it.\n\nFor stateful UHP automation:\n\n1. Read capabilities and limits.\n2. Subscribe from a known event sequence and obtain a fenced snapshot.\n3. Apply only later events in order.\n4. Resnapshot after a sequence gap, overflow, reconnect, server-generation\n   change, or `resync_required` event.\n5. Use advertised revisions or `if_revision` for conflicting mutations.\n6. Prefer atomic methods such as `agent.start`, `agent.prompt`, `layout.apply`,\n   `workspace.move_block`, and `diff.note.apply` when the live capabilities\n   advertise them.\n\nThe default endpoint trusts the local owner and is not a public TCP service.\nCreate scoped, expiring UHP tokens only for an explicitly delegated harness.\nNever print, persist, or log token secrets, and never grant broader scopes than\nthe requested integration requires. Terminal observe and control streams are\nfor explicit harness or remote-client work. Control is exclusive, bounded, and\nmust be released when the task ends. Prefer `agent prompt`, `pane read`, and\nother semantic routes for ordinary automation.\n\nFor method families, event recovery, tokens, revisions, layout operations, and\nterminal streams, read\n[uhp-control.md](references/uhp-control.md) when it is installed. The rules\nabove remain sufficient when `luvus skill show` is the only available file.\n\n## Delegate and manage agents\n\nResolve existing agents with:\n\n```sh\nluvus agent list\nluvus agent get <target>\n```\n\nTargets are a live name, pane id, or unique agent kind. If a kind is ambiguous,\nask the user to choose or name the panes. Never guess.\n\nTo start and name a sibling agent from a managed pane:\n\n```sh\nluvus agent start reviewer --kind codex --timeout 30\n```\n\nFrom an external terminal, select a live anchor first:\n\n```sh\nluvus agent start reviewer --kind codex --anchor <pane-id> --timeout 30\n```\n\nTry the anchored start directly. Only when it returns a syntax or usage error\nshowing that `--anchor` is unsupported, use the compatible two-command path and\npass the new pane id returned by `pane split`. Do not run a help preflight:\n\n```sh\nluvus pane split <anchor-pane-id> --no-focus\nluvus agent start reviewer --kind codex --pane <new-pane-id> --timeout 30\n```\n\nOmit `--down` for a right-side split and add it to the split or anchored start\nfor a split below. Never combine `--anchor` and `--pane`.\n\nSend work with `agent send`, not raw pane text and Enter:\n\n```sh\nluvus agent send reviewer \"Review the current diff\"\n```\n\nDo not add `--wait` unless the user explicitly asks to wait or the next required\nstep depends on the result. In a managed pane, name the caller and ask the\nworker to report back when asynchronous delivery is useful:\n\n```sh\nluvus agent name lead\nluvus agent send reviewer \"Review the diff. When done, run: luvus agent send lead 'done: <summary>'\"\n```\n\nAfter a no-wait handoff, end the turn. The report-back message starts a fresh\nturn. An external terminal has no caller pane, so do not invent one.\n\nWhen waiting was requested, keep it bounded and read a bounded result:\n\n```sh\nluvus agent send reviewer \"Review the diff\" --wait --timeout 300\nluvus agent read reviewer --lines 120\n```\n\nTreat `idle`, `done`, `working`, and `blocked` as ready once the requested agent\nidentity is recognized. `unknown` is not proof of completion, but it does not\nundo a matching identity. When `agent start` returns `ready: true`, accept its\nname, pane, and kind without another status lookup. Use `wait agent-status` for\na requested lifecycle transition after work is sent, not for startup identity.\n\nFor a blocked agent:\n\n1. Run `luvus agent get <target>`.\n2. Run `luvus agent read <target> --source visible --lines 120`.\n3. Identify the exact approval or question.\n4. Send `agent keys` only when the user's request authorizes that effect.\n\n## Control panes, tabs, and workspaces\n\nUse these read routes before a write whose target is not already known:\n\n- `luvus workspace list`\n- `luvus tab list`\n- `luvus pane list`\n- `luvus pane status <id>`\n- `luvus pane read <id> --lines 120`\n- `luvus search <query>`\n\nWhen the user supplies a stable 0-based workspace index, run the requested\nmutation directly. Run `workspace list` only to resolve a name, path, or sidebar\nposition to an index, or once after `not_found` to show current choices. Reuse a\ncurrent list result from the thread and do not run `help` before these documented\ncommands. Renaming changes the label, never the folder; pinning changes sidebar\ndisplay order, never the API index:\n\n```sh\nluvus workspace rename <workspace-index> <name>\nluvus workspace pin <workspace-index>\nluvus workspace unpin <workspace-index>\n```\n\nClosing the final project does not stop the client or leave it without a shell.\nLuvus immediately creates a neutral workspace and terminal at the user's home\ndirectory. Its displayed path follows the focused pane's live cwd. An empty\n`workspace list` is therefore an exceptional restore or spawn failure, not proof\nthat the server is offline. Use `workspace open <path>` when the user named a\nspecific project.\n\nFrom a managed pane, use `LUVUS_PANE_ID` as the caller or split anchor. From an\nexternal terminal, select an explicit pane returned by live state.\n\nTo run an ordinary command beside an explicit pane without stealing focus:\n\n```sh\nluvus pane split <anchor-pane-id> --no-focus\nluvus pane run <new-pane-id> \"cargo test\"\nluvus wait output <new-pane-id> --match \"test result\" --timeout 300\nluvus pane read <new-pane-id> --lines 120\n```\n\nFork a supported live agent only after resolving it with `agent get`. The fork\ninherits the source conversation but receives its own new session:\n\n```sh\nluvus agent get <target>\nluvus agent fork <target> [--name <alias>] [--no-focus]\n```\n\nNative forks currently support Claude, Grok, Codex, Pi, and OMP. Report\n`unsupported_agent`, `session_unknown`, or `spawn_failed` exactly when returned.\nDo not approximate a failed fork with `pane split`, `agent start`, or `resume`,\nbecause those paths do not guarantee an independent copy of the conversation.\n\nMove an existing pane only after resolving its id and listing the destination\ntabs in that pane's workspace. Tab numbers are 1-based:\n\n```sh\nluvus pane move <pane-id> --tab <tab-number>\nluvus pane move <pane-id> --new-tab\n```\n\nReorder tabs in the active workspace only after `luvus tab list` confirms the\nsource and final positions:\n\n```sh\nluvus tab move <from> <to>\n```\n\n## Control advanced surfaces safely\n\nThis section remains complete when `SKILL.md` is installed by itself. If\n[advanced-control.md](references/advanced-control.md) is available, read it for\na compact command index. Its absence is not a blocker and never permits a\nguess or a weaker safety check.\n\nUse these read routes to resolve state and exact targets:\n\n- Files and Git: `luvus files tree`, `luvus git status`,\n  `luvus git branches`, `luvus git log`\n- DIFF: `luvus diff list`, `luvus diff get <path>`,\n  `luvus diff note list`\n- Worktrees: `luvus worktree list`\n- Orchestration: `luvus task list`, `luvus task get <id>`,\n  `luvus lease list`\n- Modules: `luvus module list`, `luvus module info <id>`,\n  `luvus module actions`, `luvus module settings <id>`,\n  `luvus module log <id>`\n- Themes and UI: `luvus theme list`, `luvus bar list`,\n  `luvus ui dock list`\n\nRun `luvus help all` only when the requested mutation grammar is uncertain.\nThis remains compatible with older Luvus releases. Before changing an advanced\nsurface:\n\n- Inspect files and Git before opening a file, revealing a path, refreshing\n  the tree, or opening a Git view.\n- Inspect the exact DIFF layer and file before opening it or adding, editing,\n  resolving, removing, applying, or sending a review note. Removing a note and\n  sending feedback to an agent require explicit authorization.\n- List worktrees before creating, opening, or removing one. Removal requires\n  explicit authorization and an exact path.\n- Inspect task and lease ownership, dependencies, gates, assignees, and path\n  leases before claiming, starting, updating, completing, releasing, deleting,\n  or merging.\n- Inspect module metadata, actions, settings, and logs before changing module\n  state. Installation, uninstallation, and consequential setting changes need\n  clear authorization.\n- Validate theme sources before installing them. Do not uninstall the active\n  theme or fetch a remote theme without explicit authorization.\n- CLI widget commands use `luvus bar ...`; the UHP method family is\n  `ui.bar.*`. Inspect widgets and docks before changing placement or content.\n  Avoid sidebar, dock, notification, toast, bar, or focus changes unless they\n  serve the user's request.\n- Open Mission Control directly with `luvus mission open [<workspace>]` when\n  the user asks for it. The optional workspace index is 0-based; omit it to\n  target the active workspace. For UHP automation, use the workspace-scoped\n  `mission.open` method.\n- Agent detection is built into Luvus. `luvus integration install` manages\n  optional native session-resume hooks and must not be used merely to make an\n  agent appear in the sidebar. Install or remove an integration only when the\n  user explicitly requests that lifecycle integration.\n- For Hermes, `luvus integration install hermes` adds exact per-pane session\n  ownership while native read-only session discovery remains the fallback.\n- Subscribe to events only for a live monitoring request. Stop when its\n  condition is satisfied and never retain an unbounded stream.\n\n## Learn configuration and unfamiliar surfaces\n\nUse `luvus help <topic>` for the installed command grammar and\n`luvus uhp capabilities` plus `luvus uhp schema` for a selected server's live\nautomation contract. For configuration, installation, concepts, or a surface\nnot covered here, read https://luvus.dev/agent-readme.md first and use\nhttps://luvus.dev/llms.txt to open only the relevant documentation page.\n\nLuvus preferences live in `config.json` under `~/.luvus/`, or under the\nexplicit `LUVUS_HOME`. Debug builds use `~/.luvus-dev/`. Prefer the Settings\nscreen for validated live changes, preserve unknown fields during a manual\nedit, and never substitute production, development, or named-session paths.\nThe installed binary and selected running server remain authoritative when the\nwebsite describes a newer release.\n\n## Safety\n\n- Use explicit targets for writes. A focused pane may belong to another client.\n- Preserve focus and inactive-pane scroll positions unless asked to change\n  them.\n- Preserve prompts, paths, Unicode, quotes, dollar signs, equals signs, and\n  newlines as arguments. Avoid an unnecessary `sh -c` interpolation layer.\n- Do not close panes, tabs, or workspaces, remove worktrees, delete or merge\n  tasks, uninstall modules, or overwrite consequential settings without clear\n  authorization and a read-only target check.\n- Never stop or restart a Luvus server as a normal control step. Do so only\n  after an explicit request and a warning that every managed pane is affected.\n"
}

SHA-256 of public snapshot: a89c4832a2ae1d56c240f2265d941dafb27264518bf14edaf2e69ef689d8b7f1