VasanthandClaude Opus 5.5
ff2f7fcd4a
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>
1.9 KiB
The handover is an ops guide in the operator's order, with dev notes kept apart
Superseded by ADR-0005.
rpa-bot-handoff writes two files:
HANDOVER.mdis for the operator who runs the bot and does not read code. Its 11 sections follow the operator's own questions, in the order they ask them: where is what, how do I run it, how long do I wait, how do I read the result and the report, how do I see an exception, how will I know, how do I tell the dev team, what must I not do, what happened before.HANDOVER-DEV.mdis for developers. It holds the failure-class check and the gaps to fix before handover, with file:line.
Every exception row tells ops whether to wait (the bot retries by itself), act, or call the dev team. Every wait is a number of seconds or minutes taken from the code. The skill changes no code.
Why: the first version was one document sorted by architecture and exception type, with dev sections mixed in. Reviewing it, the user said ops need "which tab shows what, how to run, how many seconds to wait, which tab has the report, how to see an exception, how to tell us". In Tebra Auto Post's first months, most ops questions were exactly these. Ops re-ran items the bot was still retrying. They edited rows that needed a check in Tebra first ("Payment not confirmed after Save" had really posted). They couldn't tell why a batch stayed Pending. Architecture, failure classes and file:line refs don't help an operator, and they bury what does.
Lessons as a checklist: Tebra's incidents are bundled as 12 generic failure classes. Each new bot is checked against every class in HANDOVER-DEV.md, and an unused class is written down as "not applicable" with a reason, so nothing is dropped silently. A scrubbed Tebra example shows both files.
Subagents are required: in the first 47 eval runs, 8 wrote the doc without starting the scan subagents. The skill now says to always start them.