- 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>
133 lines
7.5 KiB
Markdown
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.
|