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