Route pre-MR review through the work account

user/agents/skills/ticket/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ticket
-description: End-to-end Jira ticket workflow — fetch a ticket into .claude/docs/epics/, write a plan, implement it with clean commits, run pre-mr-review to convergence, and write the MR doc. Use when the user gives you a Jira ticket key (e.g. KACP-11111) to work, or asks to plan/implement/wrap up a ticket.
+description: End-to-end Jira ticket workflow — fetch a ticket into .claude/docs/epics/, write a plan, implement it with clean commits, drive the pre-mr-review audit to convergence (the user runs it themselves from their work Claude account), and write the MR doc. Use when the user gives you a Jira ticket key (e.g. KACP-11111) to work, or asks to plan/implement/wrap up a ticket.
 disable-model-invocation: true
 ---
 
@@ -372,7 +372,7 @@ place from the start.
      - Proceed to implementing the existing `plan.md` as-is (they reviewed and approved it)
      - Resume implementation (some plan steps are already checked off / some commits
        already exist on the ticket branch — pick up from the first unchecked step)
-     - Run `pre-mr-review` now (implementation looks done, just need the audit + MR doc)
+     - Move to the pre-mr-review stage (implementation looks done, just need the audit + MR doc; the user runs the audit from their work account, see Phase 2 step 7)
      Route to **Phase 1** or **Phase 2** accordingly.
    - **Both `plan.md` and `mr.md` exist** — this ticket looks finished. Tell the user
      `mr.md` already exists at its path and ask whether they want you to refresh it
@@ -620,8 +620,8 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved
    Order matters and is not just convenience. `pre-mr-review`'s output is a readiness
    verdict that gets pasted verbatim into `mr.md`. Anything that runs after it
    invalidates that verdict by construction, and you end up rerunning it and rewriting
-   the handoff. Review first, fix, commit, and only then run `pre-mr-review` over the
+   the handoff. Review first, fix, commit, and only then have the user
-   final tree.
+   run `pre-mr-review` over the final tree.
 
    - **Skip this step for genuinely trivial changes**: a copy tweak, a styling fix, a
      one line correction with no logic in it. Run it whenever the change adds or
@@ -671,11 +671,25 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved
    in the current repo). If it doesn't, stop here, tell the user implementation and
    local verification are done but this repo has no `pre-mr-review` skill to run, and
    let them decide how to proceed.
-7. Invoke the `pre-mr-review` skill. Read its verdict.
+7. **Do NOT invoke the `pre-mr-review` skill yourself.** The org asks that this
+   review run from the developer's separate work Claude account, so the audit on
+   record must come from there, not from this session. Instead:
+   1. Tell the user the branch is ready for its pre-mr-review and ask them to run
+      `/pre-mr-review` from their work account, then let you know when it has
+      finished. Stop and wait, this is a hard gate.
+   2. When they say it ran, read the audit and handoff files it wrote under
+      `.claude/audits/pre-mr/` (the context script from the repo's `pre-mr-review`
+      skill prints the exact paths). Check the `last_reviewed_head` in the audit
+      header matches the current HEAD; if the branch moved after their run, say so
+      and ask them to rerun before acting on a stale audit.
+   3. Read the verdict.
       - **Ready to Open MR**: continue to step 8.
-   - **Almost Ready / Not Ready Yet**: fix what it flagged (each meaningful fix as its
+      - **Almost Ready / Not Ready Yet**: fix what it flagged (each meaningful fix
-     own commit), then invoke `pre-mr-review` again. Repeat until the verdict is Ready
+        as its own commit), then ask the user to rerun the review from the work
-     to Open MR. Don't write `mr.md` before that verdict is reached.
+        account and wait again. Repeat until the verdict is Ready to Open MR. Don't
+        write `mr.md` before that verdict is reached.
+   Findings that need no code change (mentions, disclosures) get addressed in
+   `mr.md`'s Additional Notes or the Jira fields as usual.
 8. Read `~/.agents/skills/ticket/templates/mr.md` — this is the org's MR template,
    copied into this skill so it still works even though the original
    `.claude/docs/mr/template.md` no longer exists in the command-center repo. `mr.md`
@@ -707,9 +721,9 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved
      the audit's own words, not a retelling of them. Concretely:
 
      - Never hand-write a handoff section, and never edit one in place. If it is
-       wrong, thin, or stale, fix the handoff file by rerunning `/pre-mr-review`,
+       wrong, thin, or stale, ask the user to rerun `/pre-mr-review` from their work
-       then re-paste.
+       account to regenerate the handoff file, then re-paste.
-     - On EVERY rerun, replace the whole existing handoff block with the whole
+     - On EVERY rerun of theirs, replace the whole existing handoff block with the whole
        regenerated one. Do not patch the copy sitting in `mr.md` to match the new
        head — that is how the two silently diverge, and the version the reviewer
        reads stops being the version the audit actually produced.