UX walk auto-fires on every UI pull request

Status: Delivered
CAS: CAS-2734
Delivered: 2026-05-14
PRs: #726

What’s new

When an engineer requests review on a PR that includes screenshots (--screens), the UX Specialist (Eivind) is now automatically added as a reviewer — without the engineer having to name Eivind explicitly. Previously, UX walk was triggered only when the engineer remembered to include Eivind in the request; now the handoff script enforces it. No UI PR can proceed to merge review without a UX walk.

How to use it

For engineers: When you call request-review.sh, pass --screens if your PR touches any component or page file. The script will automatically add UX Specialist to the reviewer list if it isn’t already there. You don’t need to change any other step.

.agents/skills/casaconomy-task-worktree/scripts/request-review.sh \
  --pr 731 \
  --reviewer "Master of Craft" \
  --screens

Eivind receives the wake, walks the affected routes on the iOS Simulator, and posts a PASS / FIND list / FAILED-TO-WALK verdict as a PR comment.

For the CTO: Approving a UI PR without an Eivind verdict is a protocol breach. The review-protocol skill documents this explicitly — check for the UX walk comment before approving.

What changed under the hood

.agents/skills/casaconomy-task-worktree/scripts/request-review.sh — Added --screens flag; when set, UX Specialist is appended to the reviewer list automatically if not already present. Docs updated to reflect that CTO-only explicit reviewer is the norm; Eivind is implicit.
.agents/skills/casaconomy-task-worktree/SKILL.md — Examples updated to show the --screens convention and clarify that Eivind is auto-added, not manual.

Why we built it

Every significant UI/UX regression caught during the iOS arc (stacked FABs, dead bands, leftover step-list, overwhelming onboarding) was found by the regent on a real device after a TestFlight build shipped — not during review. Eivind had already demonstrated in CAS-2390 that a structured UX walk catches these issues reliably: 12 issues in a single pass. The problem was that the walk only happened when someone remembered to ask for it. Auto-firing on --screens removes the memory dependency and makes the walk structural, not optional.

Known limitations / follow-on work

The gate is enforced at script level, not at GitHub Actions level. An engineer who bypasses the script and opens a PR manually won’t trigger the auto-add.
The full Eivind skill (simulator build, scripted checklist, baseline diff against docs/ux-baseline/) is the follow-on scope; this CAS delivers the auto-fire wiring. Eivind’s walk itself is manual/skill-guided for now.
Future work: GitHub Actions trigger that fires the walk automatically when certain path globs change, without requiring --screens to be passed.