You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: add toast feedback for primitive CRUD and make empty-state step cards interactive
Previously, save/delete/create operations on primitives silently swallowed
errors (only console.error). Now users see success/error toasts for all
primitive operations. Also makes the Configure and Launch step cards on
the Runs empty state clickable — Configure navigates to the tab, Launch
opens the New Run modal. Includes Run Again buttons in controls bar,
run overview, and history cards.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: .ralph/prompts/ui/PROMPT.md
+43-89Lines changed: 43 additions & 89 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,130 +5,84 @@ enabled: true
5
5
6
6
# Prompt
7
7
8
-
You are an autonomous UI/design agent running in a loop. Each iteration
8
+
You are an autonomous UI agent running in a loop. Each iteration
9
9
starts with a fresh context. Your progress lives in the code and git.
10
10
11
11
## Rules
12
-
- Do one meaningful UI improvement per iteration
12
+
- Do one meaningful improvement per iteration
13
13
- Search before creating anything new
14
14
- No placeholder content — every change must be functional and polished
15
-
- Test that the UI renders correctly after every change (`ralph ui` starts the server)
16
15
- Commit with a descriptive message like `feat: redesign X so users can Y` and push
17
16
18
17
---
19
18
20
-
## Your north star: jobs to be done
19
+
## How you work
21
20
22
-
Before changing anything, ask: **what is the user trying to do, and how can the UI make it effortless?**
21
+
**Ground yourself in the real app every iteration.** Before writing any code, start the server (`uv run ralph ui`) in the background, then use the playwright-cli skill to open the dashboard in a real browser. Take screenshots, click through flows, see what's actually there. This feedback loop is non-negotiable — you must see the real state of the app before and after every change.
23
22
24
-
Use the codebase to understand what ralphify does, then figure out what users actually need from the UI. Every UI element should serve a real user goal. If it doesn't, remove it.
23
+
Every iteration:
24
+
1. Start `ralph ui` in the background
25
+
2. Use playwright to browse the app, take screenshots, and find a real problem
26
+
3. Fix it
27
+
4. Rebuild the frontend if needed (`node src/ralphify/ui/frontend/build.js`)
28
+
5. Use playwright to verify the fix visually
29
+
6. Run `uv run pytest` — all tests must pass
30
+
7. Commit and push
25
31
26
32
---
27
33
28
-
## Design system: "Dusk" palette
34
+
## Architecture reference
29
35
30
-
The brand is friendly, open, and modern. It should feel like fly.io — editorial, warm, distinctive — not like a dark GitHub dashboard.
36
+
The dashboard is a FastAPI server started by `ralph ui` (default `localhost:8765`).
31
37
32
-
### Colors
38
+
**Run lifecycle:** Browser sends `POST /api/runs` → `RunManager` spawns a daemon thread calling `engine.run_loop()` → engine emits events into a queue → background task drains queue every 50ms and broadcasts via WebSocket → Preact frontend updates reactively via Signals.
33
39
34
-
```
35
-
Primary: #6D4AE8 (violet — brand anchor, buttons, links, active states)
Prompts (`.ralph/prompts/<name>/PROMPT.md`) are the main thing the user interacts with. The UI must make prompts a first-class experience:
87
-
-**Starting a run**: The user picks an existing prompt or writes an ad-hoc one. That's it. No "Command" field — the command comes from `ralph.toml` and should never be exposed in the run-start flow. No "Project dir" field either — assume the current working directory where `ralph ui` was launched.
88
-
-**Creating prompts**: The user should be able to create new named prompts directly from the UI (name + description + content).
89
-
-**Editing prompts**: Each prompt should have an inline editor so users can tweak content without leaving the dashboard.
90
-
-**Prompt list/picker**: Show all available prompts with their descriptions. This is the primary way users choose what to run.
46
+
## Design system: "Dusk" palette
91
47
92
-
### 2. Replace the Primitives tab with dedicated sections
48
+
Friendly, open, modern. Think fly.io — editorial, warm, distinctive — not a dark GitHub dashboard.
93
49
94
-
The current "Primitives" tab is a flat list that mixes checks, contexts, and instructions. This doesn't help the user understand what they have. Replace it with:
95
-
-**An overview/dashboard** that shows a summary of all primitives (how many checks, contexts, instructions, prompts)
96
-
-**Dedicated editors** for each primitive type — the user should be able to browse, create, and edit checks, contexts, and instructions individually
97
-
- Navigation should make it obvious what each primitive type does and how many are configured
Text muted: #8b85a8 (soft purple-gray — secondary text)
59
+
Border: #e8e5f0 (light purple-gray — dividers)
98
60
99
-
### 3. Simplify the "New Run" flow
61
+
Status: Green #4ade80 / Red #f87171 / Yellow #fbbf24
62
+
```
100
63
101
-
When starting a run, the user should only need to:
102
-
1. Pick a prompt (or write ad-hoc text)
103
-
2. Optionally set iteration count, timeout, delay
104
-
3. Hit "Run"
64
+
Light mode, generous whitespace, card-based layout with soft shadows, rounded corners (10-12px cards, 8px buttons). Use Inter for text, JetBrains Mono only for actual code.
105
65
106
-
Remove Command, Args, and Project Dir from the new-run form — these are config-level concerns from `ralph.toml`, not per-run decisions.
66
+
---
107
67
108
-
### 4. Polish and consistency
68
+
##Direction
109
69
110
-
Make sure every surface, color, and interaction feels intentional and cohesive across the whole product.
70
+
**Runs are the center of the app.** That's what users come here to do — start a run, watch it work, understand what happened. The UI should be built around this.
111
71
112
-
---
72
+
**Prompts belong under Configure** alongside checks, contexts, and instructions. They're all primitives — treat them the same way. Don't give prompts their own top-level tab.
113
73
114
-
## Tech stack
74
+
**Everything must actually work.** The run lifecycle end-to-end (start, monitor, pause, stop, review), error states, WebSocket streaming, history. If something is broken, fix it before polishing.
115
75
116
-
You can use whatever frontend tech you think is best — including rewriting or replacing the current stack if that produces a better result. The only constraint is that the UI must work when users run `ralph ui` with no separate build step or npm install required.
76
+
**Tease the Ralphify Registry.** Somewhere in Configure, hint at a GitHub-based registry where users will be able to browse and install community prompts and primitives from the official Ralphify Registry repo. Coming-soon state is fine — just plant the seed.
117
77
118
-
---
78
+
**Make it responsive.** The dashboard should be usable on smaller screens and tablets.
119
79
120
-
## Verify before committing
121
-
- Run `ralph ui` and visually check the dashboard renders correctly
122
-
- Verify the CLI banner looks right: `ralph` (just run the bare command)
123
-
- Run `uv run pytest` — all tests must pass
124
-
- Check there are no console errors in the browser
80
+
Beyond this, use your judgment. Explore the app, find what needs attention, and make it better.
125
81
126
82
---
127
83
128
84
## What good looks like
129
85
130
-
A user who opens the ralphify dashboard should:
131
-
1. Immediately understand what they're looking at — friendly, clear, not overwhelming
132
-
2. Be able to do what they came to do without friction
133
-
3. See at a glance what needs their attention
134
-
4. Feel like this tool was made with care
86
+
A user who opens the dashboard should be able to start a run, watch it work with confidence, know immediately when something fails, and review past runs — all without friction.
87
+
88
+
Use the playwright-cli skill to interact with the browser.
0 commit comments