Plainask

Who it is for

• Data teams overloaded with ad-hoc requests
• Heads of data enabling governed self-serve
• Finance and operations analysts
• Business teams (sales, marketing, support, product) who don't write SQL

Layout

1. Landing: black canvas with soft rose-to-navy gradient bands at the top and bottom edges, a short product statement and a sign-in card
2. Onboarding flow: connect warehouse, scope datasets/tables/fields, add business context, review and approve AI-drafted metrics, publish
3. Chat with data: question input, answer with chart/table, 'based on metric X' citation and SQL disclosure
4. Dashboard builder: tiles bound to approved metrics, dynamic filters, embedded chat
5. Control panel: usage and query logs, cost caps per query/day, kill switch, metric editor, evals runner

Palette

sleek, trustworthy, controlled, modern, calm. A dark gradient front door leading into a neutral slate workspace.

• background#000000
• gradient edge rose#9a5670
• gradient edge slate blue#56709e
• light app background#ffffff
• primary slate#0f172b
• muted surface#f1f5f9
• border#e2e8f0

Every checked pair, measured again

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

Display

Inter SemiBold 28-40px headings, sentence case

Body

Inter 16px at line-height 1.5; JetBrains Mono for SQL and figures

A neutral sans with a mono companion for SQL keeps attention on the data and its provenance.

Spacing and imagery

Standard slate system on a 4px base: 10px card radius, 6px inputs, roomy chat column, dashboard grid with 16-24px gutters.

Soft rose and slate-blue gradient glows at the page edges; inside the app, charts and tables carry the visuals.

Components

• Warehouse connection wizard
• Dataset/table/field scoping tree
• Business context input (text or document upload)
• AI-drafted metric definitions review list
• Metric detail with SQL, test results and approve/reject
• Chat-with-data interface with citations
• Answer chart/table renderer
• Dashboard builder with metric-bound tiles and filters
• Embedded dashboard chatbot
• Control panel usage and query logs
• Cost cap settings and kill switch
• Evals test set runner with scores
• Publish-as-connector settings
• Access/invite management

Interactions

• Step-by-step onboarding with validation gates
• Toggle datasets and fields on or off for exposure
• Approve, edit or reject drafted metrics after seeing test results
• Ask questions in natural language; expand to see definition and SQL
• Add a tile from an answer to a dashboard
• Apply dynamic filters across tiles
• Run evals and compare accuracy over time
• Hit the kill switch to pause all queries

Data

• Connection{id, org_id, warehouse_type, config (secret ref), status}
• ScopeItem{connection_id, dataset, table, column, exposed}
• BusinessContext{org_id, text, document_path?}
• Metric{id, org_id, name, description, sql, grain, dimensions[], status draft|approved|rejected, tested_at, test_result}
• Question{id, user_id, text, metric_ids[], sql, row_count, cost, created_at}
• Dashboard{id, owner_id, title, tiles[{metric_id, viz, filters}]}
• EvalCase{id, question, expected}
• EvalRun{id, judge_model, score, created_at}
• Limits{org_id, per_query_cost_cap, daily_cost_cap, paused}

Build prompt

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

Copy the baseline and build prompt

### How to use these prompts
Paste a template'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 templates)
- 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.

### Goal
Build **Plainask**, a governed self-service analytics app. A data team connects a warehouse, chooses exactly which data is exposed, and approves metric definitions drafted by an AI agent. Business users then ask questions in plain English and build live dashboards, and every number they see traces back to an approved definition.

### Stack
React 18 + TypeScript + Vite, Tailwind CSS, shadcn/ui (Radix: Stepper-like Tabs, Tree/Collapsible, Dialog, Sheet, Command) and lucide-react. Use TanStack Query and Table, Recharts for answer visualizations and dashboard tiles, react-hook-form + zod, CodeMirror (read-only SQL viewer) and react-grid-layout for dashboards. Supabase provides:
- Auth with invite-only org membership.
- Postgres for configuration, metrics, dashboards, logs and evals; no warehouse data is stored.
- Vault or Edge Function secrets for warehouse credentials.
- Edge Functions: warehouse connector (read-only queries), metric drafting and testing, NL-to-metric query planning, and the eval runner.
LLM calls happen only server-side.

### Pages & layout
1. **Landing / sign-in**: a dark canvas with soft rose and slate-blue gradient glows at the edges, a short product statement and a sign-in card.
2. **Onboarding** (for admins): connect a warehouse (type, credentials and a connection test), scope datasets, tables and columns in a tree, add business context (text or upload), review drafted metrics (definition, SQL, test result, approve/edit/reject), then publish.
3. **Ask**: a chat thread where each answer shows a chart or table, the metric(s) used, an expandable SQL block and an "Add to dashboard" action.
4. **Dashboards**: a grid of metric-bound tiles, global filters and an embedded chat.
5. **Control panel** (for admins): usage, query log with cost, per-query and daily caps, a kill switch, the metric library and editor, evals (test set, judge model, scores over time), and members.

### Design system
- Dark shell: `--background: #000000`, glow gradients `#9a5670` → transparent and `#56709e` → transparent.
- App surfaces (light): `--background: #ffffff`, `--foreground: #020618`, `--primary: #0f172b`, `--muted: #f1f5f9`, `--muted-fg: #5f6e84`, `--border: #e2e8f0` (decorative), `--input-border: #7591b7`, `--ring: #7d91ad`.
- Status colors: approved green, draft amber, rejected red, paused slate.
- Fonts: Inter for UI, JetBrains Mono for SQL and figures. Scale 12/14/16/20/28/40; body 16px at line-height 1.5, 75ch max.
- Spacing on a 4px base; radius 10px on cards, 6px on inputs.
- Motion: 150-200ms.

### Components & interactions
ConnectionForm (test with success/failure detail; secrets masked), ScopeTree (tri-state checkboxes, search), ContextEditor, MetricReviewCard (approve, edit, reject; failing test blocks approval), ChatThread (streaming, "no approved metric covers this" fallback, error and retry), AnswerViz (auto chart type, switchable; table toggle), SqlDisclosure, DashboardGrid (drag and resize; tile loading and error), FilterBar, UsageTable, CostCapForm, KillSwitch (confirm dialog; banner when paused), EvalRunner (progress, per-case pass/fail).

### Data & state
Tables as in the data model, plus `org_members(org_id, user_id, role admin|analyst|viewer)`. Queries always go through approved metrics: the planner maps a question to metric + dimensions + filters, and generated SQL is templated from the metric definition (never free-form) and executed read-only with row and time limits. Log each query with its cost estimate.

### Accessibility
Landing text is white on solid black (21:1) and never sits on the decorative gradient glows. The scope tree follows the tree keyboard pattern. The chat log is a live region. Every chart has a table alternative and a text summary. Dashboard drag and resize needs keyboard alternatives (move and size controls). The kill switch uses a clear label and a confirmation.
Verified contrast: landing: #ffffff on #000000 = 21.0:1; body: #020618 on #ffffff = 20.2:1; muted: #5f6e84 on #ffffff = 5.2:1; white on primary: #ffffff on #0f172b = 17.8:1.

### Security
RLS by org and role: only admins manage connections, scope, metrics, caps and evals; analysts and viewers query approved metrics only. Warehouse credentials live only in server-side secrets and are never returned to the client. The connector uses read-only roles and allow-listed schemas, with statement timeouts, row limits and cost caps enforced server-side. Validate every request with zod. Treat prompt injection in business context or data values as untrusted, and never let model output execute arbitrary SQL. Rate-limit per user.

### Performance & SEO
Cache metric results briefly by (metric, filters) and stream answers. Lazy-load CodeMirror, the grid and charts. Noindex everything except a simple landing page with title and meta.

### Guardrails
- Write fresh copy; name no real warehouses or chat products in the UI beyond generic connector types.
- Use fictional sample data.
- Don't present unapproved metrics as official.
- Keep components small and typed; no `any`. Show query and cost errors visibly.
- Done when: (1) onboarding connects, scopes and approves at least three metrics; (2) every answer cites its metric and SQL; (3) caps and the kill switch block queries server-side; (4) viewers cannot reach admin screens or unscoped data; (5) an eval run produces a score.

Open the builderAll templatesThis palette on its own