Skills/Rpa_Skills
8
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

rpa-bot-handoff: short skill, MEK SOP as the model

Browse Source 
The skill itself read as too detailed. SKILL.md is now a short checklist
(460 words, was 1,321): 5 steps, 5 rules, and 6 one-line "don't miss"
checks that replace the 12 Tebra failure classes (failure-classes.md
removed). The MEK Charge Reconciliation SOP - the 3-page PDF ops liked -
replaces the Tebra example as the model (emails swapped for examples).
New test keeps SKILL.md under 500 words with 6 checks.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
VasanthandClaude Opus 5.5 committed 2026-10-28 17:28:23 +05:30
1 parent 0188de7403
commit 36e621b153
9 files changed
+137 -234
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

skills/rpa-bot-handoff/SKILL.md
+21 -62
View File
@@ -1,75 +1,34 @@
---
name: rpa-bot-handoff
description: Writes a short Handover SOP for an RPA bot that is being handed over to an ops/support team - "<Project Name> Handover SOP", at most 4 pages, as Markdown, Word and PDF. Scans the bot's code with a subagent (never runs it) and writes, in the operator's order - how to run it (which URL or shortcut, what to click), what shows where once it runs, where the result is and what it means, how a problem shows and what to do, and how to email the developer, with their manager in CC. Every label, message and wait is copied from the code. Use when the user asks to "hand over a bot", "document a bot for ops", "write a handover doc", "handover SOP", "ops guide", "runbook", "support doc", "operator guide" or "how ops should handle bot errors" for an RPA or automation project.
description: 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
Write one document in the bot's repo: **`<Project Name> Handover SOP`**, as `HANDOVER-SOP.md`, `<Project Name> Handover SOP.docx` and `<Project Name> Handover SOP.pdf`. The PDF is what ops gets.
Make **`<Project Name> Handover SOP`**: one PDF, at most 4 pages, that ops keeps open while they run the bot. `templates/reference/mek-charge-reconciliation.md` is the model: copy its length, layout and tone.
The reader is an **operator who does not read code**. The SOP answers only what they ask, in this order:
1. How do I run it? Which URL or shortcut, what do I click.
2. What shows where once it runs?
3. Where is the result, and what does it mean?
4. Something went wrong: how does it show, and what do I do?
5. Who do I email about it, and who goes in CC?
## Steps
| File | What it is |
|---|---|
| `templates/HANDOVER-SOP.md` | The SOP skeleton: 5 sections. Keep their order. |
| `templates/failure-classes.md` | 12 failure classes from Tebra Auto Post. A scan checklist so no problem type is missed. |
| `templates/reference/tebra-auto-post.md` | A filled example for Tebra, scrubbed. Copy its length and wording, not its content. |
| `templates/to_docx.py` | Turns the finished SOP into Word, and with `--pdf` into PDF too (through Word on Windows, LibreOffice elsewhere). Prints the word and page count. Needs `python-docx`. |
1. **Scan.** Start 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 the operator can see, alerts, and how to stop.
2. **Ask once:** the developer's email (To), the manager's name and email (CC), and where ops runs it if the code allows more than one place.
3. **Write** `HANDOVER-SOP.md` from `templates/HANDOVER-SOP.md`: 1. How to run, 2. What you see while it runs, 3. Result, 4. When something goes wrong, 5. Email us.
4. **Build** with `templates/to_docx.py`: `python <skill>/templates/to_docx.py HANDOVER-SOP.md -o "<Project Name> Handover SOP.docx" --pdf`. Over 4 pages: shorten cells, never drop a message.
5. **Hand over** the PDF. List problems for the dev team in at most 5 lines in the chat, not in the SOP.
## Rules
- **Short.** At most 4 pages, which is about 1,400 words including tables. A small bot fits in 2. Never pad: a section with nothing to say gets one line.
- **Accurate.** Copy every URL, button label, lane or column name, status and message **exactly** from the code or the screen. Never paraphrase a message the operator will search for. When the code builds a message from parts, write it with the variable parts in italics: "Couldn't download *Location* from *Portal*".
- **Every wait is a number** from the code, in seconds or minutes. Write "not measured" for a normal duration the logs don't show.
- **Write what the code does.** If the screen misleads (green or "Finished" while something failed), say so in one line where it shows.
- **The operator's words only.** No file:line, function names, SQL, env var names or log internals in the SOP.
- **Never run the bot.** Read code, config, logs and history only.
- **Never copy** patient data, customer or client names, credentials, internal IPs, keys or `.env` values into the SOP.
- **Re-runs:** always say what clicking Run (or starting the bot) again does to the data: does it start from the current data, and does it delete or overwrite the previous results.
- Copy every label and message exactly from the code. Variable parts go in *italics*: "Couldn't download *Location*".
- Every wait is a number. Say plainly when the screen misleads ("Finished" while something failed).
- Say what clicking Run again does to the old results.
- One row per message, one short line per cell.
- No file names, code, settings names, patient data, client names or passwords.
## 1. Scan (one subagent, required)
## Don't miss
Start one read-only subagent. Tell it: never run the bot, no PHI, client names, credentials or IPs in the report, file:line refs, under 1200 words. Ask it for:
1. **Start:** the URL, shortcut or command ops uses, the sign-in screen, and the exact button that starts a run. What clicking it again does to the previous data and results.
2. **Screen while running:** every area, lane, list or column that changes during a run, its exact label and the texts it shows, in order.
3. **Waits:** every timeout and retry count, in seconds, with its step. What the bot does when it runs out.
4. **Result:** how a run ends on screen (texts, colours), where the result or report is, its name, sheets or columns, and every per-item status with its meaning.
5. **Problems:** every message the operator can see (exact text, where it shows, colour), what triggers it, whether the bot retries, what happens next. Include sign-in and connection messages.
6. **Alerts and stopping:** any email, popup or sound on failure (or none), whether there is a Stop button, and anything ops must not do while it runs.
While it runs, read `templates/failure-classes.md` and `templates/reference/tebra-auto-post.md`. Check the subagent's report against the 12 classes; ask it a follow-up for any class it skipped.
## 2. Ask once (one message, at most 2 questions)
1. **Email:** the developer's email address (the "To"), the manager's name and email address (the "CC"), and how fast ops gets an answer. Never a personal phone number. The CC is the developer's manager, not the operator's.
2. **Where ops runs it:** the URL or machine, when the code allows more than one.
Skip a question the user already answered. Default the rest: title from the project name, today's date, version from the project's version string.
## 3. Write `HANDOVER-SOP.md`
Copy `templates/HANDOVER-SOP.md` to the bot's repo root and fill every `{{PLACEHOLDER}}`:
1. **How to run:** the URL or shortcut, then numbered steps with the real labels. Then 2 to 4 "before you click" bullets, including what a new click does to the previous results.
2. **What you see while it runs:** a table, one row per area of the screen, in screen order: where, what it shows. Then the normal sequence in 3 to 5 numbered lines. Then the waits table: step, the bot waits at most, then. End with when the operator steps in.
3. **Result:** how a good run ends; how a run that needs a look ends (call out misleading greens). Then where the result is, and a small table of the per-item statuses: status, meaning, what you do.
4. **When something goes wrong:** where problems show and how (colour, list, column). Then one table row per message, numbered `E01`, `E02`...: message (exact), what it means, what you do. Put "check X **before** re-running" in bold. Say "email us" in the row when the operator can't fix it. Then the don'ts in at most 4 bullets, and the one right way to stop the bot.
5. **Email us:** "To" the developer and "CC" the developer's manager, both as real addresses, the response time, when to email, the email to copy (To, CC, Subject and body lines), what to attach, and what never to send (passwords, patient or client data, the result files when they hold patient data).
## 4. Verify
1. Every message and status in the subagent's report is in section 3 or 4.
2. Search the code for each quoted message, label and URL. Each must exist exactly, or be built by the code from the parts shown in italics.
3. No file:line, function names, env var names, client names, PHI, credentials or IPs.
4. Run `python <skill>/templates/to_docx.py HANDOVER-SOP.md -o "<Project Name> Handover SOP.docx" --pdf`. It writes the docx and the PDF. If it reports more than 1,400 words or more than 4 pages, cut: merge rows, drop explanations, never drop a message.
5. Open the docx with python-docx: 5 numbered section headings, no `**` or `|---` left.
6. Section 5 has a real "To" and "CC" address, and the email block starts with `To:` and `CC:` lines.
## 5. Hand over
Give the user the path to `<Project Name> Handover SOP.pdf`: "Give this to the ops team." If no PDF could be made (no Word or LibreOffice), say so and give the docx. Then, in the chat only, list in at most 5 lines the problems the scan found that the dev team should fix (misleading statuses, silent failures, no alerts). They are not part of the SOP.
Check the bot for 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.