From 36e621b153d62a9f50cff193c4fc4e2abbe4f879 Mon Sep 17 00:00:00 2001 From: Vasanth Date: Wed, 28 Oct 2026 17:28:23 +0530 Subject: [PATCH] rpa-bot-handoff: short skill, MEK SOP as the model 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 --- GLOSSARY.md | 2 +- docs/adr/0005-handover-is-a-short-sop.md | 4 +- skills/rpa-bot-handoff/README.md | 3 +- skills/rpa-bot-handoff/SKILL.md | 83 ++++---------- .../templates/failure-classes.md | 63 ----------- .../reference/mek-charge-reconciliation.md | 106 ++++++++++++++++++ .../templates/reference/tebra-auto-post.md | 100 ----------------- skills/rpa-bot-handoff/templates/to_docx.py | 2 +- tests/test_templates.py | 8 +- 9 files changed, 137 insertions(+), 234 deletions(-) delete mode 100644 skills/rpa-bot-handoff/templates/failure-classes.md create mode 100644 skills/rpa-bot-handoff/templates/reference/mek-charge-reconciliation.md delete mode 100644 skills/rpa-bot-handoff/templates/reference/tebra-auto-post.md diff --git a/GLOSSARY.md b/GLOSSARY.md index db4d8a0..fee9599 100644 --- a/GLOSSARY.md +++ b/GLOSSARY.md @@ -44,4 +44,4 @@ It is hidden for bots that take no input file. **Business exception**: the data says no (cutoff date passed, negative balance, already posted). **System exception**: the bot or the target app failed (window not found, timeout, crash). -**Failure class**: one of the 12 kinds of problem Tebra Auto Post hit after handover (`F1`-`F12` in `skills/rpa-bot-handoff/templates/failure-classes.md`). The SOP scan checks every bot against all 12 so no problem type is missed. +**Don't-miss checks**: the 6 one-line problem types in `rpa-bot-handoff`'s SKILL.md (setup missing, slow or changed app, name mismatch, says done but isn't, stuck or can't stop, cause hidden). They replace the 12 Tebra failure classes. Every SOP covers each one that applies. diff --git a/docs/adr/0005-handover-is-a-short-sop.md b/docs/adr/0005-handover-is-a-short-sop.md index d3e2ba2..993c680 100644 --- a/docs/adr/0005-handover-is-a-short-sop.md +++ b/docs/adr/0005-handover-is-a-short-sop.md @@ -8,4 +8,6 @@ Supersedes ADR-0004. **Accuracy instead of length:** every quoted message, label and URL is checked against the code before handover, and messages the code builds from parts show those parts in italics. The SOP must say what clicking Run again does to the data (fresh run on current data, previous results deleted or kept). -**Kept from ADR-0004:** the operator's words only, every wait is a number from the code, misleading statuses are called out where they show, the bot is never run, and the 12 failure classes are still checked during the scan so no problem type is missed. +**Kept from ADR-0004:** the operator's words only, every wait is a number from the code, misleading statuses are called out where they show, the bot is never run, and the bot is checked for every common problem type. + +**Shorter skill (Oct 2026):** the user found the skill itself too detailed. SKILL.md is now a short checklist (under 500 words), the 12 Tebra failure classes are folded into 6 one-line "don't miss" checks, and the MEK Charge Reconciliation SOP (the 3-page PDF ops liked) replaces the Tebra example as the model. diff --git a/skills/rpa-bot-handoff/README.md b/skills/rpa-bot-handoff/README.md index 62e02fb..960d311 100644 --- a/skills/rpa-bot-handoff/README.md +++ b/skills/rpa-bot-handoff/README.md @@ -27,6 +27,5 @@ In your bot project, ask Claude: *"write the handover SOP for this bot"* or *"do |---|---| | `SKILL.md` | Steps Claude follows | | `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/reference/mek-charge-reconciliation.md` | The model SOP (MEK Charge Reconciliation, 3 pages) | | `templates/to_docx.py` | Turns the SOP into Word, and with `--pdf` into PDF; prints word and page counts (`--selfcheck` tests it) | diff --git a/skills/rpa-bot-handoff/SKILL.md b/skills/rpa-bot-handoff/SKILL.md index 977ebda..2ffb4fd 100644 --- a/skills/rpa-bot-handoff/SKILL.md +++ b/skills/rpa-bot-handoff/SKILL.md @@ -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 - " 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 " 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: **` Handover SOP`**, as `HANDOVER-SOP.md`, ` Handover SOP.docx` and ` Handover SOP.pdf`. The PDF is what ops gets. +Make **` 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 /templates/to_docx.py HANDOVER-SOP.md -o " 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 /templates/to_docx.py HANDOVER-SOP.md -o " 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 ` 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. diff --git a/skills/rpa-bot-handoff/templates/failure-classes.md b/skills/rpa-bot-handoff/templates/failure-classes.md deleted file mode 100644 index f5a17b9..0000000 --- a/skills/rpa-bot-handoff/templates/failure-classes.md +++ /dev/null @@ -1,63 +0,0 @@ -# Failure classes - -Twelve kinds of problem Tebra Auto Post hit in its first months with ops. Check every new bot against each one. For each class: what to look for in the code, and where the ops guide (`HANDOVER.md`) or the dev notes (`HANDOVER-DEV.md`) must cover it. Section numbers are the ops guide's. - -## F1. Missing prerequisite on the ops machine -**Tebra:** a missing database driver gave a cryptic error only on some laptops; a missing settings file made the duplicate check fail silently; a helper app's shortcut wasn't where the bot searched; some bugs appeared only in the packaged exe, never under `uv run`. -**Look for:** drivers, `.env` / settings files, shortcuts or install paths the bot searches, `sys.frozen` branches. -**Doc:** the "Before you start" checklist in section 3, and the exact message each missing item produces in section 7. - -## F2. The bot grabs the wrong window, or can't take focus -**Tebra:** it matched its own window, and a database tool whose title held the target app's name, then closed the real app. Windows' foreground lock meant clicks landed elsewhere when someone used the machine during a run. -**Look for:** window matching by title substring, focus / foreground calls, exclude lists. -**Doc:** section 10: which windows must not be open, and hands off the machine. - -## F3. The target app is slower, or different, than the bot expects -**Tebra:** a screen took about 98 s under load against a 90 s timeout; two screens shared a header and were confused; controls drawn without accessibility elements; a long list put the target off-screen; a wrapped name was clicked between its lines on a small screen. -**Look for:** every timeout value, screen-identification checks, "element not found" paths, screen-size assumptions. -**Doc:** a section 7 row for each "not found / did not load" message, and the wait from section 4. Screen-resolution rules go in section 3. - -## F4. Input data the bot reads differently than ops writes it -**Tebra:** names containing commas were split into pieces and silently skipped; a `&` in a name broke matching; Excel dates arrived as serial numbers; a new client with no mapping entry got the wrong file prefix. -**Look for:** split / separator logic, name matching, date parsing, mapping or config files ops must maintain. -**Doc:** input rules in section 3, each with one wrong and one right example. Point at the sample input file if the bot has one. - -## F5. Marked done when nothing was done -**Tebra:** a location was marked Success with 0 items when the bot couldn't confirm it was on the right page; a company was marked Success after a crash. -**Look for:** where success / complete is set, and whether it checks a positive count or a confirmation first. -**Doc:** if a guard exists, a section 7 row for the "left Pending" message. If not, a gap in `HANDOVER-DEV.md`. - -## F6. The action happened but the bot couldn't confirm it -**Tebra:** "Payment not confirmed after Save" - the save took longer than the wait, so the row showed Error while the payment really had posted. Re-running risked posting twice. -**Look for:** waits after a commit action (save, submit, send), and what the bot writes when the confirmation times out. -**Doc:** a section 7 row that tells ops, in bold, to **check in the target app before re-running**, and how to correct the record afterwards. - -## F7. A business exception shown as success -**Tebra:** "ERA Errors on posting" and "negative balance - not posted" rows showed green (Completed) although a person had to follow up. -**Look for:** status mapping tables; any comment that means "not done" stored under a success status. -**Doc:** mark these "not done, needs follow-up" in the section 5 status table, give each a section 7 row, and add the mapping to the gaps in `HANDOVER-DEV.md`. - -## F8. Endless re-runs, or killed by the watchdog -**Tebra:** practices with no items re-ran the same company forever; already-processed rows were re-walked slowly after a restart until the watchdog killed the run at exactly 300 s, again and again. -**Look for:** auto-rerun loops and their limits, watchdog timeouts, "0 items" handling, heartbeats. -**Doc:** every limit in section 4, and in section 7 the signs of a loop ops should report ("the same company restarts more than N times"). - -## F9. Stopping the bot the wrong way -**Tebra:** closing the app window didn't stop the bot, which kept driving the target app; closing the target app doesn't stop it either. -**Look for:** how the child process ends (process-tree kill, parent-death watch), and any Stop button. -**Doc:** the one right way to stop it, in section 10. - -## F10. One stuck item blocks the queue -**Tebra:** one Error row kept a whole batch Pending for weeks; a run that died in its first seconds locked the upload all day. Ops didn't know which row blocked it, or that yesterday's Pending batch never blocks today's upload. -**Look for:** completion gates (what must be true for a batch / company to complete), locks on new uploads, resume logic. -**Doc:** in section 7: what blocks what, how to find the blocking item (section 6), and how to release it (edit, discard, clear). - -## F11. The cause is hidden from ops -**Tebra:** the real cause was only in a database column the Report tab didn't show, or in the raw log; the friendly on-screen log hid errors; some app messages went to the screen only, never to a file. -**Look for:** columns written but never displayed, log filters, messages printed only to the UI. -**Doc:** sections 2 and 6 point only at places ops can open (question 2). Every hidden cause becomes a gap in `HANDOVER-DEV.md`. - -## F12. The update didn't arrive, or an old build undid a new one -**Tebra:** the launcher failed silently on a self-signed certificate, so users stayed on an old version; the server reported a deploy as done without swapping the container; a stale zip was shipped; each start re-deployed database procedures, so a machine on an old build overwrote newer ones. -**Look for:** update / launcher code, version display, anything the app writes to shared resources on start. -**Doc:** section 3 (check the version before a run) and section 11. Add "every machine must run the same version" when shared resources are rewritten on start. diff --git a/skills/rpa-bot-handoff/templates/reference/mek-charge-reconciliation.md b/skills/rpa-bot-handoff/templates/reference/mek-charge-reconciliation.md new file mode 100644 index 0000000..df2181e --- /dev/null +++ b/skills/rpa-bot-handoff/templates/reference/mek-charge-reconciliation.md @@ -0,0 +1,106 @@ +# Model SOP: MEK Charge Reconciliation + +The SOP ops liked: 3 pages, plain words, every message copied from the app. The email addresses are examples. Copy its length, layout and tone, not its content. + +--- + +# MEK Charge Reconciliation Handover SOP + +Version 0.1.0 · 28 Oct 2026 · Problems: email dev@example.com, CC manager@example.com (section 5) + +Downloads the Waystar claims and the Aquilaehr visits for every MEK location, both portals at the same time, matches them by patient name and date of service, and builds one Excel report per location plus one for All Locations. + +## 1. How to run + +1. Open https://mek-charge-reconciliation.app.ecareindia.com/ in your browser. +2. Type the team password in **Password** and click **Sign in**. You stay signed in for 12 hours. +3. Click **Run reconciliation**. +4. Wait until the status next to the button says **Finished** or **Stopped**. Closing the tab doesn't stop the run. + +**Before you click Run reconciliation:** +- **Download the reports you still need.** Every click first deletes all the previous reports, then downloads fresh data from both portals and builds new reports from it. +- Only one run at a time. If the button is greyed out and the status says "Running…", a run is already going: wait for it. + +## 2. What you see while it runs + +| Where on the screen | What it shows | +|---|---| +| **Waystar** and **Aquilaehr** lanes | "Ready" → "Signing in…" → "3 of 10 locations" → "All 10 downloaded" (green). Orange "8 of 10 · 2 failed" when some locations failed. Red "Stopped" when that portal stopped | +| **Excel reports** box | "Waiting for both downloads" → "Building 4 of 11" → "11 reports ready" (green) | +| Status next to the button | "Running…" → "Finished *time*" (green) or "Stopped *time*" (red) | +| Activity list under the button | One line per step, starting with "Run started *time*". Dot colours: green done, orange check this, red failed, grey progress | +| **Technical log** (click to open) | Raw lines, only for an email to us | +| **Reports** box | One row per report with "Updated *time* · *size* KB" and **Download**, plus **Download all (ZIP)** | + +The page refreshes itself every 2 seconds. + +**A normal run:** both lanes sign in and fill up at the same time; when both say "All 10 downloaded", the Excel box counts to "11 reports ready" and the last line says "Finished. Your reports are ready to download below." + +| Step | The bot waits at most | Then | +|---|---|---| +| Sign in to each portal | 3 min | That portal stops for this run (E01) | +| Each step for one location (find, switch, load, download) | 15 s to 2 min | Skips that location. No step is retried | + +**Step in only when:** the status says Finished or Stopped, or no new line has appeared in the activity list for 10 minutes (E10). + +## 3. Result + +- **Good run:** "Finished", both lanes green "All 10 downloaded", "11 reports ready", no red or orange dots. +- **Needs a look:** any red or orange dot, an orange or red lane, or "Stopped". **"Finished" also shows when one portal failed to sign in: always check both lanes.** +- There is no email or alert. Open the page after every run. + +**Where:** **Reports** box → **Download**, or **Download all (ZIP)**. Each Excel has a **Summary** sheet with the counts and a **Reconciliation** sheet. Filter its **Result** column: + +| Result | Meaning | What you do | +|---|---|---| +| Matched | Same date of service, first name and a last name | Nothing | +| Missing in Waystar | An Aquilaehr visit with no Waystar claim | Follow up. If the Note says "Claim ID … is in Waystar with DOS …", the claim exists with another date | +| Missing in Aquilaehr | A Waystar claim with no Aquilaehr visit | Follow up. If the Note says "Claim ID … is in Aquilaehr with Visit Date …", the visit exists with another date | +| Duplicate in Waystar | "Same patient + DOS already matched to another Waystar claim" | Check for a double claim | + +## 4. When something goes wrong + +**How it shows:** a red or orange dot in the activity list, an orange or red lane, or the status "Stopped". The line names the location and the portal. + +| ID | Message you see | What it means | What you do | +|---|---|---|---| +| E01 | "Couldn't sign in to *Portal* in time. Check the login details, then run again." | Nothing was downloaded from that portal. Its lane stays on "Signing in…", then turns red "Stopped" | Run again once. Fails again: email us (only we can change the logins) | +| E02 | "Couldn't download *Location* from *Portal*. This location wasn't found in *Portal*." | The location was renamed or removed in the portal | Email us. Re-running won't help | +| E03 | "Couldn't download *Location* from *Portal*. *Portal* took too long to respond." | The portal was too slow | Download the good reports, run again later. Fails twice: email us | +| E04 | "Couldn't download *Location* from Aquilaehr. Aquilaehr opened a different location than expected." | Aquilaehr showed the wrong practice | Run again. Fails twice: email us | +| E05 | "Couldn't download *Location* from *Portal*. Try running again. If it keeps failing, open the technical log below." | Any other download problem | Run again. Fails twice: email us | +| E06 | "*Portal* finished, but these locations couldn't be downloaded: *names*" | Summary of E02 to E05 | Those locations have no report, or a one-sided one | +| E07 | "*Location* has exactly the same *Portal* data as *Location*. Please check this location." | One may hold the other's data | **Don't use those two reports.** Run again (expected only when both have no data) | +| E08 | "Skipped *Location*: nothing was downloaded from Aquilaehr" | No report was built for that location | Look for its red Aquilaehr line (E01 to E05) | +| E09 | "Check *Location*: fewer than half of the visits matched. The wrong practice may have been downloaded." | Most visits didn't match | **Before re-running, check its Note column.** Dates exactly one day off the DOS: don't re-run, email us. Otherwise run again | +| E10 | "Running…" with no new activity line for 10 minutes | The run is stuck | Email us. Don't start another run | +| E11 | "Something unexpected went wrong. The technical log below has the details.", or "Stopped" with no red line that explains it | An error without a plain message, e.g. a new Waystar security question | Email us with the last 20 lines of **Technical log** | +| E12 | A location has no report and no red line names it | A failed Waystar download is not always listed | Email us | +| E13 | The lanes say "Ready" and the status is empty, although a run was started | The server restarted and the run was lost | Download what is listed, then run again | +| E14 | "That password isn't right. Try again." or "Enter your password." | Wrong or empty password | Check for "Caps Lock is on" and type it again | +| E15 | "Sign-in failed. Try again.", "Can't reach the server. Try again.", or a 404 / 502 page | The server or the network has a problem | Try again in 5 minutes, then email us | + +**Don't:** +- Click **Run reconciliation** before downloading the reports you need: it deletes them. +- Ask for a server restart or redeploy during a run: the run is lost. +- Sign in to Waystar or Aquilaehr with the bot's account during a run. + +**To stop it:** there is no Stop button, and closing the page doesn't stop it. Let it finish, or email us and we stop it on the server. + +## 5. Email us + +Email **dev@example.com** with **the RPA manager** (manager@example.com) in CC when section 4 says "email us", or when the same error comes back after one re-run. Answer: same working day. + +``` +To: dev@example.com +CC: manager@example.com +Subject: MEK Charge Reconciliation - E - + +Run started: +Error: E - +Location / portal: +What I did: +Attached: screenshot of the Run box +``` + +**Never send:** the sign-in password, or the Excel reports (they hold patient names). diff --git a/skills/rpa-bot-handoff/templates/reference/tebra-auto-post.md b/skills/rpa-bot-handoff/templates/reference/tebra-auto-post.md deleted file mode 100644 index 82eb695..0000000 --- a/skills/rpa-bot-handoff/templates/reference/tebra-auto-post.md +++ /dev/null @@ -1,100 +0,0 @@ -# Worked example: Tebra Auto Post (v2.5.3), scrubbed - -What the SOP looks like for a real bot: about 2.5 pages. Client names, IDs, amounts, credentials and server addresses are removed, and the email addresses are examples. **Copy the length and the plain wording, not the content.** - ---- - -# Tebra Auto Post Handover SOP - -Version 2.5.3 · 28 Oct 2026 · Problems: email dev@example.com, CC manager@example.com (section 5) - -Posts insurance ERA payments into the Tebra desktop app, company by company and practice by practice, from the input Excel, then turns each ERA into a PDF. - -## 1. How to run - -1. Open **Ecare Tebra Automation Tool** from the Desktop. Check the title bar shows v2.5.3. -2. **Run** tab → drop the input Excel on the upload box. -3. Check the preview: the Login, Company and Location sheets all have rows. -4. Click **Trigger automation**. -5. Leave the mouse and keyboard alone until the run ends. - -**Before you click Trigger automation:** -- One practice per row. Wrong: `North Clinic, South Clinic` in one cell (both are skipped). Right: one per row, spelled exactly as in Tebra. -- Every click starts a new batch from the Excel you uploaded. ERAs already posted are not posted again. -- Close SQL Server Management Studio and any other window with "Tebra" in its title. - -## 2. What you see while it runs - -| Where on the screen | What it shows | -|---|---| -| **Run** tab → checkpoint boxes | 7 boxes, grey → green as each step finishes; red **stuck** when a step makes no progress | -| **Run** tab → live log | Each company, practice and ERA as it is posted | -| **Dashboard** | The batch: Pending while running, Completed when every practice is done | -| **Report** tab | One row per ERA: File Status (colour) and Comments | - -**A normal run:** -1. Tebra opens by itself and signs in to the first company. -2. The checkpoint boxes turn green one by one; the live log lists each ERA. -3. Tebra closes and reopens for the next company. -4. The Dashboard shows the batch as **Completed**. - -| Step | The bot waits at most | Then | -|---|---|---| -| Any checkpoint box | 5 min with no progress (10 min for the ERA list) | Marks it red **stuck**, restarts Tebra, up to 3 times | -| Open one ERA | 90 s, 3 tries, then 3 Tebra restarts | Writes the row as Error, moves on | -| Save one payment | 45 s + 30 s + 30 s | Checks the ERA list; Error if still there (E03) | -| PDF of one ERA | 60 min | Moves the file to `Need_attention` | - -**Step in only when:** the run has ended, or the log says "Stuck - automatic restarts exhausted. Click Resume.". - -## 3. Result - -- **Good run:** the batch is **Completed** on the Dashboard and the Report tab has no red rows. -- **Needs a look:** the batch stays **Pending**, or a row is red. **Three different results show green**: read the Comments of every green row. - -**Where:** Report tab → search the Batch ID → File Status and Comments. Export with the Excel button. - -| Status - Comments | Meaning | What you do | -|---|---|---| -| Completed - "Posted successfully" | Posted | Nothing | -| Completed - "ERA Errors on posting" | **Not posted.** Tebra rejected it | Review it in Tebra by hand | -| Completed - "negative balance account … not posted" | **Not posted on purpose** | Follow the negative-balance process | -| Deferred (grey) | Check date after the cutoff | Nothing; a later run picks it up | -| Error (red) | Failed after all retries | Section 4 | - -## 4. When something goes wrong - -**How it shows:** a red row on the Report tab (read Comments), a red **stuck** box on the Run tab, or a batch still **Pending** on the Dashboard. - -| ID | Message you see | What it means | What you do | -|---|---|---|---| -| E01 | "[login] FAILED for company …" | Tebra's sign-in never appeared | Check the Login sheet, then click **Resume**. Email us if it fails again | -| E02 | "Wrong practice opened … leaving Pending" | The practice name doesn't match Tebra | Fix the spelling in the Excel, click **Resume** | -| E03 | "Payment not confirmed after Save" | The bot clicked Save but never saw "saved". **It may have posted** | **Check the payment in Tebra before re-running.** If posted, set the row to Completed. If not, click **Resume** | -| E04 | "Save button element not found" | The payment screen had no Save button | Email us | -| E05 | "Stuck - automatic restarts exhausted. Click Resume." | 3 restarts didn't help | Click **Resume** once. Email us if it stops again | -| E06 | Batch stays **Pending** | One red or unfinished row keeps its practice open | Find the red row (Report tab), fix or edit it. Email us if you can't find it | - -**Don't:** -- Use the mouse or keyboard while it runs: its clicks land in the wrong window. -- Close Tebra to stop the bot: the bot keeps going. - -**To stop it:** close the **Ecare Tebra Automation Tool** window. - -## 5. Email us - -Email **dev@example.com** with **the RPA manager** (manager@example.com) in CC when section 4 says "email us", or when the same error comes back after one Resume. Answer: same working day. - -``` -To: dev@example.com -CC: manager@example.com -Subject: Tebra Auto Post - E - - -Batch ID: -Error: E - -Where: -What I did: -Attached: screenshot of the Run tab and of Tebra -``` - -**Never send:** the Login sheet, passwords, or patient names. diff --git a/skills/rpa-bot-handoff/templates/to_docx.py b/skills/rpa-bot-handoff/templates/to_docx.py index ac9bea9..764fe82 100644 --- a/skills/rpa-bot-handoff/templates/to_docx.py +++ b/skills/rpa-bot-handoff/templates/to_docx.py @@ -120,7 +120,7 @@ def to_pdf(docx_path): def selfcheck(): - example = Path(__file__).parent / "reference" / "tebra-auto-post.md" + example = Path(__file__).parent / "reference" / "mek-charge-reconciliation.md" sop = "# " + example.read_text(encoding="utf-8").split("\n---\n", 1)[1].split("\n# ", 1)[1] out = Path(tempfile.mkdtemp()) / "HANDOVER-SOP.docx" convert(sop, out) diff --git a/tests/test_templates.py b/tests/test_templates.py index e4bbf8f..b2ce76a 100644 --- a/tests/test_templates.py +++ b/tests/test_templates.py @@ -52,10 +52,10 @@ def test_handoff_skill_references_files_that_exist(): assert not [p for p in paths if not (skill / p).exists()] -def test_handoff_lists_twelve_failure_classes(): - skill = ROOT / "skills" / "rpa-bot-handoff" / "templates" - classes = (skill / "failure-classes.md").read_text(encoding="utf-8") - assert len(re.findall(r"^## F\d+\.", classes, re.MULTILINE)) == 12 +def test_handoff_skill_stays_short(): + skill = (ROOT / "skills" / "rpa-bot-handoff" / "SKILL.md").read_text(encoding="utf-8") + assert len(skill.split()) <= 500, len(skill.split()) + assert len(re.findall(r"^\d+\. ", skill.split("## Don't miss")[1], re.MULTILINE)) == 6 def test_handoff_sop_has_five_sections_in_order():