rpa-bot-handoff: one short Handover SOP (max 4 pages) instead of the 11-section guide

The first real handover (MEK Charge Reconciliation) came out at 9 pages.
Ops want it short: which URL to open and what to click, what shows where
after the click, what to do when an exception comes, and how to email us.

- Output is "<Project Name> Handover SOP" (HANDOVER-SOP.md + .docx) with
  5 sections: how to run, what you see while it runs, result, when
  something goes wrong, email us. HANDOVER-DEV.md is dropped; dev-team
  findings go in the chat.
- At most ~1,400 words; to_docx.py prints the word count and flags overflow,
  and renders *italic* for the variable parts of messages.
- Every quoted message, label and URL is checked against the code. The SOP
  must say what clicking Run again does to the data.
- One scan subagent; failure classes stay as a scan checklist.
- Tebra reference rewritten in the SOP format; test, README, glossary
  updated; ADR-0005 supersedes ADR-0004.

The handoff eval runner (tests/evals/run_handoff_eval.py) still grades an
older 13-section format and was already out of date; not touched here.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

skills/rpa-bot-handoff/README.md

@@ -1,41 +1,32 @@
 # rpa-bot-handoff
 
-A Claude skill that writes the **ops guide** for an RPA bot that is being handed over to an ops team.
+A Claude skill that writes a short **Handover SOP** for an RPA bot that is being handed over to an ops team.
 
 ## What you get
-**`HANDOVER.md`**: the ops guide, in plain words, for operators who don't read code:
-1. What this bot does
-2. Where is what: which tab, screen, file or folder shows what
-3. How to run: checklist and steps with the real button names
-4. How long to wait at each step, in seconds or minutes, and when to step in
-5. After the run: what each ending means, where the report is
-6. How to see an exception
-7. Exception list: message → where → meaning → what you do → wait or call us
-8. How you will know something went wrong
-9. How to tell the dev team, with a ready message template
-10. Don'ts, and the right way to stop the bot
-11. Issues seen before
+**`<Project Name> Handover SOP.docx`** (and `HANDOVER-SOP.md`): at most 4 pages, in plain words, for operators who don't read code:
+1. How to run: the URL or shortcut, what to click, and what a new click does to the previous results
+2. What you see while it runs: what shows where, a normal run, how long each step may take
+3. Result: how a good run ends, where the report is, what each status means
+4. When something goes wrong: how it shows, each message (E01, E02...) with what to do, the don'ts, how to stop it
+5. Email us: the address, when to email, and the email to copy
 
-**`HANDOVER.docx`**: the same ops guide as a Word document. This is what you give the ops team at the end.
-
-**`HANDOVER-DEV.md`**: for developers. The check against 12 failure classes learned from Tebra Auto Post, the gaps to fix before handover (file:line), and the incident list.
+Problems the scan finds for the dev team are listed in the chat, not in the SOP.
 
 ## Install
 Copy this folder to `~/.claude/skills/rpa-bot-handoff/`.
 
 ## Use
-In your bot project, ask Claude: *"write the ops guide for this bot"* or *"document this bot for handover"*. The skill:
-1. Scans the code and history with subagents. It never runs the bot.
-2. Asks up to three things: how ops reaches the dev team, what ops can open, and any unclear statuses.
-3. Writes both files and checks them.
-4. Turns the ops guide into `HANDOVER.docx` and gives you that document to hand to ops.
+In your bot project, ask Claude: *"write the handover SOP for this bot"* or *"document this bot for handover"*. The skill:
+1. Scans the code with a subagent. It never runs the bot.
+2. Asks up to two things: the email group ops writes to, and where ops runs the bot.
+3. Writes the SOP, checks every quoted message and label against the code, and keeps it under 1,400 words.
+4. Turns it into the Word file you give to ops.
 
 ## Files
 | File | What it is |
 |---|---|
 | `SKILL.md` | Steps Claude follows |
-| `templates/HANDOVER.md` | The ops guide skeleton |
-| `templates/HANDOVER-DEV.md` | The dev notes skeleton |
-| `templates/failure-classes.md` | 12 failure classes from Tebra's first months with ops |
-| `templates/reference/tebra-auto-post.md` | Both files filled in for Tebra, scrubbed |
-| `templates/to_docx.py` | Turns `HANDOVER.md` into `HANDOVER.docx` (`--selfcheck` tests it) |
+| `templates/HANDOVER-SOP.md` | The SOP skeleton |
+| `templates/failure-classes.md` | 12 failure classes from Tebra's first months with ops, used as a scan checklist |
+| `templates/reference/tebra-auto-post.md` | The SOP filled in for Tebra, scrubbed |
+| `templates/to_docx.py` | Turns the SOP into Word and prints the word count (`--selfcheck` tests it) |