diff --git a/user/agents/skills/ticket/SKILL.md b/user/agents/skills/ticket/SKILL.md
index fcef3fe..269f803 100644
--- a/user/agents/skills/ticket/SKILL.md
+++ b/user/agents/skills/ticket/SKILL.md
@@ -751,6 +751,35 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved
         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.
+
+   **The verdict is the gate and it is not negotiable.** Ready to Open MR is what
+   goes on record with the Lead, so never reason your way past it because the
+   remaining items look harmless. That judgment is not yours to make.
+
+   **Don't confuse the verdict with the handoff's recommendation.** They are
+   different fields in different files for different readers. The audit's
+   `Verdict` says whether the branch is ready to become an MR, and that is the
+   gate. The handoff's `Recommendation` (`Merge`, `Merge after conditions`) is
+   advice to the maintainer about merging it, and `Merge after conditions` is
+   normal and expected at a Ready verdict. Never treat the recommendation as a
+   blocker or report it as one.
+
+   **Reruns converge by giving the audit more, not by repeating the command.**
+   When a rerun is needed, the user is running it, so every rerun costs them.
+   Make each one count:
+   - **Feed it context on the first run.** It reviews the diff, and left alone it
+     re-derives intent from the branch name and re-raises decisions that are
+     already settled. Ask the user to point it at the ticket's
+     `resources/ticket.md` and `plan.md`. This is the cheapest thing that reduces
+     repeat findings.
+   - **Answer its decisions explicitly in the rerun.** When it parks a finding
+     under "Decide before opening", write the decision and its reasoning into the
+     prompt for the next run, so it can reclassify rather than re-ask. A silent
+     rerun on an unchanged diff re-asks the same question.
+   - **Say so when it finds new things in unchanged code.** That means the earlier
+     run was an incomplete pass, not that the branch got worse. Tell the user
+     plainly, because it is the audit's problem to fix and it changes how much
+     weight the next run deserves.
 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`
@@ -775,7 +804,9 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved
      verified" if you actually ran a build and it passed).
    - Replace `<!-- Paste the Pre-MR handoff here -->` with the exact content of the
      latest `pre-mr-review` handoff file (the one with verdict Ready to Open MR) —
-     paste it verbatim, don't summarize it.
+     paste it verbatim, don't summarize it. Its `Recommendation` line is the
+     audit's advice to the maintainer and is left exactly as written, including
+     `Merge after conditions`.
 
      The handoff section of `mr.md` is GENERATED OUTPUT, not something you author.
      It is the block that states whether the branch is ready to merge, so it must be