Commands

This page lists the available commands. For the ideas behind the review workflows, read Review agent work.

Open a review

cueloop                     # open the inbox (every pending review)
cueloop <session-id>        # open one session by its ses_… id
cueloop plan [id|title]     # latest pending plan, or one you name
cueloop reply [id|title]    # latest pending reply review
cueloop diff [id|title]     # working-tree diff review
cueloop pair [thread-id]    # live pairing workbench
cueloop prototype [file]    # review a component design doc (Markdown)
cueloop review <pr>         # pull a pull request in and review it

Install an extension

cueloop install npm:<package>[@version]

Installed UI entries load when you next start cueloop. Run cueloop restart to load daemon entries, including VCS adapters. See Extensions.

• cueloop with no arguments opens the inbox across all types.
• cueloop plan opens the latest pending plan review. Pass an id or title to address a specific one.
• cueloop reply opens the latest pending reply review - an agent's message submitted for review before you act on it. It reads like a plan and uses the same comments and Messages.
• cueloop diff is dual-mode: on a dirty working tree with no argument it creates a review from the current changes (untracked files included); with a selector, or on a clean tree, it opens the latest pending diff review.
• cueloop prototype is dual-mode: with a Markdown file it creates a review of a component design doc (its prop API, composition, and callstack) that you comment by line; with no file (or --latest / --open) it opens the latest pending prototype review. An .html file instead creates the opt-in experimental pixel mockup ([experimental] prototype_pixels).
• cueloop review <pr> is dual-mode too: a bare review (or --latest / --open / a ses_… id) opens a pending pull-request review, while any other value is treated as a PR reference and pulls that PR in via gh.

Flags (on plan, reply, diff, prototype, review):

• --latest - open the latest pending review of that type.
• --open [id|title] - open a pending review, optionally by id or title.
• --no-tui - (on review <pr>) skip the UI and print the created session as JSON.
• --head-sha <sha> - (on review <pr>) refuse to open a Thread if the PR moved after the agent reviewed it.

Share over SSH

cueloop share [session-id]        # upload a plan, copy the ssh line
cueloop share --fork [session-id] # fork the plan, then share the fork
cueloop share pull [session-id]   # pull a teammate's comments back
cueloop serve [session-id]        # serve a live session over SSH yourself

• cueloop share uploads the plan to the gateway and copies a single ssh p_…@cueloop.dev line for a teammate. With no id it shares the most recent session. Flags: --host (default cueloop.dev), --port (default 22), --fork to share a fork of the session so a second teammate gets their own copy and discussion.
• cueloop share pull adds a teammate's comments to your plan. Run cueloop share first. Only the key that shared the plan can pull it.
• cueloop serve hosts a session from your own machine over SSH; observers are read-only and you stay the writable controller. Flags: --port (default 2222, 0 picks a free port), --host (default 127.0.0.1).

See Share a Thread for the full workflow.

Post to GitHub

cueloop review-post <session-id> --comments C1,C3 --event comment --body-file review.md

Posts selected agent findings from a completed Thread. Omit --comments to post every unresolved agent finding. Posting is always explicit. The Thread's send-message text gives instructions to the agent and is never posted as the GitHub review body. Use --body or --body-file for a separate review body.

comment         → COMMENT
approve         → APPROVE
request-changes → REQUEST_CHANGES

The Message summary becomes the review body.

Automation

cueloop session <operation> [flags] # automate Thread operations; JSON on stdout
cueloop refine                     # summarize feedback from past Threads
cueloop daemon                     # keep the background service running
cueloop --help                     # print help

cueloop session exposes Thread operations for scripts and agents. Operations: create, get, list, wait, annotate, remove, cut, restore, curate, set-viewed, navigate, branch, switch, label, fork, name-self, events, resolve, submit-revision. Each prints JSON, so it composes with other tools. Run cueloop session with no primitive for the flag list.

Discussion operations:

cueloop session annotate <id> --quote "two phases" --body "Why two?"     # a comment
cueloop session annotate <id> --reply-to <comment-id> --body "Rollout."  # a reply, on the root's anchor
cueloop session annotate <id> --selector "main > h1" --body "Too loud."  # a pixel-prototype comment, by element (experimental)
cueloop session remove <id> <comment-id>                                 # remove a comment
cueloop session name-self <id> "Ana" --author <fingerprint>              # the display name of an author
cueloop session events <id> [--once] [--ready]                           # follow events; --ready prints after subscribing

Review operations:

cueloop session cut <id> <block>                                  # drop a block of a plan from the working copy
cueloop session restore <id> <block> [--line <n>]                 # put a cut block back, before line n
cueloop session curate <id> --rejections '[{"path":"src/a.ts","hunkIndex":0}]'  # reject hunks of a diff
cueloop session set-viewed <id> <path> [<path> ...]               # mark files as walked

Block indexes refer to the submitted revision and remain stable while you edit. Pull-request diffs are read-only, so curate applies only to working-tree diffs.

History operations:

cueloop session label <id> "before the rewrite"          # name the current tip as a checkpoint
cueloop session branch <id> alt                          # start a branch at the tip and switch to it
cueloop session switch <id> main                         # show another branch's path
cueloop session navigate <id> <entry-id> [--summary ""] # move the tip back to an entry on its path
cueloop session fork <id>                                # copy the path into a new session
cueloop share --fork [<id>]                              # fork, then share the fork

Navigating back does not delete later work. A fork copies the current path into a new Thread. See History for the full behavior.

cueloop refine writes a Markdown report of reviewer comments from past Threads. It prints JSON with the report path. Use --limit to change the default maximum of 200 Threads.

cueloop daemon keeps the background service in the foreground for a process manager. Other commands start it automatically.