Rpa_Skills/skills/rpa-bot-handoff/SKILL.md

name, description

name

description

rpa-bot-handoff

Writes "<Project Name> Handover SOP" - a short PDF (at most 4 pages) that ops keeps open while running an RPA bot - how to run it, what shows where, the result, what to do when something goes wrong, and who to email (developer in To, manager in CC). Reads the code, never runs the bot. Use when the user asks to "hand over a bot", "document a bot for ops", "write a handover doc", "handover SOP", "ops guide", "runbook" or "operator guide".

RPA bot handoff

Make <Project Name> Handover SOP: one PDF, at most 4 pages, that ops keeps open while they run the bot. Plain words, no code.

1. Scan. One read-only subagent (never run the bot; no patient data, client names or passwords in its report). Ask for exact on-screen text with file:line: how to start (URL or shortcut, sign-in, Run button, what a new run does to old results), what shows where during a run, every timeout and retry, how a run ends and where the result is, every message ops can see, alerts, how to stop.
2. Ask once: the developer's email (To), the manager's name and email (CC), and where ops runs it if unclear.
3. Write HANDOVER-SOP.md in this shape:

# <Project Name> Handover SOP
Version <x> · <date> · Problems: email <developer>, CC <manager> (section 5)
<one line: what the bot does, from which app, what it produces>
## 1. How to run
Numbered steps: URL or shortcut, sign in, the Run button. Then "Before you click": what a new run does to the old results; one run at a time.
## 2. What you see while it runs
| Where on the screen | What it shows |   then a normal run in one line
| Step | The bot waits at most | Then |      then "Step in only when: ..."
## 3. Result
Good run / Needs a look (call out a misleading "Finished" or green). Where the result is.
| Status | Meaning | What you do |
## 4. When something goes wrong
How it shows (colour, list, column). Then:
| ID | Message you see | What it means | What you do |   E01, E02 ... one row per message
Don't: (at most 3, with a short reason). To stop it: (the one right way).
## 5. Email us
Email <developer> with <manager name> (<manager email>) in CC when section 4 says "email us". Answer: <time>.
To: <developer>
CC: <manager>
Subject: <Project Name> - E<number> - <date>
Run started / Error: E<number> - <message> / Where / What I did / Attached: screenshot
Never send: passwords, patient data, result files that hold patient data.

4. Make the PDF yourself: turn the SOP into one self-contained HTML page (A4, 1.8 cm margins, clean sans-serif 10.5 pt, bold headings, bordered tables with a shaded header row at 9.5 pt, the email block in a grey box, no page break inside a table row), then print it with headless Chrome or Edge (--headless --print-to-pdf) to <Project Name> Handover SOP.pdf. Look at every page. Over 4 pages: shorten cells, never drop a message.
5. Hand over the PDF. Problems for the dev team go in the chat (at most 5 lines), not in the SOP.

Rules

• Copy every label and message exactly from the code; variable parts in italics ("Couldn't download Location").
• Every wait is a number. Say plainly when the screen misleads.
• One row per message, one short line per cell.
• No file names, code, settings names, patient data, client names or passwords.

Don't miss: check each of these and cover every one that applies in section 3 or 4:

1. Setup missing: login, file, driver. Which message shows?
2. The app or portal is slow or changed: timeouts, "not found".
3. Names in the input or mapping don't match the target app.
4. Says done but isn't, or did it but says failed: tell ops to check before re-running.
5. Stuck, can't be stopped, or blocks the next run.
6. The cause is only in a raw log, or there is no alert.