@quickchatai/pi-quickreview 1.1.0 → 1.3.1

package/README.md

@@ -9,21 +9,67 @@ pi install npm:@quickchatai/pi-quickreview
 
 ## Commands
 
-- `/review` reviews the current branch against its base. `/review 123` (or a
-  pull request URL) reviews a PR, and `/review --uncommitted` the uncommitted
-  tree. `--preview` shows the plan and the price without running anything.
-  The result is shown in the session, saved as markdown and JSON, or posted
-  to the PR as a comment-only review (`--to pr`); pi asks each time, unless
-  you keep an answer as the repo's default.
-- `/scan` scans the whole repo for defects, priced first and started only on
-  your yes. It runs the `qcr` CLI on your machine; `--sandbox docker` runs it
-  in the scan sandbox instead.
-- `/selfimprove` scans the repo, then hands the findings to this session's
-  agent with a fix loop: triage, fix with tests, review, and a re-scan of
-  what changed.
-- `/qcr-setup` checks the pi version, the login, git, GitHub access for PR
-  targets and the `qcr` CLI, and offers to install `qcr`
-  (`npm i -g @quickchatai/quickreview`).
+Each command is also a skill of the same name, so the model in your session
+knows the command and can tell you the line to type.
+
+- `/qcr-review [preset] [target]` reviews in the background: the command
+  returns at once, you keep chatting, the status line shows the review's
+  progress, and the result arrives in the session as a message (and is kept
+  as markdown and JSON under the qcr state home).
+  - The target: nothing reviews the current branch against its base together
+    with its uncommitted changes, as one review; `123`, `#123` or a pull
+    request URL reviews a PR; a branch name reviews that branch;
+    `--uncommitted` reviews the uncommitted changes alone.
+  - The preset, first when given: `quick` (lower reasoning, about half the
+    cost), `full` (the whole target again at the highest reasoning) or
+    `security` (only the security and data-safety lenses the change
+    triggers).
+  - `--preview` shows the plan and the price without running anything;
+    `--stop` stops the review that is running. One review runs per session
+    at a time, and ending the session stops it.
+  - After a PR review, your posting rule decides whether it goes to the PR
+    as a comment-only review (see Settings).
+- `/qcr-scan [--delta] [--sha REF] [--preview]` scans the whole repo for
+  defects, priced first and started only on your yes. It runs in the
+  background in this pi, like a review: a status line while it runs, the new
+  findings as a message when it ends, `/qcr-scan stop` to stop it. Its cases
+  are SDK sessions of this pi behind the same read-only bash guard as the
+  review's lenses. `/qcr-scan findings`, `status`, `units` and the other
+  scan subcommands pass through as typed. The scan sandbox (a container) and
+  dismissing a finding are the `qcr` app's (`qcr scan`).
+- `/qcr-setup` checks the pi version, the login, git and GitHub access for
+  PR targets. It then offers to set up this repo's profile (`.qcr/`), No
+  first: on your yes, your agent in the session surveys the repo, reads its
+  review history, interviews you and writes the profile for you to commit.
+  `/qcr-setup profile` starts that straight away. Its checks are steps on a
+  setup checklist (`src/setupchecklist.ts`) that the `qcr` app extends with
+  its own steps.
+
+`/review`, `/scan` and `/selfimprove` are gone: pi's command namespace is
+shared with every other extension, so the commands carry the `qcr-` prefix.
+`/review` is `/qcr-review`, `/scan` is `/qcr-scan`, and `/selfimprove` is a
+command of the `qcr` app's own pi (`qcr pi`).
+
+## Settings
+
+Your own defaults live in pi's settings (`~/.pi/agent/settings.json`, or the
+project's `.pi/settings.json`), under `quickreview`:
+
+```json
+{
+  "quickreview": {
+    "posting": "ask",
+    "preset": "quick"
+  }
+}
+```
+
+- `posting` decides what happens after a PR review: `ask` (the default)
+  asks, with "No, keep it here" offered first; `never` keeps every review in
+  the session; `always` posts without asking.
+- `preset` is the preset a `/qcr-review` without one runs under.
+
+Rules for one repository live in its profile, not here.
 
 ## Which pi
 
@@ -42,32 +88,38 @@ exactly instead; `qcr pi` starts that pinned pi with this plugin preloaded.
 - A pi login for the review's models (`/login` in pi). The review borrows
   it: pi refreshes it when needed, and the review only ever reads a copy.
   An API key for another provider is not used in its place: with no login
-  for the review's provider, `/review` stops and names `/login`.
+  for the review's provider, `/qcr-review` stops and names `/login`. The
+  scan borrows it the same way.
 - For a PR: the App when a qcr install configures one, else `GITHUB_TOKEN`,
   `GH_TOKEN` or `gh auth login`, in that order.
-- For posting (`--to pr`): a qcr config with `dry_run = false`. The shipped
-  defaults keep `dry_run` on, and then `/review` refuses to post and says so.
+- For posting: a qcr config with `dry_run = false`. The shipped defaults keep
+  `dry_run` on, and then a post is recorded under the qcr state home
+  (`review/dryrun/`) and nothing is sent; the post question says so.
 
 ## What it never does
 
-- The review never writes to your checkout: it reads the tree as it is.
-  (`/selfimprove`'s fixes are made by your own session's agent, under your
-  pi's own tools and permissions, not by the review.)
-- The review never runs your code, tests or app: it reads code and CI.
-- It never posts unless you choose `--to pr`, and then it posts one
-  comment-only review through the same mutation gate the bot uses. It never
-  approves, requests changes or dismisses a review.
+- The review and the scan never write to your checkout: they read the tree
+  as it is.
+- The review and the scan never run your code, tests or app: they read code
+  (and the review, CI).
+- It never runs the `qcr` CLI.
+- It never posts unless you say yes to the post question (or your posting
+  rule is `always`), and then it posts one comment-only review through the
+  same mutation gate the bot uses. It never approves, requests changes or
+  dismisses a review.
 - It never refreshes your login itself, and never hands a token to the
   model's tools.
 - It never gives your session a tool. The review's lens passes run in their
   own sessions, with none of your pi extensions, skills or settings, and
-  your session only sees the result.
+  your session only sees the result. The skills it ships are instructions
+  for your session's model, naming the commands.
 - It never sets or flips `dry_run`.
 - It never starts `claude`.
 
 ## What ships in the package
 
-The compiled review core and the plugin (`dist/`), and under `assets/` the
+The compiled review core and the plugin (`dist/`), one skill per command
+(`skills/`), and under `assets/` the
 data the core reads: the agents, prompts and seeds, the schemas, the
 profiles and the shipped config defaults. `assets/` is copied from the
 repository at pack time and checked file by file against its source, so the

package/assets/config.example.toml

@@ -6,10 +6,11 @@
 # supply are marked "← FILL (n)" — grep for FILL. Flip dry_run to false only
 # as a deliberate cutover act, never as part of setup.
 #
-# YOU DO NOT HAVE TO FILL THIS BY HAND: `scripts/qcr onboard` interviews you
-# for the few values only you can answer, derives the rest, and patches this
-# file in place — every comment survives, and a re-run edits only what changed.
-# It never writes dry_run in either direction; going live is its own explicit
+# YOU DO NOT HAVE TO FILL THIS BY HAND: a bare `qcr` (the home) writes the
+# repository you choose and its defaults, and the setup wizard's steps
+# interview you for the rest, derive what they can, and patch this file in
+# place — every comment survives, and a re-run edits only what changed.
+# Neither writes dry_run in either direction; going live is its own explicit
 # step. See docs/onboarding.md.
 # ONE mutation class is exempt and executes for real even here: the App
 # re-pointing its OWN webhook URL (see [ingress] below) — it can never touch
@@ -27,8 +28,22 @@ timezone = "UTC"                             # ← FILL: your IANA timezone, e.g
 
 [github]
 repo = ""                                    # ← FILL (1): the repo to review, "owner/name"
-app_slug = ""                                # ← FILL (2): your GitHub App slug
-bot_login = ""                               # ← FILL (3): the App bot login, "<app_slug>[bot]"
+# Whose GitHub credential the daemon runs on:
+#   "app"  (the default; a missing key means "app") — a GitHub App: its
+#          installation token, webhooks, APPROVE / REQUEST_CHANGES reviews.
+#   "user" — your OWN GitHub account, no App. Polling only: [ingress] shape
+#          must be "polling" (config load refuses anything else), no webhooks,
+#          no webhook self-heal. Every review posts as a COMMENT whose body
+#          states the verdict (an automated verdict never counts as your
+#          approval, and GitHub refuses either on your own PR). The token is
+#          read from the FILE <secrets dir>/github_token (0600, the token
+#          alone), which `qcr github-token sync` writes from your `gh` login;
+#          never from the environment or a command line. app_slug may be "";
+#          bot_login is your own GitHub login. The App secrets (app_id,
+#          app.pem, webhook_secret) are not needed.
+#auth = "app"
+app_slug = ""                                # ← FILL (2): your GitHub App slug ("" under auth = "user")
+bot_login = ""                               # ← FILL (3): the App bot login, "<app_slug>[bot]" (your login under auth = "user")
 review_team = ""                            # ← FILL (4): "org/team" whose review request triggers
 # There is no reviewer knob here. The reviewer never hands a PR back: it always
 # decides on the merits and posts a verdict. If you want a named person told
@@ -39,7 +54,8 @@ in_progress_label = "AI review in progress"
 reviewed_label = "Automatic Review"
 improvement_label = "Bot improvement"
 issue_label = "bot-filed"
-# secrets dir: app_id, app.pem, webhook_secret, tunnel_token; optional openai_api_key (pi, API-key
+# secrets dir: app_id, app.pem, webhook_secret, tunnel_token (auth = "user": github_token instead
+# of the first three); optional openai_api_key (pi, API-key
 # route) and openai_embeddings_api_key (only with embedding_provider = "openai" in the openviking table)
 # "" (recommended) = the install's config home, $XDG_CONFIG_HOME/qcr/<install>/secrets (the old
 # ~/.config/quickreview-bot is never read — `qcr install migrate` moves it). A path here wins.
@@ -81,8 +97,12 @@ port = 8787                                  # loopback only; your HTTPS ingress
 # touches only the App's own configuration, never the reviewed repo. Off by
 # default: with the section absent (or shape = "none") no watcher ever starts —
 # a stable hostname (named tunnel, VM route) needs none of this.
+# shape = "polling" takes no webhooks at all: the daemon's /webhook route
+# refuses every delivery, no webhook_secret is read, and the reconcile poll
+# (poll_interval_s, below) is the only trigger. [github] auth = "user"
+# requires it.
 #[ingress]
-#shape = "tunnel-file"                       # "none" (default) | "tunnel-file"
+#shape = "tunnel-file"                       # "none" (default) | "tunnel-file" | "polling"
 #hostname_file = ""                          # "" ⇒ <root>/state/ingress/hostname
 #debounce_ms = 3000                          # settle time after a file change
 #sweep_interval_s = 300                      # polling backstop behind fs.watch
@@ -204,7 +224,9 @@ improvement_pr_deny_prefixes = ["migrations/", "infra/", "ansible/", ".github/wo
 [models]
 # default for every role; tiered pass models below
 # Provider prefix is `openai-codex/` — the ChatGPT-OAuth route's provider key
-# in pi's auth.json (direct `openai/` needs an API key we don't ship).
+# in pi's auth.json. Any OpenAI login serves it: when pi holds no
+# `openai-codex` login but an `openai` one (pi 1.4's Sign in with ChatGPT, or
+# an OpenAI API key), the same model runs on `openai` (docs/llm-setup.md).
 default = "openai-codex/gpt-6.1-sol"
 conversation = "openai-codex/gpt-6.1-sol"
 # Passes always run at sol-high — single variant, not raisable (already top).
@@ -261,7 +283,11 @@ small_diff_lines = 150
 #             memory forward follows this knob too — it reaches the daemon
 #             container's loopback memory engine with a plain `docker exec`
 #             (the forward script's --local mode) instead of the ssh hop.
-# Always explicit: an empty ssh_host does NOT mean local.
+# Onboarding writes this from the recorded topology. Until it has (ssh with an
+# EMPTY ssh_host), the TUI never runs `ssh ""`: on a compose project (the
+# checklist recorded the local topology, or the project .env pins
+# QCR_VERSION) it reads the local stack and says so once; otherwise every
+# surface says "ssh_host is empty — set it to the VM's ssh alias".
 target = "ssh"
 ssh_host = ""                                # ← FILL (7): ssh alias of the VM running the container
                                              #   (leave "" when target = "local" — it is unused)
@@ -270,10 +296,14 @@ memory_container = ""             # the container the memory forward relays into
                                   # (OpenViking is the daemon container's child). On a VM running
                                   # the memory sidecar (the openviking table's endpoint =
                                   # "remote") set "quickreview-memory"; flip it back with the endpoint.
-remote_state_dir = "/opt/quickreview/state"  # host path on ssh; inside the daemon container on local
+remote_state_dir = "/opt/quickreview/state"  # host path on ssh; inside the daemon container on local,
+                                  # where this default reads as the release image's /opt/qcr/state
+                                  # (the compose state volume; onboarding writes it for local)
 remote_sandbox_root = ""         # "" = read the container's qcr.layout label (release: /opt/qcr, legacy: /opt/quickreview/sandbox);
                                   # a value here wins and is never probed
-sudo_docker = true                # docker on the VM needs sudo (root-owned socket)
+sudo_docker = true                # docker on the VM needs sudo (root-owned socket). On local, onboarding
+                                  # writes false, and the TUI drops sudo by itself when this user can open
+                                  # the docker socket (a sudo prompt behind the TUI can only fail)
 poll_interval_s = 3
 stale_after_s = 90                # DATA STALE banner past this written_at age
                                   # (the daemon rewrites status.json every ~30s)
@@ -338,6 +368,19 @@ session_dir = "state/pi-sessions"
 # lens_cache_stagger_ms = 2500
 # lens_pass_deadline_min = 8
 
+[home]
+# The home: a bare `qcr` opens the app's own pinned pi, on your own pi login
+# ($PI_CODING_AGENT_DIR, default ~/.pi/agent), with a panel of the
+# repository's pull requests. Every key is optional.
+#   model — the chat's model, "provider/id". The panel counts only this
+#           model's provider as signed in: a login under another provider
+#           cannot run the chat.
+#   tools — "reviewer": the model may call the plugin's tools, the home's
+#           own home_* tools and pi's read tools (read, grep, find, ls), and
+#           no MCP server starts. "full": every tool pi has.
+model = "openai-codex/gpt-6.1-sol"
+tools = "reviewer"
+
 [memory]
 # Round seeding — how much memory rides each round prompt and how
 # long the daemon waits for it. Memory NEVER blocks or delays a round: past
@@ -594,7 +637,10 @@ local_embedder_threads = 1
 # (COMPANION_DEFAULTS) are the shipped configuration; uncomment to override.
 # enabled = true                  # `qcr tui` starts it unless --no-companion
 # container_name = "qcr-companion"
-# image = "qcr-companion:release" # the release image (docker/Dockerfile) in companion mode, built from the app root: qcr companion rebuild
+# image = "qcr-companion:release" # the release image (docker/Dockerfile) in companion mode, built from the app root: qcr companion rebuild.
+#                                  # Left unset on a compose box (the project .env pins QCR_VERSION), a first start runs the
+#                                  # already-pulled ghcr.io/quickchatai/quickreview:<QCR_VERSION> instead of building, unless a
+#                                  # local build exists; a ghcr.io/quickchatai/quickreview tag set here is pulled, never built over
 # pihome_volume = "companion-pihome"   # its OWN pi auth — never the VM's auth.json
 # session = "companion"           # tmux session inside the container
 # model = "openai-codex/gpt-6.1-sol:medium"
@@ -859,7 +905,7 @@ extra_vendored_segments = []   # extra third-party markers (case-insensitive)
 # whatever — the system BEHAVES exactly as a build without the feature.
 # (The placeholder that renders empty leaves a blank line in the prompt, like
 # the sibling notes beside it.)
-# `qcr onboard`'s escalation step writes this section.
+# The setup wizard's escalation step writes this section.
 #
 # The configuration cannot be half-done: `enabled = true` with no `targets`,
 # or a rule pointing at a login that is not a target, or a rule that declares

package/assets/prompts/onboarding.md

@@ -26,6 +26,33 @@ never as a lecture up front.
 - **On a fully-finished installation** this session doubles as a diagnostic:
   `onboard_status` re-verifies everything; report what holds and what broke.
 
+## What the person needs, and the fast path
+
+Say this near the start, in two or three short lines. They need three things:
+a **model login** (pi's `/login` opens by itself the first time — any working
+OpenAI login is fine), their **GitHub sign-in** (`gh` logged in; on a Boxes VM
+it already is), and **one repository**. Setup ends once the defaults are in
+place and verified; the TUI then opens on the board, which lists the
+repository's open pull requests — they pick one there and press `R` to review
+it.
+
+Recommend the fast path and take its defaults unless they ask otherwise:
+
+- **topology** — `onboard_topology` with `choice: "local"` (this computer);
+- **GitHub** — `onboard_github_account` with no `github_auth`: where gh is
+  signed in it uses their own account by itself. Call it once to get their
+  recent repositories, then again with `repo`;
+- **ingress** — `onboard_ingress` with no `choice`: polling is the default
+  (the reviewer checks GitHub every few minutes; webhooks can come later);
+- **the first review** — not part of setup: after `finish_and_exit` the board
+  lists the open pull requests, and `R` on one starts its review at once, no
+  label to add.
+
+**Never ask for something no tool takes.** Every question you put to the person
+is a step's input (the tool's parameters say which). If a step asks for nothing,
+do not invent a question for it — run it. When a tool returns a refusal that
+lists options, read those options out; do not add your own.
+
 ## What you teach, when
 
 - **At the start** (one short paragraph): QuickReview is a deterministic
@@ -42,33 +69,46 @@ never as a lecture up front.
   (what the reviewer learns and keeps). Explain each only when its step is in
   front of you.
 
-## The last three steps
+## GitHub, in one step
+
+`onboard_github_account` is the GitHub question. On their own account it saves
+their token (0600, never shown — say so), installs a refresh every 20 minutes,
+and creates the trigger labels if their account may. Read out its refresh line
+as it is: on a machine without `crontab` it says what lapses and gives the
+manual command. If they want a GitHub App instead, call it with
+`github_auth: "app"`; the App steps then take over. Never call the App step on
+the own-account route: it is skipped there.
+
+## The last steps
 
 - **Bring-up is slow the first time.** Say so before you run it — the tool's
   own warning is there to be read out — and let its streamed output show. A
   long build is expected, not a hang.
-- **The proof round is the point of the whole session.** Ask the operator for
-  one real, open pull request of their own and have them add the trigger label
-  to it. Then follow it. When the review comes back, show it to them and let
-  them read it: this is their first sight of what the reviewer says, and it
-  still cannot have posted anywhere.
-- **The go-live offer is theirs, and only theirs.** Read out what dry-run is
-  and what going live means, then ask once and accept the answer. Do not
-  advocate, do not repeat the offer, and never call the tool with a decision
-  they did not say. Staying in dry-run is a finished, fully working
-  installation — say so plainly if they choose it, and mention that they can
-  flip later whenever they like.
+- **The reviewer needs its own model login.** The review sessions run in the
+  daemon's container, and a login never transfers from this machine into it.
+  Once the stack is up, the LLM auth step's `daemon_login` check names the one
+  command that opens it; ask them to run it in a second terminal, sign in, and
+  tell you — then re-run the LLM auth step. Without it the first review on the
+  board would fail at once.
+- **The first review and go-live come after setup.** `onboard_proof_round` and
+  `onboard_go_live` are marked "after setup": setup finishes without them. Do
+  not run them here unless the person asks. Say plainly that the installation
+  stays in dry-run (every intended GitHub write is recorded, nothing is
+  posted), and that going live is their decision later, from the home
+  (Advanced → "Dry-run or live"), once a review has shown them what it says.
 
 ## Finishing
 
-When every step reports done, say that `finish_and_exit` will re-verify the
-whole checklist one last time and, only if all green, close this session and
-open the TUI. If it returns red checks, that is the answer: explain them, fix
+When every setup step reports done (the "after setup" ones need not be), say
+that `finish_and_exit` will re-verify the whole checklist one last time and,
+only if all green, close this session: the home then lists the repository's
+pull requests, and they select one and press `alt+r` to review it now. If it
+returns red checks, that is the answer: explain them, fix
 what can be fixed through the step tools, and try again. Never present
 onboarding as finished while anything is red, and never tell the operator to
 quit around a red check.
 
-Before `finish_and_exit`, pass on what comes next, as the go-live step's
-`next` line says it: set up the repo with `qcr setup` (or `I` on the TUI
-board). Until then the reviewer knows nothing about this codebase. It is a
+Before `finish_and_exit`, pass on what comes next: the first review is `alt+r`
+on a pull request in the home; then tune the reviewer to the repository with
+the home's "Tune to this repo" (`t` on the panel). Until then the reviewer knows nothing about this codebase. It is a
 recommendation, once — never start it from here.

package/assets/schemas/review-result.v1.json

@@ -137,6 +137,10 @@
     "post": {
       "$ref": "#/$defs/post"
     },
+    "post_ready": {
+      "type": "string",
+      "description": "A finished PR review that was not posted: the file it is kept in, which a host that asks the person later posts through the gate exactly as `--to pr` would have."
+    },
     "run_id": {
       "type": "string",
       "description": "A detached run's id (start, status, stop)."
@@ -149,6 +153,14 @@
       "type": "string",
       "description": "What a detached run reviews."
     },
+    "started_at": {
+      "type": "number",
+      "description": "When a detached run was started, ms since the epoch."
+    },
+    "ended_at": {
+      "type": "number",
+      "description": "When a detached run ended (its exit or its stop), ms since the epoch; absent while it runs."
+    },
     "elapsed_s": {
       "type": "integer",
       "minimum": 0
@@ -165,6 +177,50 @@
           "items": {
             "type": "string"
           }
+        },
+        "live": {
+          "type": "object",
+          "description": "The running round's live log, projected: what the parent and each lens are doing now.",
+          "properties": {
+            "round": { "type": "integer", "minimum": 1 },
+            "parent_status": { "enum": ["active", "settled"] },
+            "last_activity": { "type": "string" },
+            "updated_at": { "type": "string" },
+            "active_tool": { "type": "string" },
+            "agents": {
+              "type": "array",
+              "items": {
+                "type": "object",
+                "required": ["agent", "status", "duration_ms", "tool_count"],
+                "properties": {
+                  "agent": { "type": "string" },
+                  "status": { "enum": ["running", "completed", "failed"] },
+                  "duration_ms": {
+                    "type": "number",
+                    "minimum": 0,
+                    "description": "The lens's time so far; a running lens's counts from its start between updates."
+                  },
+                  "tool_count": {
+                    "type": "number",
+                    "minimum": 0,
+                    "description": "Tool calls the lens has started; a finished lens keeps its final count."
+                  },
+                  "current_tool": {
+                    "type": "string",
+                    "description": "The running (or last) tool, as `<tool>: <args>` or the bare name."
+                  },
+                  "current_target": {
+                    "type": "string",
+                    "description": "While the lens runs: the path its current tool works on, when it names one."
+                  },
+                  "line": {
+                    "type": "string",
+                    "description": "The lens as one line a person reads: `security · read src/x.ts · 7 tools · 0:41`."
+                  }
+                }
+              }
+            }
+          }
         }
       }
     },
@@ -234,6 +290,10 @@
             "kind": {
               "enum": ["pr", "branch", "uncommitted", "diff"],
               "description": "What is reviewed: a pull request, the current branch against its base, the uncommitted working tree, or a unified diff handed in (`--diff`). Only a pr target can be posted."
+            },
+            "uncommitted": {
+              "const": true,
+              "description": "A branch target reviewed together with the working tree's uncommitted edits, as one review. Absent otherwise."
             }
           }
         },

package/dist/extensions/quickreview.d.ts

@@ -1,5 +1,7 @@
-import { type ExtensionAPI } from "@earendil-works/pi-coding-agent";
-import type { Runner } from "../src/plugin/session.js";
+import { type ExtensionAPI, type ExtensionCommandContext } from "@earendil-works/pi-coding-agent";
+import type { HostAuth } from "../src/plugin/login.js";
+import { type ReviewCommandDeps } from "../src/plugin/review.js";
+import type { Runner, SessionUi } from "../src/plugin/session.js";
 /** What the host entry hands the plugin. */
 export interface QuickReviewConfig {
     /** The process environment, read once by the host entry. */
@@ -9,13 +11,19 @@ export interface QuickReviewConfig {
     runner: Runner;
     /** Standard output (pi's print mode shows a command's result there). */
     print: (text: string) => void;
-    /** Test seams: the running pi's version, its agent dir, the range. */
+    /** Test seams: the running pi's version, its agent dir, the range, the
+     * review's core. */
     piVersion?: string;
     agentDir?: string;
     range?: string;
+    review?: ReviewCommandDeps;
 }
-/** The commands, in the order /qcr-setup names them. */
-export declare const QUICKREVIEW_COMMANDS: readonly ["review", "scan", "qcr-setup", "selfimprove"];
+/** The commands, each also a skill of the same name (skills/<name>/SKILL.md). */
+export declare const QUICKREVIEW_COMMANDS: readonly ["qcr-review", "qcr-scan", "qcr-setup"];
+/** The host pi's auth, by the shape the plugin asks of it. */
+export declare function hostAuth(ctx: ExtensionCommandContext, agentDir: string): HostAuth;
+/** The session's ways to reach the person, from a command's context. */
+export declare function sessionUi(pi: ExtensionAPI, ctx: ExtensionCommandContext, print: (t: string) => void): SessionUi;
 /** The plugin's extension factory over `config`. */
 export declare function createQuickReview(config: QuickReviewConfig): (pi: ExtensionAPI) => void;
 //# sourceMappingURL=quickreview.d.ts.map

package/dist/extensions/quickreview.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"quickreview.d.ts","sourceRoot":"","sources":["../../extensions/quickreview.ts"],"names":[],"mappings":"AAYA,OAAO,EAGL,KAAK,YAAY,EAElB,MAAM,iCAAiC,CAAC;AAOzC,OAAO,KAAK,EAAc,MAAM,EAAa,MAAM,0BAA0B,CAAC;AAI9E,4CAA4C;AAC5C,MAAM,WAAW,iBAAiB;IAChC,4DAA4D;IAC5D,GAAG,EAAE,MAAM,CAAC,UAAU,CAAC;IACvB,uBAAuB;IACvB,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,MAAM,CAAC;IACf,wEAAwE;IACxE,KAAK,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;IAC9B,sEAAsE;IACtE,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,KAAK,CAAC,EAAE,MAAM,CAAC;CAChB;AAED,wDAAwD;AACxD,eAAO,MAAM,oBAAoB,yDAA0D,CAAC;AAoE5F,oDAAoD;AACpD,wBAAgB,iBAAiB,CAAC,MAAM,EAAE,iBAAiB,GAAG,CAAC,EAAE,EAAE,YAAY,KAAK,IAAI,CAuEvF"}
+{"version":3,"file":"quickreview.d.ts","sourceRoot":"","sources":["../../extensions/quickreview.ts"],"names":[],"mappings":"AAsBA,OAAO,EAGL,KAAK,YAAY,EACjB,KAAK,uBAAuB,EAC7B,MAAM,iCAAiC,CAAC;AAIzC,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,wBAAwB,CAAC;AACvD,OAAO,EAKL,KAAK,iBAAiB,EACvB,MAAM,yBAAyB,CAAC;AAEjC,OAAO,KAAK,EAAc,MAAM,EAAE,SAAS,EAAE,MAAM,0BAA0B,CAAC;AAK9E,4CAA4C;AAC5C,MAAM,WAAW,iBAAiB;IAChC,4DAA4D;IAC5D,GAAG,EAAE,MAAM,CAAC,UAAU,CAAC;IACvB,uBAAuB;IACvB,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,MAAM,CAAC;IACf,wEAAwE;IACxE,KAAK,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;IAC9B;wBACoB;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,MAAM,CAAC,EAAE,iBAAiB,CAAC;CAC5B;AAED,iFAAiF;AACjF,eAAO,MAAM,oBAAoB,kDAAmD,CAAC;AAErF,8DAA8D;AAC9D,wBAAgB,QAAQ,CAAC,GAAG,EAAE,uBAAuB,EAAE,QAAQ,EAAE,MAAM,GAAG,QAAQ,CA8BjF;AAKD,wEAAwE;AACxE,wBAAgB,SAAS,CACvB,EAAE,EAAE,YAAY,EAChB,GAAG,EAAE,uBAAuB,EAC5B,KAAK,EAAE,CAAC,CAAC,EAAE,MAAM,KAAK,IAAI,GACzB,SAAS,CA6BX;AAED,oDAAoD;AACpD,wBAAgB,iBAAiB,CAAC,MAAM,EAAE,iBAAiB,GAAG,CAAC,EAAE,EAAE,YAAY,KAAK,IAAI,CAmGvF"}