Repository navigation
v1.43.0
A session with the revier skill can now do a full round trip with another agent: add its tab, prompt it, and read its answer. worktree-merge got stricter and safer: it finds the PR of a worktree, merges the PR as it is, takes the merge method the repository uses, and keeps your gitignored files.
A session reads the answer of the agent it prompted
revier 0.14.0 added revier agent read, revier agent send-keys and revier agent new --no-focus. The revier skill described the CLI as it was before, so a session handed work to you that it can now do itself. With revier 0.14.0 or later, the skill does three new things:
- It reads the answer. After a prompt, the session waits for the other agent, reads its last message with
revier agent read, and puts it in its reply. Before, it told you that the result is in the window of that agent. Where revier cannot read the last message (the agent of a link, a harness other than Claude Code, an agent that has said nothing), the session reads the text of the panel with--screen. - It adds the agent tab. Where a project has an open workspace and no agent, the session runs
revier agent new --no-focus -p <name>and waits for the harness to start. Before, it gave you the command to type. The guard has permitted this command since v1.42.0; the skill now uses it.revier openfor a workspace that does not run stays a command you run. - It can answer a dialog, where you ask for that. For an agent that waits at
attention, the default is the same as before: the session reports the agent and sends no key. Where you ask in the session for an answer, it reads the screen of that agent, sends only keys that the screen offers, and reads the screen again. It sends one answer. Where the dialog is gone, it continues with the prompt or the read. Where the dialog stays, it stops and reports the text.
On a revier before 0.14.0 the skill keeps the earlier steps. The session selects the steps from the installed version that the skill prints; no code enforces the selection.
The new steps were checked against the text of the skill and revier agent --help. No session drove the full round trip before this release.
worktree-merge takes the merge method the repository uses
Where a project documents no merge method, worktree-merge always merged with a merge commit, also in a repository that squashes every PR. It now takes the first of these that gives an answer:
- The one method the repository allows.
- The method of the last five merged PRs on the base branch, where all five agree and the repository allows it.
--merge, where the repository allows it. Else the run asks you.
The report names the method and the rule that selected it. Rule 2 tells a squash from a rebase by a commit subject that ends in (#<number>), which is a heuristic. A project that documents its method is not affected.
worktree-merge keeps your gitignored files
The worktree removal deleted gitignored files without a word: the clean check reads git status --porcelain, which leaves them out. Before the removal, the run now lists the ignored entries and passes over a symlink, an entry that the setup or the build makes again, and an entry equal to the copy in the main checkout. For each entry left, it asks whether to copy it to the same path in the main checkout or to drop it. An entry can be a whole directory. The report lists each one and where its copy is.
Which entries count as made again by the build is the judgement of the session, not a fixed list.
Fixes
worktree-mergewith no argument found no PR in a worktree whose branch was pushed under another name.ghfinds a PR by the local branch name, andworktree-shipcan push under another one. The run now takes the pushed branch from the upstream of the current branch. With no upstream, or with the default branch as upstream, it asks for the PR number.- A PR that was behind its base failed at the merge, after the CI wait, in a repository that requires an up-to-date branch. The run now reads the merge state first. For a PR that is behind, it runs
gh pr update-branch, pulls in the worktree, and waits for CI on the new commit. It reads the state again after CI, so a base branch that moves while the checks run can cause more than one round. - A merge run repaired the PR. After a failed check or a refused merge, a session could edit files, push, and then merge the result with no word from you. The skill did not say what a stop forbids. The run now edits no file of the PR and pushes no commit: a stop ends the run with a report, and the head of the PR stays as it was. The one exception is the
gh pr update-branchabove. project-review-change --fixcould apply an edit for a finding the reviewer graded only plausible. The reviewer could grade a finding plausible and tag its actionsettled, and--fixapplies each settled action with no question. An action now counts as settled only where every finding it names is graded proven. Any other action comes back as an open question, and the--fixreport names it as not applied. The trade-off: a--fixrun can apply fewer edits and ask more questions.- The structured result of
project-review-codebasehad no rules dimension. The rules dimension ran, but the schema had norulesvalue, so its findings came back under another dimension and the result had no rules verdict.findings[].dimensioncan now berules, anddimension_verdictscan hold aruleskey. The key is absent on a run with no rules file. - After a rebase merge, the local PR branch could stay behind.
git branch -drefuses a branch whose commits were rewritten. The run now deletes it with-Dafter a rebase merge too, as after a squash merge.
Changed behavior worth knowing
worktree-mergestops for a PR whose base is not the default branch of the remote. This applies to an open PR and to one you already merged on GitHub: no merge, and no worktree is removed. In a project whose documented base branch is not the default branch (develop, for example),worktree-shipopens the PR against the documented branch, andworktree-mergethen stops for that PR. Merge and clean up such a PR by hand.worktree-mergeno longer repairs. For a failed check, a conflict with the base branch, an unmet branch rule (a missing approval, for example), or a merge that GitHub refuses, the run ends with a report. Start the repair as a new change, then start the merge again.worktree-mergecan stop and ask before it removes the worktree, once for each gitignored entry of yours. A run that finished unattended before can now wait for an answer.worktree-mergemoves the head of a PR that is behind its base, withgh pr update-branch, and asks no question first.worktree-mergemay squash or rebase where it made a merge commit before: in a repository that allows one method alone, or whose last five merged PRs all used the same method. To pin the method, document it in the project.worktree-mergehas two new early checks.gh auth statusmust succeed. And wheregh pr checksprintsno checks reported, the run tries again for up to one minute before it concludes that the project has no checks, so a project with no CI waits that minute on each merge.worktree-shipopens one PR per run, with an explicit--base. The base is the base branch the project documents, else the default branch of the remote. It opens no PR on the branch of another PR. Where the head commit of another open PR is in the commits of the change, the run stops before it commits and pushes, and reports the two ways on: that PR merges first, or both changes go into one PR.- The
revierskill pre-approves two more commands:revier agent readandrevier agent new --no-focus. A session with the skill can add an agent tab to an open workspace, and read the last message or the panel text of another agent, with no permission prompt.revier agent promptandrevier agent send-keysare not pre-approved. On kitty, a workspace window that does not hold the keyboard shows the new tab, although the focus does not move. - A consumer of the
project-review-codebaseresult sees a fourth dimension value,rules. Code that handles onlyconsistency,structureandarchitecturemust accept it, and must not require therulesverdict.
Full Changelog: v1.42.0...v1.43.0