v1.47.0

This release cuts the text the plugins put into every session, and the worktree skills now let the project's own merge and review rules win. It also fixes six problems from the v1.46.0 session review.

Less text in every session

A measurement over 30 days of transcripts showed that the plugins' text cost about 440M token-reads. Each token in a skill listing entry costs much more than a token in a skill body, because every context loads the listing, also in subagents. Each cut below was checked against earlier failures, and none of the cut text closed a failure seen in a session.

• challenge:grill is user-invoked. It had 0 model invocations in 5 review runs. Run it as /challenge:grill.
• Shorter listing entries for html-visualize-ask, writing-project-docs, writing-skills, revier, tasks-core, project-review-change, worktree-review and the project-reviewer agent. The seven skills among them were each driven once from a typical prompt after the cut, and each loaded.
• Repeated text removed from the project-reviewer agent (it now gets its rules from its caller), writing-project-docs, project-review-change and the shared rules-conformance.md.

worktree-flow skills are shorter, and project rules come first

• Project rules win. worktree-merge and worktree-review now open with one line: the project's own rules for a merge or a review win over the skill. Before, in another project, agents under these skills skipped the merge and review docs that the project's AGENTS.md routes to.
• Shorter skills. worktree-merge went from 1296 to 689 words, and worktree-review from 1481 to 1015. worktree-ship went from 9819 to 3981 characters, and its PR body template from 3814 to 1017. The skills keep the gotchas from earlier runs: the upstream lookup, the re-check of the merge state after CI, the merge method of past PRs, gitignored files lost when a worktree is removed, the install after a dependency change, and the Review line contract between worktree-ship and worktree-review.
• The reviewed-head check moves to worktree-review. worktree-ship still resumes, and leaves the check for an already-reviewed head to worktree-review.
• Open questions go to you. worktree-review puts the open questions from the reviews to you, goes on without an answer, and keeps them for the Review line and the report.

Fixes

• The worktree guard refused a probe in the scratchpad. A command such as W=/tmp/probe && git worktree add $W HEAD was refused as a persistent worktree. The guard now takes the value of $W from the last assignment before the add on the same line. A variable that is not set on that line is still refused.
• A failed label write showed as "0 usable sessions" in project-review-docs. The workflow now compares the counts that the agents report with the history it writes, and reports a mismatch as a failed stage. The label agent now writes with the Write tool.
• project-review-docs got no standard directory when the standard skill was already loaded. The Skill call answers "already loaded" and prints no base directory. Step 2 now takes the line from the earlier load.
• Worktree isolation refused step 3 of project-review-docs. The step was one compound shell block. It is now three plain commands.
• The rules review's /tasks:tasks-create suggestion was lost. worktree-review and worktree-ship now carry it into the report.
• revier did not trigger for "other Claude instances in this project". It now has this trigger phrase.

Changed behavior worth knowing

• challenge:grill no longer starts from prose such as "stress-test this plan". Use /challenge:grill.
• A skill with a shorter listing entry can start less often from prose. Use its slash command where it does not start.
• worktree-merge and worktree-review follow your project's merge and review docs where those differ from the skill.
• The worktree guard now allows git worktree add $VAR where VAR is set to a /tmp or scratchpad path on the same line.

Full Changelog: v1.46.0...v1.47.0

v1.46.0

Every skill-to-skill hand-off is now an explicit Skill tool call that also runs when the target skill loaded earlier in the session. A second run of a skill now runs all its steps again, and does not repeat a shortened version from memory. worktree-review now picks the code-review effort from what the PR changes. worktree-merge now installs changed dependencies in the main checkout.

Skills reload the skills they hand off to

Session transcripts showed that a skill reached a second time in one session was often replayed from memory, and steps were dropped. An example is a second worktree-ship run that skipped worktree-review and project-review-change. A hand-off behind a vague condition never ran: project-review-session loaded its target 0 times in 14 runs.

Each hand-off in tasks, worktree-flow, project-review, project-auto-work, project-execute and html-visualization now reads "Call the Skill tool with <skill>, even where it loaded earlier in this session", with a condition the agent can test. A hand-off to a skill that only the user can start now names the /command for the user to run. The instruction-writing:writing-skills rubric has a new hand-off rule under Invocation. The project-doc standard and its examples (instruction-writing:writing-project-docs) teach the same form, so new skills and new project docs follow it.

worktree-review sizes the code review to the change

• Effort from the change. Before, the code review ran at medium for docs-only paths and at xhigh for all other paths. Now the model chooses from what the PR changes. Text that only people read, such as release notes, gets medium or lower. Code, configuration, tests, agent instructions, and text that a program decides on, such as a version bump, get xhigh. Where it is unclear, the effort is xhigh. Agent instructions such as AGENTS.md, CLAUDE.md and docs/ guides now get xhigh.
• Rules review runs to its end. worktree-review calls project-review-change through the Skill tool and follows it to its last step. It no longer starts the reviewer agent with its own prompt.
• Suggested rule additions are kept. The Review line of the PR body and the reports of worktree-review and worktree-ship now list the rule additions that the rules review suggests. Before, they could be lost when the context was compacted.

worktree-merge installs changed dependencies

Before, after worktree-merge, the next build failed when the PR changed dependencies, because the install ran only in the worktree that the merge removes. Now, after the pull, worktree-merge looks at the merged files. Where they hold a dependency input (a manifest, lockfile or tool-version pin), it runs the install part of the project's documented setup in the main checkout. It runs nothing where the setup has no separate install part, or where HEAD does not hold the merge (a failed pull, or another branch checked out). It reports the changed inputs.

Fixes

• worktree-ship stray-work Move out stopped at git add. This occurred in every repo that gitignores .claude/ or .claude/worktrees. The main checkout stayed on worktree-ship-stray/<name> with no transport commit. Cause: git refuses a pathspec whose literal prefix is ignored, and this includes exclude pathspecs. The exclude is now written as [.]claude/worktrees, which has an empty literal prefix. It was tested on git 2.7 to 2.55 and on 10 repos with different ignore setups.
• A repo hook could rename the transport commit. --no-verify does not skip the prepare-commit-msg or post-commit hooks, so a hook could rewrite the subject that Bring in searches for. The transport commit now runs with -c core.hooksPath=/dev/null.

Changed behavior worth knowing

• A skill that hands off now loads the target skill again each time, also where it loaded earlier in the session.
• A finding that belongs to another review, or a request that fits another html-visualization mode, now gives you the /command to run. The skill no longer starts that skill itself.
• worktree-merge can now run your project's install command in the main checkout after a merge.
• worktree-review runs the code review at xhigh on more PRs than before, including PRs that change only agent instructions.
• worktree-ship reports each part of a change that it cannot drive, with the reason and what you must check by hand.

Full Changelog: v1.45.0...v1.46.0

v1.45.0

An agent that implements a tracker issue now sets the issue to in progress before the first edit. tasks-core and worktree-ship carry the rule.

The change follows from a review of the sessions on one machine. In 19 sessions that agents read in full, 67 implemented issues never got the status and 3 got it after the work started. Only tasks-start carried the rule, and most of the work started from tasks-core or worktree-ship.

An implemented issue shows as in progress

tasks-core printed the menu of taskmgr guide and no rule. taskmgr guide progress shows the status command as an example and does not say when to run it. The skill now has a section of its own:

• Before the first edit that implements an issue, run taskmgr update <id> --status in_progress.
• A session that hands the implementation to a subagent or a workflow sets the status itself, before the hand-off. In the reviewed sessions, 34 of the 67 issues were implemented by a subagent or a workflow agent whose prompt named no status step.

The rule binds implementation only. A session that files, grooms or repairs the body of an issue leaves its status as it is.

worktree-ship marks the issues a change implements

Step 3 of worktree-ship now marks each tracker issue that the change implements, and that is not started, as in progress. It does this before the first edit, and before a subagent or a workflow gets the work.

• Where the tracker is taskmgr and tasks:tasks-core is available, the run loads that skill for the command.
• Where the tracker has no in-progress status, or the session cannot set it, the run marks nothing. The report of step 8 names each such issue with the reason.
• An issue that is in progress, or further on, is left as it is. A resumed run does not set back a closed issue.

worktree-flow does not depend on tasks: the step works on each tracker, and uses tasks-core only where it is installed.

Changed behavior worth knowing

• A session that implements a taskmgr issue writes a status to the tracker. The issue leaves taskmgr ready and shows under "In progress" on /tasks-board.
• Nothing sets the status back. worktree-merge does not touch the tracker. An issue of an abandoned change stays in_progress until you close it or set it to open. Before this release it stayed open.
• A workflow that implements several issues gets them all marked at its start. If the workflow stops early, the issues it did not reach stay in_progress.
• The status records no owner. A second session that marks the same issue gets no error.
• tasks-core must load for its rule to apply. A prompt that names an issue id and no tracker word may not load the skill. worktree-ship covers that case with its own step.

The worktree-ship step was not run end to end before this release. The tasks-core rule was: in three headless runs on a scratch store, the agent set the status before the edit.

Full Changelog: v1.44.0...v1.45.0

v1.44.0

worktree-review now picks the effort of the code review from what the PR changes: medium for a PR that holds project documentation only, xhigh for all others. The rules review no longer builds a finding on a general quality rule.

Both changes follow from the timing and token analysis of 86 ship runs. The code review is 45% of the cost of a run, and a quarter of the findings of the rules review were correctness or simplification points that the code review reports anyway.

A docs-only PR gets a lighter code review

worktree-review ran code-review xhigh --fix on every PR. It now reads the paths of the PR with gh pr diff <pr-number> --name-only and selects the effort:

• medium, where every path is project documentation: AGENTS.md, CLAUDE.md or README.md at the repository root, or a Markdown file under docs/ at that root.
• xhigh, for every other PR, and where the command fails.

The run reads the paths after the rules review and the push of its fix, because that fix can add a path. The Review line of the PR body names the effort that ran.

The list of documentation paths is narrow on purpose. A SKILL.md is not project documentation, so a skill change keeps xhigh. So does a README.md or a docs/ directory below the root, a file under the root docs/ that is not Markdown, and a CONTRIBUTING.md.

One limit: gh pr diff --name-only prints only the new path of a renamed file. A PR that moves a file into the root docs/ and changes nothing else gets medium.

worktree-ship runs worktree-review, so it gets the same rule.

The rules review leaves general quality to the code review

A rules review reported bugs, duplicates and simpler forms as rule violations where the project has a general rule such as "code must be correct" or "keep it simple". The code review reports the same points, so they came twice.

A finding now needs a rule that names the thing the change got wrong. A rule that names no specific thing backs no finding. The review names such a defect in one line, as routed to the code review, and the defect does not change the verdict.

The rule is in the shared rules-conformance.md, so it applies to project-review-change and to the rules dimension of project-review-codebase.

No rules review of a real change with such a defect was run before this release. The effect on the number of findings is not measured.

Changed behavior worth knowing

• A docs-only PR gets code-review medium, not xhigh. This applies to each project that runs worktree-review or worktree-ship. To get the deeper review on such a PR, run /code-review xhigh --fix <pr-number> yourself.
• A rules review reports fewer findings. A bug, a duplicate or a simpler form that only a general rule covers is one line in the report and has no effect on the verdict. With --fix, no edit is applied for it.
• Where no code review follows the rules review, nothing reports such a defect in full. This is the case for project-review-change run by itself and for project-review-codebase. Run /code-review to get it.
• The Review line of a PR body names the effort: code-review medium --fix or code-review xhigh --fix. A tool that matches the literal text code-review xhigh --fix must accept the two forms.

Full Changelog: v1.43.0...v1.44.0

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 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

v1.42.0

The revier guard now lets a session add an agent tab with revier agent new --no-focus. It needs revier 0.14.0 or later, which has the flag.

A session can add an agent that takes no focus

revier 0.14.0 has revier agent new --no-focus: the tab opens, nothing is focused or raised, and the command prints the address of the new agent, <project>:<panel>. The guard of the revier plugin now permits that command, so a session can add an agent and then prompt it, with no command for the user to run.

The guard permits the flag in these conditions:

• The command is revier agent new. open, go, popup, shutdown, agent focus, shell new and session restore have no such flag and stay denied, also with --no-focus in their arguments.
• The flag is the whole word --no-focus, in the arguments of that same command. --no-focus=false, a flag in a comment, and a flag after ;, & or | do not count.

revier agent new with no flag stays denied.

The skill text of the plugin does not name the flag yet. It still says that agent new takes the focus, so a session uses the flag only when you tell it to.

Fixes

• A focus mover inside a command substitution passed the guard. A command such as revier session restore --dry-run $(revier open demo) ran, and revier open took the focus. The cause: a flag that makes a command safe cleared everything up to the next ;, & or |. The guard now judges a command substitution in the arguments on its own.

Changed behavior worth knowing

• agent new --no-focus needs an open workspace. For a project that is not open, revier refuses the command, and revier open stays denied.
• Only the spelling --no-focus is permitted. The guard denies -no-focus and --no-focus=true, although revier accepts them.
• The guard stops accidents, not intent. One form passes although revier takes the focus: revier agent new --resume $id --no-focus with $id empty, where revier reads the flag as the id. Quote the variable, or put --no-focus first.

Full Changelog: v1.41.0...v1.42.0

v1.41.0

The review of a PR is now its own skill, /worktree-flow:worktree-review. An agent can start it, and a project doc names this one command as its review step.

One command for the full review of a PR

/worktree-flow:worktree-review [pr-number] runs the two reviews on a PR and pushes what they fix:

1. It checks the PR: open, not from a fork, its head in this checkout, the tree clean.
2. It runs each gate of the project on the PR's head. A review reads a change that works, so the run stops where a gate is red.
3. It runs the rules review (project-review:project-review-change --fix), then the code review (code-review xhigh --fix). After each review that fixed something, it runs the gates, repeats the drives, commits, and pushes to the PR's head branch.
4. It writes the Review line into the PR body, with the head commit that was reviewed.

With no argument, it takes the PR that the current branch was pushed to. On a head that the Review line names already, the run only reports.

Before this release the two reviews were step 7 of /worktree-flow:worktree-ship, which only the user can start. A project doc that wanted this review had to name each review with its level and flag. worktree-ship now invokes the new skill at step 7, and the example CHANGE-WORKFLOW.md of the doc standard names the one command.

Where the project-review plugin is not installed, the rules review is reported as skipped, never as passed. A later run with the plugin installed runs the rules review that is missing.

Changed behavior worth knowing

• The push names its target. The fixes go to the PR's head branch with git push <remote> HEAD:<headRefName>. Where the remote rejects the push, the run stops and keeps the commit local.
• No push to a fork. The review stops for a PR from a fork.
• A stopped review is reported as such. Where the review stops before it records its result, worktree-ship reports the PR as not reviewed, with the reason, and does not name the merge as the next step.
• The Review line has a new owner. worktree-review writes it, and brings the Gate and Driven lines up to date where it ran them again. The PR body template of worktree-ship no longer holds that line.
• Project docs. A CHANGE-WORKFLOW.md that names code-review xhigh --fix or project-review-change --fix as its review step can name /worktree-flow:worktree-review <pr> in their place.

Full Changelog: v1.40.0...v1.41.0

v1.40.0

The tasks plugin now needs taskmgr v0.11.0 or later. Its skills use the tree and create --from commands of that version, and /tasks-board no longer draws one issue in two sections.

The tasks skills use taskmgr tree and create --from

• /tasks:tasks-overview starts its report from taskmgr tree and takes the titles of the blockers from taskmgr blocked. An issue ID as the argument selects the subtree of that issue. Any other scope is a filter. With no argument, the report covers everything open.
• /tasks:tasks-create files the full set of tasks in one call: taskmgr create --from -. Where taskmgr refuses one entry, it files none of the set, so a refused run leaves no partial set in the tracker. The set goes in on standard input, so no file stays behind.

Fixes

• /tasks-board drew a started issue that waits on a blocker two times, under In progress and under Blocked. taskmgr lists such an issue in the two views, and the board drew each row it received. The board now draws the issue one time, under In progress, with its blockers named. The count of the Blocked section no longer includes it.

Changed behavior worth knowing

• taskmgr v0.11.0 is the minimum. tasks:tasks-core now checks for the tree command before it prints the guide. With an older taskmgr, each tasks skill stops with a STOP line and points to the troubleshooting reference, the same as with no taskmgr installed. taskmgr version shows what you have. The install commands in that reference also do the upgrade.
• Upgrade taskmgr before you update the plugin, or the tasks skills stop until you do.

Full Changelog: v1.39.0...v1.40.0

v1.39.0

/worktree-flow:worktree-ship now runs two reviews on each PR, and it takes work left on the main checkout into the worktree. The project-doc standard gives coding rules and review rules a file each, and project-review-change can apply the fixes it finds.

Coding rules and review rules in two files

The project-doc standard of instruction-writing now splits the rules of a project by the job that reads them.

• docs/CODING.md holds what a change needs in order to work: build and code-generation commands, where code goes, and which mechanism of the repository a change must use.
• docs/REVIEWING.md holds the quality rules: how finished code must look and what it must withstand. Each is a condition a reviewer can check on the diff.

The test for one rule: where the late fix is a rewrite, the rule belongs to CODING.md. Where a reviewer can apply it to the finished diff as a local edit, it belongs to REVIEWING.md. The standard has two contracts, an ownership table, and six worked examples for the split. project-exec-init writes its documents to the same split.

project-review-change --fix applies the settled fixes

/project-review:project-review-change [--fix] [pr-number|branch|path] reviews one change against the written rules of the project. The review is read-only, as before, and runs on the reviewer agent.

With --fix, the session then applies each action the reviewer tagged as settled, runs the checks of the review again, and reports each result. It leaves the result uncommitted. The open items stay questions for you.

--fix holds only for a subject that is checked out with a clean tree. For any other subject the run says so and goes on as a review without fixes.

worktree-ship reviews the rules, then the code

Step 7 of /worktree-flow:worktree-ship now runs two reviews on the PR, one after the other:

1. project-review:project-review-change --fix <pr>, which holds the change against the written rules of the project.
2. code-review xhigh --fix <pr>, which looks for defects in the code.

After each review that applied a fix, the run repeats the gates and the drive, commits, and pushes, so the second review reads the head the first one fixed. The Review line of the PR body records both results and the head commit.

The project-review plugin is optional. Where it is not installed, the run reports the rules review as skipped, never as passed.

worktree-ship takes stray work off the main checkout

A run that starts in the main checkout now looks for stray work there: uncommitted files, and commits the upstream of the branch lacks. Before, that work stayed on the default branch.

• With no argument, the stray work is the change. The run moves it into the new worktree without a question and leaves the main checkout clean and equal to its upstream.
• With an argument, the run shows the stray work and asks whether it belongs to the change. On "no" it leaves the work in place, ships the named change alone, and names the work in its report.
• The work travels on a branch the run owns, worktree-ship-stray/<worktree-name>. The uncommitted files ride on one transport commit, which the run takes apart again in the worktree.
• That branch is also the mark of a run that stopped in the middle of the move. A later run finds it and asks whether to continue the move.

The run resets the main checkout only once the tree is clean and the branch holds the old HEAD. The procedure is in references/stray-work.md of the skill.

The final report of the skill now names the next step: /worktree-flow:worktree-merge.

Fixes

• A test of the canonical-doc lists passed on a Python error. test-canonical-docs.sh read a value that no longer exists, and the assertion is removed.

Changed behavior worth knowing

• worktree-ship resets the default branch of the main checkout. Where that branch holds commits its upstream lacks, a run with no argument moves them to the worktree and runs git reset --hard @{upstream} there. The commits are on the worktree-ship-stray/ branch before the reset.
• Untracked files move too. With no argument, an untracked file that no ignore rule covers goes into the worktree and into the PR. Start the run with an argument, or ignore the file, where you want it left alone.
• A stopped move asks on every later run. While a worktree-ship-stray/* branch exists, each run from the main checkout asks whether to continue it. Where you decline, the run stops; delete the branch to end that.
• Stale base. Where the local default branch is behind its upstream and holds stray work, the worktree starts from that older base. Pull first to prevent a conflict in the PR.
• worktree-ship takes longer. The rules review adds one agent run, and one more round of gates where it applies a fix.
• Projects on the doc standard: four kinds of rules leave CODING.md for REVIEWING.md. project-review-docs reports a rule in the wrong file as a finding.

Full Changelog: v1.38.0...v1.39.0

v1.38.0

project-review gains /project-review-session, a retrospective on one coding session that lists what to improve in the environment of the coding agent. The revier skill can now answer which projects you worked in over the last days.

A retrospective on one coding session

/project-review:project-review-session [session] reads one session and lists candidates for improvement, in order of severity. With no argument, it reviews the current session. It applies nothing: you pick the candidate to apply.

• The subject is the environment of the agent, not the code the session wrote. The categories are navigation, automated checks, coding standards, the size of AGENTS.md, tool economy, instructions that change nothing, and access to information.
• Each candidate quotes the moment of the session that shows it, and names the file it changes by absolute path.
• The report then lists the categories with no finding, and each part of the session that was not read.
• The run reads every message you typed and every failed tool result in full. A shortened extract of the transcript is only an index to find records.
• The session can come from another project. The run reads the checkout that session ran in, not the current directory.
• Each run writes its extracts into a directory of its own and prints the path, so two retrospectives can run at the same time.

A mechanical rule violation gets a deterministic check (a linter rule, a pre-commit hook, a CI job), not a new line in a document. A repo with no pre-commit hook and no CI check is a finding by itself.

The skill is user-invoked only; the model does not start it. The text is adapted from the retro skill of mattpocock/skills (MIT), and NOTICE.md in the plugin records each change from it. The other three project-review skills now name it in "Not covered".

Ask revier which projects you worked in

revier list shows only what is open now. The revier skill now also answers a question about the last days, for example "which projects did I work on this week?". It needs revier 0.13.0 or later, which added revier events.

• The answer is one row per project, most used first: the project with more days of activity, then the one with more go presses.
• A project that only had an idle agent open is reported apart, as open and not as worked in.
• A link and the project it points to on a linked host are one row, under the name of the link.
• Each row lists the conversations the agents held there, so a follow-up can find a transcript or run git and gh in the checkout.
• When a linked host gives no events, the answer says that the projects of that host are missing.

Fixes

None. The two fixes merged in this period apply to project-review-session, which is new in this release.

Changed behavior worth knowing

• The revier skill can trigger on a question about past work, such as "the projects I worked on". Its allowed tools now include revier events.
• Past use needs python3 on PATH and revier 0.13.0. Without python3 the skill stops and says so. An older revier has no events command, and the script fails with that message.
• /project-review-session appears in the slash-command list of each install of project-review. No other skill of the plugin changes its behaviour.

Full Changelog: v1.37.0...v1.38.0