Skip to main content
vibld

Template

Pipewright

The editor for a new workflow in an AI agent automation platform. A workflow starts as just a Start node (inputs) and an End node (outputs); users add steps between them, configure each step, run it, and save versions. The canvas makes the data flow legible to developers and ops users alike.

Visual workflow builder canvas for AI agents · App screen: flowchart · Small tools and apps · full-stack app (auth + DB)

A mock-up of the screen, drawn from its layout, palette and typefaces. A build follows the full prompt below.

Start from this screenRead the build prompt

Typefaces

The catalog's own faces. A screen composed into a template is drawn in that template's typefaces.

  • InterHeadings: Inter 600, 16px node titles; 18px header name
  • InterBody: Inter 400 14px in nodes, 16px in inspector forms

Patterns

  • node canvas with start and end nodes
  • coloured node headers by role
  • inline '+ Add step' connector button
  • floating zoom and pan toolbar
  • breadcrumb + version badge editor header
  • tabbed editor modes (model, retries, triggers, editor, evals)
  • split Save button with menu
  • side annotations next to nodes

States it is designed for

  • new workflow (only Start and End)
  • unsaved changes (dot on Save)
  • saving / saved with version bump
  • run in progress
  • run failed at a node (red outline + error in inspector)
  • validation errors (missing output mapping) listed in a banner
  • read-only on small screens or for viewers
  • load error with retry

Who it is for

  • developers building agent pipelines
  • automation engineers
  • technical product teams

Layout

  1. app sidebar (same as the rest of the app, Workflows active)
  2. top bar breadcrumb: org switcher / Workflows / workflow slug / Editor
  3. editor header row: workflow chip, version badge (v1.0.0), editable name, mode tabs (Model, Retries, Triggers, Editor active, Evals), then Runs, Run, overflow and a dark split Save button
  4. canvas fills the rest with a subtle dot grid; floating toolbar top-left (select/hand toggle, zoom out, reset, zoom in)
  5. Start node with violet gradient header and inputs list; '+ Add step' pill on the connector; End node with teal header and outputs list
  6. annotations to the right of nodes (how inputs are accessed; what the output returns) with a Connect link
  7. green Run pill to the left of Start
  8. right inspector slides in when a node is selected
  9. below 900px the canvas becomes read-only with a notice to edit on a larger screen

Palette

Precise and playful at once: a quiet grey workspace with two bright bookend nodes.

  • canvas#f5f5f5
  • node surface#ffffff
  • primary text#171717
  • secondary text#5c5c5c
  • start header#6d4be8
  • end header#0f7a5f
  • run pill#15803d
  • primary button (save)#1c1c1c
  • connector line#8e8e8e
  • dot grid#e2e2e2

Every checked pair, measured again

SampleWhereRatioNeeds
Aabody text17.93:14.5:1
Aamuted text on canvas6.13:14.5:1
Aastart header title5.49:14.5:1
Aaend header title5.29:14.5:1
Aarun pill label5.02:14.5:1
Aasave button label17.04:14.5:1
connector line3.01:13:1

As vibld’s tokens

The palette on the fifteen colour tokens vibld styles a project with, each text colour on the fill it is read on. Marked tokens are solved from the palette, because no swatch held that role at 4.5:1.

  • background
  • card
  • muted
  • primary
  • secondary
  • accent
  • destructive *

Type scale

Display
Inter 600, 16px node titles; 18px header name
Body
Inter 400 14px in nodes, 16px in inspector forms

Version badge and variable names in JetBrains Mono 12px; node titles on coloured headers 14px 600 white.

Spacing and imagery

Dense editor: header row 48px; nodes 240px wide, 12px radius, 1px #e2e2e2 border and 0 1px 2px shadow; node header 36px; 32px vertical gap between nodes; toolbar buttons 28px.

No imagery; colour-coded node headers, small lucide icons (play, check-circle, plus), dot grid background.

Components

  • EditorHeader (chip, version badge, name, mode tabs, actions)
  • Canvas with pan/zoom
  • ZoomToolbar
  • Node (header, body, add-row)
  • Edge with AddStepButton
  • Annotation
  • RunPill
  • NodeInspector drawer
  • StepPicker popover (LLM call, HTTP request, code, branch, human review)
  • SaveSplitButton (save, save as new version)

Interactions

  • drag canvas with space+drag or hand tool; wheel/pinch zoom 25–200%
  • '+ Add step' opens a searchable step picker and inserts the node in place
  • select a node to open the inspector; Delete removes (with undo toast)
  • drag nodes to reorder within the linear chain (dnd-kit)
  • Cmd/Ctrl+S saves; Cmd/Ctrl+Enter runs
  • Run shows per-node status badges (running spinner, success tick, error)

Data

  • Workflow{id, org_id, slug, name, current_version_id}
  • WorkflowVersion{id, workflow_id, semver, graph jsonb (nodes, edges), created_by, created_at}
  • Node{id, type (start|end|llm|http|code|branch|review), config jsonb, position}
  • Run{id, workflow_version_id, status (queued|running|succeeded|failed), inputs jsonb, outputs jsonb, started_at, finished_at}
  • NodeRun{id, run_id, node_id, status, output jsonb, error}

Guardrails

Experience

  • Always keep Start and End on the canvas; they cannot be deleted.
  • Explain inputs and outputs next to the bookend nodes in plain words.
  • Put the insertion point on the edge itself so users add steps where they look.
  • Save creates an immutable version; show the version in the header.
  • Keep canvas controls in one floating toolbar with tooltips and shortcuts.

Accessibility

  • Provide an outline view (ordered list of steps) that is fully keyboard editable as an alternative to the canvas.
  • Nodes are focusable with arrow keys between them and Enter to open the inspector.
  • Status is shown with icon + text, not only colour.
  • White titles on node headers meet 4.5:1.
  • Zoom buttons have labels and the zoom level is announced.

Security

  • RLS: workflows, versions and runs scoped to org members; editors write, viewers read.
  • Validate the graph server-side (single start/end, no cycles, known node types, config schemas) before saving or running.
  • Secrets referenced by nodes are stored server-side and injected at run time, never in the graph JSON.
  • Sandbox code nodes and rate-limit runs per org.

Build prompt

The baseline every prompt in the catalog assumes, then this design’s own ten sections, from goal to guardrails.

The baseline
### How to use these prompts
Paste an entry's build prompt into your coding agent as the first message. Each prompt names its own stack, tokens and acceptance criteria; the rules below apply to all of them and can be prepended once per project.

### Engineering baseline
- TypeScript strict mode, no `any`, small typed components, feature folders, and one source of truth for design tokens (CSS variables consumed by Tailwind).
- Validate every input with a shared zod schema on the client and again on the server or edge function. Never trust client-side checks alone.
- Show loading, empty and error states for every async view. Surface errors in plain language with a retry, and log details to the console in development only.
- Keep secrets out of the bundle. Only publishable keys (for example a Supabase anon key) belong in client code; service-role keys, API keys and webhooks live in server or edge-function environment variables.

### Data and auth baseline (full-stack entries)
- Enable Row Level Security on every table before inserting data. Default-deny, then add owner-scoped policies (`auth.uid() = user_id`) and explicit role checks for admin views.
- Store roles in a separate table checked by a security-definer function, never in a user-editable profile field.
- Upload files to private storage buckets with size and MIME limits, and serve them through signed URLs.
- Rate-limit public endpoints (forms, auth, AI calls) and add a honeypot field or captcha to anonymous forms.
- Take payments through a hosted checkout and verify webhooks by signature. Never handle raw card data.

### Accessibility and UX baseline
- Target WCAG 2.2 AA: 4.5:1 contrast for normal text and 3:1 for large text, input borders, focus rings and meaningful icons or chart lines. Every palette in this catalog lists its verified pairs; re-check with a contrast tool after any colour change.
- Keep body text at 16px or larger with 1.5 line height, nothing below 12px, no light weights under 24px, and uppercase only for short labels.
- Give every interactive element a visible focus ring, full keyboard support, semantic landmarks, labelled form fields, and alt text on meaningful images.
- Respect `prefers-reduced-motion` for every animation. Give drag-and-drop and carousels keyboard and button alternatives.
- Build mobile-first and test at 375px, 768px and 1280px.

### Content guardrails
- Use original copy, fictional sample data and placeholder or licensed imagery. Do not reuse another product's name, logo, screenshots or marketing text.
- Label demo testimonials and metrics as samples. Collect the minimum personal data the feature needs.

### SaaS screen baseline
- Design every screen for its full set of states: first-run empty, loading skeleton, partial data, error with retry, permission-denied, and success feedback. Each entry lists the states its screen needs.
- Keep destructive actions (delete, revoke, downgrade, remove member) behind a confirmation that names the object, and prefer undo over a second dialog where the action is reversible.
- Enforce authorisation on the server for every action a screen exposes. Hiding a button is not access control; check the role again in the API or RLS policy.
- Never show secrets (API keys, tokens) in full after creation. Show them once, then mask them, and offer rotate and revoke.
- Keep the app shell (navigation, workspace switcher, account menu) consistent across screens, and preserve filters, sort and scroll position when the user navigates back.
### Goal
Build **Pipewright**, the workflow editor for an AI agent automation platform. A new workflow opens with a Start node and an End node; users insert steps, configure them in an inspector, run the workflow with test inputs and save versions.

### Stack
React 18 + TypeScript + Vite, Tailwind CSS, shadcn/ui (Tabs, Popover, Command, Sheet, DropdownMenu), lucide-react, dnd-kit for reordering, Motion for inspector and node transitions, TanStack Query, react-hook-form + zod for node configs. Supabase Auth, Postgres, Realtime channel for run status, Edge Functions for validate/run.

### Pages & layout
1. **App shell** with sidebar (Workflows active).
2. **/workflows/:slug/editor**: header row, canvas, floating toolbar, inspector sheet.
3. **/workflows/:slug/runs**: run list with status and duration.
4. Outline view toggle for keyboard/screen-reader editing.

### Design system
- Colors: `--canvas: #f5f5f5` (canvas), `--node: #ffffff` (node surface), `--fg: #171717` (primary text), `--muted: #5c5c5c` (secondary text), `--start: #6d4be8` (start header), `--end: #0f7a5f` (end header), `--run: #15803d` (run pill), `--primary: #1c1c1c` (primary button (save)), `--edge: #8e8e8e` (connector line), `--grid: #e2e2e2` (dot grid).
- Fonts: Inter 600, 16px node titles; 18px header name for headings; Inter 400 14px in nodes, 16px in inspector forms for body. Version badge and variable names in JetBrains Mono 12px; node titles on coloured headers 14px 600 white.
- Spacing: Dense editor: header row 48px; nodes 240px wide, 12px radius, 1px #e2e2e2 border and 0 1px 2px shadow; node header 36px; 32px vertical gap between nodes; toolbar buttons 28px.
- Radius: 12px nodes, 8px buttons, full pills for Run and Add step.
- Shadows: nodes 0 1px 2px rgba(0,0,0,0.06); inspector 0 8px 24px.
- Motion: new node scales in 150ms; inspector slides 200ms; running node pulses its border (off under reduced motion).

### Components & interactions
EditorHeader, ModeTabs, SaveSplitButton, Canvas (CSS transform pan/zoom), ZoomToolbar, Node, Edge, AddStepButton, StepPicker, Annotation, RunPill, NodeInspector, OutlineView, RunStatusBadge.

Interactions: drag canvas with space+drag or hand tool; wheel/pinch zoom 25–200%; '+ Add step' opens a searchable step picker and inserts the node in place; select a node to open the inspector; Delete removes (with undo toast); drag nodes to reorder within the linear chain (dnd-kit); Cmd/Ctrl+S saves; Cmd/Ctrl+Enter runs; Run shows per-node status badges (running spinner, success tick, error).

States to build: new workflow (only Start and End); unsaved changes (dot on Save); saving / saved with version bump; run in progress; run failed at a node (red outline + error in inspector); validation errors (missing output mapping) listed in a banner; read-only on small screens or for viewers; load error with retry.

### Data & state
Graph state in a reducer with undo/redo (50 steps); dirty flag compares with the saved version. Runs subscribe to status updates by run id. Seed an org with one empty workflow and one five-step example.

Model: `Workflow{id, org_id, slug, name, current_version_id}`; `WorkflowVersion{id, workflow_id, semver, graph jsonb (nodes, edges), created_by, created_at}`; `Node{id, type (start|end|llm|http|code|branch|review), config jsonb, position}`; `Run{id, workflow_version_id, status (queued|running|succeeded|failed), inputs jsonb, outputs jsonb, started_at, finished_at}`; `NodeRun{id, run_id, node_id, status, output jsonb, error}`.

### Accessibility
Provide an outline view (ordered list of steps) that is fully keyboard editable as an alternative to the canvas. Nodes are focusable with arrow keys between them and Enter to open the inspector. Status is shown with icon + text, not only colour. White titles on node headers meet 4.5:1. Zoom buttons have labels and the zoom level is announced.
Verified contrast: body text: #171717 on #ffffff = 17.93:1; muted text on canvas: #5c5c5c on #f5f5f5 = 6.13:1; start header title: #ffffff on #6d4be8 = 5.49:1; end header title: #ffffff on #0f7a5f = 5.29:1; run pill label: #ffffff on #15803d = 5.02:1; save button label: #ffffff on #1c1c1c = 17.04:1; connector line: #8e8e8e on #f5f5f5 = 3.01:1.

### Security
RLS: workflows, versions and runs scoped to org members; editors write, viewers read. Validate the graph server-side (single start/end, no cycles, known node types, config schemas) before saving or running. Secrets referenced by nodes are stored server-side and injected at run time, never in the graph JSON. Sandbox code nodes and rate-limit runs per org. RLS per table: `workflows` and `workflow_versions` select for org members, insert/update for editors; `runs` and `node_runs` select for members, insert only via the run Edge Function, updates by service role.

### Performance & SEO
Render nodes as DOM (not canvas) up to ~200; memoise node components; throttle pan/zoom with requestAnimationFrame. Editor routes noindex.

### Guardrails
- Always keep Start and End on the canvas; they cannot be deleted.
- Explain inputs and outputs next to the bookend nodes in plain words.
- Put the insertion point on the edge itself so users add steps where they look.
- Save creates an immutable version; show the version in the header.
- Keep canvas controls in one floating toolbar with tooltips and shortcuts.
- Write all copy fresh; use invented people, companies and numbers only. No real brands, logos, wordmarks or third-party product names anywhere in the UI or seed data.
- Do not trace or copy any existing product's layout assets, icons or illustrations; draw generic ones.
- Acceptance criteria:
  - [ ] New workflow shows only Start and End
  - [ ] Adding, configuring, reordering and deleting steps works with undo
  - [ ] Save creates a new version and clears the dirty dot
  - [ ] A run shows per-node status and errors
  - [ ] The outline view allows full editing by keyboard

Open the builderAll templatesThis palette on its own