VasanthandClaude Opus 5.5
36e621b153
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>
35 lines
2.6 KiB
Markdown
35 lines
2.6 KiB
Markdown
---
|
|
name: rpa-bot-handoff
|
|
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
|
|
|
|
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.
|
|
|
|
## Steps
|
|
|
|
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
|
|
|
|
- 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.
|
|
|
|
## Don't miss
|
|
|
|
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.
|