work-review

Take one issue that an implementer pushed and review it — the stateless review-unit behind work-review-queue, and the deliberate counterweight to work-implement. A different agent, with fresh context: it did not build this and carries no "it works because I wrote it" bias. State lives in the issue's lifecycle label; the review is read-only and idempotent, so a crashed review just re-runs.

This skill is the review half of the two-loop workflow. It never implements, edits, commits, or merges — its only outputs are a verdict (a label move plus a comment): done, changes-requested, needs human, or blocked.

Opted out? If the repo config sets work to false, all work-* skills are disabled — stop and tell the user they are turned off in .tituskirch-skills.json. Check .work == false on the resolved config before any action. A missing jq or config exits non-zero too, so a pass is not evidence the config was read.

Workflow

1. Load config & resolve tracker

Resolve .tituskirch-skills.json via templates/resolve-config.sh, never by reading the raw file (REFERENCE.md states how, missing jq included); the work.* section holds tracker, labels, work.review.maxRounds (default 3) and work.feedback — where the verdict's comment is written (feedback recipes; it defaults from work.branch, the full rule being Feedback destination in work-implement's REFERENCE). Resolve the tracker (work.tracker, falling back to issue.tracker); reuse the issue catalog cache. Config + mechanics: REFERENCE.md.

2. Resolve the target issue

• Explicit — an id/number/key (/work-review 42, ENG-123).
• Self-select — none given → the selection query: the single highest-priority issue in reviewRequested. None → say so and stop.