Files
Rpa_Skills/rpa-dashboard-no-ai/SKILL.md
T
VasanthandClaude Opus 5.5 9a5b95448d Optional sections: checkpoint tracker, admin/roles, login page
- dashboard.html: each section sits in OPTIONAL:<name> BEGIN/END blocks in
  the style, markup and script, with sample answers so a page with no bot
  shows it working. Core change: setUser records the role on <body>, so CSS
  hides admin-only parts from operators.
- templates/sections.py keeps the chosen sections and deletes the rest,
  markers included; it stops on a broken marker.
- templates/sections.md: what each section needs from the host (events,
  actions, desktop slot snippets, the role re-check, the login hand-off).
- SKILL.md step 5 asks one multi-select question and runs sections.py.
- Page check: checkpoint states, admin visibility by role and assign/remove,
  login theme and hand-off to auth or the stub. Cases skip on a generated
  page without the section; the template must carry all three. The harness
  signs in when the page has a login screen.
- tests/test_sections.py: no sections leave no trace, and that page still
  passes the page check.
- Eval runner: a-empty-sections variant (all three) and per-section checks.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 14:31:25 +05:30

133 lines
7.5 KiB
Markdown

---
name: rpa-dashboard-no-ai
description: Builds a working dashboard page for an RPA bot that does not use AI. It always includes a sidebar and top bar with a dark toggle and status dot, KPI cards, a batch status donut, a run panel with steps and a live log, and a report table with search and Excel export. The page is wired to the bot through one data contract, or runs on sample data when there is no bot yet. Supports a desktop path (PyQt6 with an embedded page) and a web path. Use when the user asks for an "RPA dashboard", "automation dashboard", "bot dashboard", a dashboard "without AI", or a status/run/report page for a bot. For bots that use an LLM or OCR extraction, use rpa-dashboard-ai instead.
---
# RPA dashboard (no AI)
Everything this skill needs is bundled in `templates/`. Never read the original
source projects.
| File | What it is |
|---|---|
| `templates/dashboard.html` | The single-file page: theme tokens, shell, KPI, donut, run panel, report, sample data. Works in PyQt (QWebChannel) or on the web (polling). |
| `templates/bridge.py` | Minimal PyQt6 host. It runs the bot as a child process and tails its output. |
| `templates/contract.md` | The data contract: events the bot sends, actions the page sends. |
| `templates/themes.md` | Theme presets (Tebra Sky, Superbill Ember) and the custom-colour steps. |
| `templates/palette.py` | Derives a custom palette from one brand hex and checks contrast. |
| `templates/sections.py`, `templates/sections.md` | Keeps the chosen optional sections in the page and deletes the rest; what each section needs from the host. |
| `templates/reference/` | Raw Tebra extracts, for reference only. The optional sections are already in `dashboard.html`. |
Follow the steps in order. Ask one question at a time, and wait for the answer.
If the user's request already answers a question, don't ask it again.
## 1. Scan the project
Before asking anything, look at the project:
- **Frontend:** `*.html` files outside `node_modules`, `.venv` and build output; a
`web/`, `frontend/` or `static/` folder; `package.json` with react, vue, angular or
svelte; a PyQt `QWebEngineView`. For any you find, note the location, the stack and
the main colour tokens (CSS custom properties or the Tailwind theme).
- **Bot:** the entry point (for example `main.py`, a `__main__` module or a run
script), what it prints (step markers, status and error lines), and how it starts.
## 2. Report the frontend, then ask keep or restyle
- **No frontend:** say "No existing frontend found." and go to step 3. Don't
describe a frontend that isn't there.
- **Frontend found:** say "Frontend found at `<path>`, stack `<stack>`, colours
`<main tokens>`." Then ask: **keep its look**, or **restyle** it?
- Keep: skip step 3. Build the page with the project's own tokens and fonts, and
change none of its existing styles.
- Restyle: go to step 3. Change only the theme tokens, never layout or logic.
## 3. Ask for colours
Skip this if the user chose to keep the existing look. Offer:
1. **Tebra Sky**: blue glass cards on a sky gradient.
2. **Superbill Ember**: flat surfaces with a red-orange brand gradient.
3. **Custom**: the user gives one brand hex colour.
## 4. Ask desktop or web
Ask only if there is no frontend. If there is one, use its stack.
- **Desktop:** a PyQt6 window with the page embedded. The page talks to Python
through a bridge, so no web server is needed.
- **Web:** the same page, served by a backend that it polls.
## 5. Ask which optional sections to build
Always built: the shell (sidebar, top bar, dark toggle, status dot), KPI cards,
the status donut, the run panel and the report table.
Ask which extras to add, as one multi-select question (choose any, or none):
- **Checkpoint tracker**: numbered boxes on the Run tab that show each checkpoint as
pending, in progress, done or stuck.
- **Admin/roles screen**: an Admin tab, for admins only, to give people admin or
operator access.
- **Login page**: a sign-in screen in the dashboard's theme. It's UI only and hands
off to the project's own auth.
Build only the chosen ones. In step 6, right after copying the page, run
`python templates/sections.py <copied dashboard.html> <chosen: checkpoints admin login>`.
It deletes the unchosen sections completely (markup, script and style), so nothing
is left behind. Never cut the blocks by hand. Then follow `templates/sections.md` for
each kept section: what to fill, which events the bot sends, and which host actions
to answer.
## 6. Build
1. Copy `templates/dashboard.html` into the project:
- Desktop: put it next to the host, for example `dashboard/dashboard.html`.
- Web: put it in the backend's static folder. With no backend yet, use
`dashboard/dashboard.html`.
2. Fill every `{{...}}` placeholder:
| Placeholder | Value |
|---|---|
| `APP_NAME`, `APP_SUBTITLE` | The project's name and a short tagline. |
| `LOGO_SRC` | The logo's path, or empty if there is none. |
| `STEPS_JSON` | The run steps as a JSON list, from the bot's real stages, for example `["Initializing","Login","Process items","Completed"]`. |
| `REPORT_COLUMNS_JSON` | `[{"key":..., "label":...}]`. It must include a column with key `status`, which shows the bucket pill. |
| `API_BASE` | Web only, for example `/api`. Leave it empty for desktop. |
3. Apply the theme by replacing the `body{...}` and `body.dark{...}` token blocks
with the preset from `templates/themes.md`. For Ember, also add its font link.
For a custom colour, run `python templates/palette.py "<hex>"`, paste the
tokens it prints, and show the user its contrast table.
4. Desktop: also copy `templates/bridge.py` next to the page, and fill
`{{BOT_MODULE}}`, the `STEPS` list (the same steps as the page), `{{ORG}}` and
`{{APP_NAME}}`.
5. Search the output for `{{`. None may be left.
## 7. Wire the data
The contract is in `templates/contract.md`: one envelope, `{event, data}`, in
both directions.
- **No bot yet:** keep `SAMPLE_DATA = true` and the `SAMPLE DATA` block. The page
answers its own data actions, so it opens with sample batches and report rows,
and Run plays a demo run. Tell the user which events their bot must send later.
- **Bot exists:** set `SAMPLE_DATA = false` and delete the `SAMPLE DATA` block. Then:
- Desktop: in `bridge.py`, set `BOT_CMD` to start the bot as a child process.
Fill `STEP_MARKERS` and `FRIENDLY_RULES` from lines the bot really prints. Use
specific substrings (for example `[step 3]`, not a bare word); the first match
wins. Unmatched error lines must always reach the log.
- Web: the backend serves `GET {API_BASE}/dashboard`, `GET {API_BASE}/run/status`
(returning `{running, events[]}`) and `POST {API_BASE}/<action-with-dashes>`.
- Apply the contract's derived rules: batch state from Pending plus date, and
report buckets from status.
## 8. Verify
Open the page. On desktop run the host; otherwise open the file or the served URL.
With sample data, opening the file in a browser is enough. Check:
- the light theme, the dark theme (use the toggle), and a window 820px wide or less;
- KPI cards, donut and legend, the Run tab's steps and log, and the Report tab's
rows and pills all show data;
- no `{{` placeholders are left and the console shows no script errors.
If Python Playwright is installed, take headless screenshots of each check and
look at them. Otherwise, ask the user to open the page. Finish by telling the user
where the files are, which theme and sections were built, and whether the page is
on sample data or wired to the bot.