Skip to content

v1.43.0

Choose a tag to compare

@hk9890 hk9890 released this 11 Oct 12:58
· 137 commits to master since this release
2d545f5

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 open for 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:

  1. The one method the repository allows.
  2. The method of the last five merged PRs on the base branch, where all five agree and the repository allows it.
  3. --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-merge with no argument found no PR in a worktree whose branch was pushed under another name. gh finds a PR by the local branch name, and worktree-ship can 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-branch above.
  • project-review-change --fix could apply an edit for a finding the reviewer graded only plausible. The reviewer could grade a finding plausible and tag its action settled, and --fix applies 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 --fix report names it as not applied. The trade-off: a --fix run can apply fewer edits and ask more questions.
  • The structured result of project-review-codebase had no rules dimension. The rules dimension ran, but the schema had no rules value, so its findings came back under another dimension and the result had no rules verdict. findings[].dimension can now be rules, and dimension_verdicts can hold a rules key. The key is absent on a run with no rules file.
  • After a rebase merge, the local PR branch could stay behind. git branch -d refuses a branch whose commits were rewritten. The run now deletes it with -D after a rebase merge too, as after a squash merge.

Changed behavior worth knowing

  • worktree-merge stops 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-ship opens the PR against the documented branch, and worktree-merge then stops for that PR. Merge and clean up such a PR by hand.
  • worktree-merge no 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-merge can 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-merge moves the head of a PR that is behind its base, with gh pr update-branch, and asks no question first.
  • worktree-merge may 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-merge has two new early checks. gh auth status must succeed. And where gh pr checks prints no 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-ship opens 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 revier skill pre-approves two more commands: revier agent read and revier 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 prompt and revier agent send-keys are 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-codebase result sees a fourth dimension value, rules. Code that handles only consistency, structure and architecture must accept it, and must not require the rules verdict.

Full Changelog: v1.42.0...v1.43.0