@staff0rd/assist 0.660.2 → 0.661.0

package/README.md

@@ -113,6 +113,7 @@ Every command supports `--help` for full detail on its flags and behaviour.
 - `assist watch report [--from <sha>]` - Print the built version from `package.json`, the last 10 commits as a markdown SHA/When/Subject table newest-first, a **Restarts** section naming the restarts the new commits make necessary, and a **Sync** section naming what changed under the paths `assist sync` installs (`claude/commands/`, `claude/skills/`, `claude/settings.json`, `claude/design-system-prompt.md`, `codex/`, `pi/`), or `- not needed`. With `--from`, commits reachable from `HEAD` but not `<sha>` are marked `← new` and both the restart and sync advice come from the files they changed. Exit codes: `0` printed, `1` git could not resolve the range
 - `assist read-time <target> [--budget <duration>]` - Estimate how long a document takes to read, printing e.g. `142 words · ~1m 39s read`. `<target>` is a pull request number, a GitHub pull request URL (which may point at another repo), `-` to read from stdin, or a path to a file; the current branch's PR is deliberately not a default. Prose counts at `readTime.wordsPerMinute` (default 200) and fenced code at half that, with a bare URL or an image/HTML tag counting as one word. The effective rate decays as the document grows, so a 500-word one reads at ~70 wpm and a 2000-word one at ~55. When the estimate exceeds the budget — one minute unless `--budget` (`45s`, `1m30s`, `2m`) says otherwise — `· over the ~1m budget` is appended
 - `assist prs` - List pull requests for the current repository
+- `assist prs status <owner/repo>... [--json]` - Report every open pull request across the named repos, grouped by repo. Each PR carries its number, title, url, author, draft and bot flags, `createdAt`/`updatedAt` with an age derived from `updatedAt`, the review decision and each latest reviewer's state, the failing and pending check names from the status check rollup, and the mergeable/conflict state. Drafts and bot PRs are flagged rather than filtered out, and the judgement of what is "pending review" is left to the caller. A repo that is not an `owner/repo` argument, is missing, or cannot be read is reported as an error entry beside the repos that succeeded, and the command still exits 0. `--json` emits the whole payload (`repos` and `errors`) instead of the human listing
 - `assist prs raise --title <t> --what <w> --why <y> [--how <h>] [--resolves <ref>] [--force] [--draft|--no-draft]` - Raise a PR, assembling the body from What/Why/How. Whether the PR is created as a draft comes from `prs.draft` unless `--draft` or `--no-draft` is passed, which always wins. In a web session the draft is previewed for approve/reject (with inline comments and pasted screenshots or video, hosted via the [`gh-image`](https://github.com/drogers0/gh-image) gh extension) before the PR is created. The preview pane carries two independent chain checkboxes, both default on: **Review PR** chains a `review --no-prompt --submit <n> --address-comments` session once the PR is raised (review → post findings → Address Comments), and **Post to Slack** announces the PR in Slack at the tail of that chain — or directly via `/prs-slack <n> --no-confirm` when Review PR is off. With both on, approving runs raise → Review PR + Post to Slack → Address Comments → Slack announce end to end. A third checkbox, **Auto-merge (squash)**, defaults off and is offered for both a new PR and an update to an existing one: approving with it ticked runs `gh pr merge --auto --squash` on the current branch's PR once it is placed, before the chain runs, and a repo that refuses auto-merge only prints a warning. It and **Draft** untick each other, since GitHub refuses auto-merge on a draft PR
 - `assist prs edit [--title <t>] [--what <w>] [--why <y>] [--how <h>] [--resolves <ref>]` - Update only the supplied sections of the current PR's body. In a web session the resulting title and body are previewed for approve/reject first (with inline comments and pasted screenshots or video, as for `raise`); on approval the edit is applied with any screenshots appended, on rejection the reviewer's comments are printed and nothing is changed. Outside a session the edit applies directly
 - `assist prs read-time <target> [--budget <duration>]` - Alias of `assist read-time`, kept because the estimate began as a pull request check
@@ -137,10 +138,14 @@ Every command supports `--help` for full detail on its flags and behaviour.
   - `--apply` - Skip posting; walk through each finding asking apply/skip. Applied findings are fixed in the working tree
   - `--backlog` - Skip posting; file all findings as a single bug backlog item with one phase per finding
   - `--checkout-only` - Skip the review entirely; check the PR out and leave an idle interactive Claude session running in the checkout tree. Requires a PR number, and cannot be combined with `--refine`, `--apply`, `--backlog` or `--submit`
+  - `--high-level` - Skip the LLM review; evaluate the high-level review checklist against the PR description and its changed files and print every item as pass, fail or manual. The deterministic items are What/Why present, description under `review.highLevel.descriptionWordCap`, a GitHub issue linked, and a screenshot or video whenever a changed file matches `review.highLevel.uiPaths`; the manual items — change structure, critical-file diffs, backend PR linked — are named with what backs them. Nothing is posted to GitHub. Cannot be combined with `--refine`, `--apply`, `--backlog`, `--submit` or `--checkout-only`. See [docs/high-level-review.md](docs/high-level-review.md)
   - `--address-comments` - After the review posts comments and submits, start an Address Comments session (`assist review-pr-comments <n>`) for the PR. Only fires inside an assist session, and only when at least one comment was posted and the review was submitted
   - `--announce` - Announce the PR in Slack (`/prs-slack <n> --no-confirm`) at the tail of the chain: the Address Comments session announces once every thread is processed when one was started, otherwise a `/prs-slack` session is started directly. Announces exactly once, and only inside an assist session
   - `--verbose` - Per-line log output instead of the stacked-spinner UI (automatic in CI)
   - `review.codexModel` - Optional; set it (`assist config set review.codexModel gpt-5-codex`) to run the codex half of the review against that model on the LiteLLM proxy, injected per-invocation so `~/.codex/config.toml` is untouched. Requires `litellm.baseUrl` and `litellm.apiKey`; with either of them missing, or the key unset, the reviewer runs plain codex on the user's own codex auth. While the model is in use it is named in the codex spinner line and in any codex failure output. The cached `codex.md` is keyed on the review directory rather than the model, so after changing `review.codexModel` the previous model's review is reused until a run passes `--force`
+  - `review.highLevel.criticalPaths` - Comma-separated globs (`assist config set review.highLevel.criticalPaths "**/*.graphql,en-AU/translation.json"`) whose full diffs back the critical-diff checklist item. Unset, no file is treated as critical
+  - `review.highLevel.uiPaths` - Comma-separated globs (`assist config set review.highLevel.uiPaths "src/ui/**"`) that make a change a UI change, so `--high-level` requires a screenshot or video in the description. Unset, the UI-evidence check passes — a repo that has not said which files are UI cannot be told it is missing a screenshot of one
+  - `review.highLevel.descriptionWordCap` - Word cap `--high-level` holds the PR description to (`assist config set review.highLevel.descriptionWordCap 300`); defaults to 300
 - `assist github commits <org> [--since <date>] [--top <n>] [--json]` - Report commit activity across a GitHub organisation: repos ranked by commits, top committers, and a per-repo author breakdown
 - `assist github issue create --title <title> --body <body> [-R <owner>/<repo>] [--type <name>] [--parent <issue>] [--project <number>] [--status <name>] [--label <name>]` - Create a GitHub issue on the current repo (or `-R`'s). There is no What/Why/How template — an issue reports a problem, and the target repo's own issue template is unknowable from here. The title and body are rejected if they reference Claude or an assist backlog item, and in a web session they are previewed for approve/reject first (with inline comments and pasted screenshots or video, as for `prs raise`, appended under `## Screenshots` on approval); nothing is created until it is approved. `--type` sets the native issue type after creation, `--parent` files the new issue as a sub-issue of the referenced issue (`owner/repo#number`, a github.com issue URL, or a bare number read against `--repo` or the current repo; a parent in another repository is allowed), `--project` adds the issue to the repo owner's project of that number, `--status` sets that project item's Status, and `--label` applies repo labels (repeat the flag or pass a comma-separated list). All five are resolved before the preview — including the token's `project` OAuth scope, whose remediation is `gh auth refresh -h github.com -s project` — so an unknown name, an unreadable parent, a missing scope, or `--status` without `--project` creates nothing. The preview pane names the repo, type, parent, project, status and labels above the body without adding them to the posted body. Raw `gh issue create` is denied in favour of this command
 - `assist github issue edit <number> [-R <owner>/<repo>] [--fresh]` - Rework an existing GitHub issue's body in the web preview pane. Fetches the issue's current `title`, `body` and `updatedAt` with `gh issue view`, writes the body to a working file under `~/.assist/github-issues/`, and previews it for approve/reject. Approving pushes the pane's markdown back with `gh issue edit --body-file`; nothing is pushed if the issue was updated on GitHub after it was fetched (the working file is named instead, so nobody else's edit is clobbered) or if the preview is rejected. Rejecting writes the pane's markdown — collapses included — to the working file and names it in the output, so the revision is made in that file rather than composed from scratch; a re-run resumes from the working file while the issue has not moved on GitHub, and `--fresh` discards it and re-fetches. Outside a web session there is no pane to edit in, so the command just prints the issue — callers never need to detect the session themselves. Only the body is touched — the title, labels, assignees and state are left alone. Raw `gh issue edit` is denied in favour of this command

package/allowed.cli-reads

@@ -47,6 +47,7 @@ assist miro extract
 assist news
 assist prs list-comments
 assist prs read-time
+assist prs status
 assist ravendb auth list
 assist ravendb collections
 assist ravendb query

package/dist/allowed.cli-reads

@@ -47,6 +47,7 @@ assist miro extract
 assist news
 assist prs list-comments
 assist prs read-time
+assist prs status
 assist ravendb auth list
 assist ravendb collections
 assist ravendb query