Snagline

A mock-up of the homepage, drawn from this design’s layout, palette and typefaces. A build follows the full prompt below.

Start from this templateRead the build prompt

Typefaces

Geist with its own mono is already a distinctive engineering pair that few templates use, and it is exactly the precise, medium-weight voice this tool needs.

• GeistHeadings: display 48-52px medium at -0.04em
• GeistBody: body 16px, dense issue rows 15px
• Geist MonoFigures and code: issue IDs, keys and timestamps

Who it is for

• Small engineering teams
• QA engineers running test cycles
• Agency developers juggling client projects
• Startups needing a simple triage flow

Layout

1. Minimal top bar: stacked-lines logo + uppercase wordmark (short, 0.08em tracking) left; theme toggle, 'Log in' text and outlined 'Sign up' button right
2. Split hero: large two-line headline and grey subcopy left, rectangular light CTA with arrow; wireframe isometric line-art blocks top right
3. Full-width stylized product mock: sidebar, issue list with IDs (SNG-###), colored priority squares and status dots, detail panel with status/priority/assignee/due
4. Feature trio (priority triage, team workflows, real-time analytics)
5. Testimonial card on diagonal-hatched band
6. Closing CTA with outlined button
7. App: bug submission form, dashboard with status tabs, bug detail, analytics

Palette

precise, dark, engineered, no-nonsense, quiet. Engineering-tool minimalism with technical line-art texture.

• background#0e0e10
• card#161618
• text#e6e6e6
• primary slate#7c8a9c
• critical red#e5484d
• in-progress amber#f5a524
• resolved green#30d158

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.

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

Type scale

Display

Geist Medium 51px, -2px tracking; H2 38px

Body

Geist 16px body; 15px in dense issue rows; issue IDs in Geist Mono

Geist sans with a mono companion gives it an engineering-tool precision; weights stay medium rather than bold.

Spacing and imagery

Left-aligned 1200px container, square-edged buttons (0 radius) and hairline borders, dense 36px list rows, 6px radius on app panels.

Isometric wireframe line-art blocks, diagonal hatch patterns, and an abstracted product UI mock with placeholder bars; one small avatar on the testimonial.

Components

• Top bar with theme toggle
• Split hero with line-art
• Abstract product mock
• Feature trio
• Hatched testimonial band
• Bug submission form
• Severity selector (critical/high/medium/low)
• Status tabs (open/in progress/resolved)
• Issue list row with ID, severity square, status dot, assignee avatar
• Detail side panel
• Assignee picker
• Analytics charts (severity, status, daily trend)
• Audit trail timeline

Interactions

• Form validation with required fields and inline errors
• Auto-generated tracking ID on submit with toast
• Real-time list updates when others change bugs
• Filter by severity, sort by date
• Status tabs switch views
• Assign/reassign with optimistic update
• Hover row highlight with hatch pattern
• Light/dark toggle

Data

• Bug{id, key 'SNG-###', title, severity, status open|in_progress|resolved, steps_to_reproduce, expected, actual, environment{browser, os, version}, reporter_id, assignee_id, due_at, created_at, resolved_at}
• BugEvent{id, bug_id, actor_id, kind, from, to, created_at}
• Profile{id, name, avatar_url, role reporter|engineer|admin}
• Comment{id, bug_id, author_id, body, created_at}

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 **Snagline**, a focused bug-tracking app for small engineering and QA teams. Anyone on the team files a structured report; engineers triage by severity, assign an owner, and move the bug through open, in progress and resolved, while a small analytics view shows trends. The aim is disciplined intake with minimal process.

### Stack
React 18 + TypeScript + Vite, Tailwind CSS, shadcn/ui (Radix: Tabs, Select, Popover, Sheet, Dialog) and lucide-react. Use react-hook-form + zod for the report form, TanStack Query for data, TanStack Table for the list, Recharts for analytics and date-fns for ages and due dates. Use Supabase for Auth (email), Postgres for bugs, events and comments, Realtime subscriptions for live list updates, and a Postgres sequence or trigger to generate readable keys.

### Pages & layout
1. **Landing**:
   - Top bar: logo, theme toggle, Log in, and an outlined Sign up.
   - Left-aligned hero: a large two-line headline, subcopy and a square light CTA, with isometric wireframe line-art on the right.
   - An abstract product mock (sidebar, issue rows with keys and colored markers, a detail panel).
   - Three feature columns, a quote card on a diagonal-hatched band, and a closing CTA.
2. **Report a bug**: title, severity (4 options with descriptions), steps to reproduce, expected vs actual side by side, environment (browser, OS, app version) and an optional attachment link.
3. **Dashboard**: status tabs with counts, a severity filter, sort by date, and dense issue rows (key, title, severity square, status dot, assignee avatar, age).
4. **Bug detail** (side sheet): fields, assignee, due date, comments and an audit trail.
5. **Analytics**: severity distribution, status breakdown, daily opened-vs-resolved, median time to resolve.

### Design system
- Dark: `--background: #0e0e10`, `--card: #161618`, `--foreground: #e6e6e6`, `--primary: #7c8a9c`, `--muted: #222225`, `--border: #404045` (decorative hairlines), `--input-border: #67676f`.
- Light: `#fafafa` background, `#18181b` text, slate primary deepened to `#657385`, `--input-border: #8a8c97`; markers switch to high `#ed5f08`, medium `#c47c09`, low `#8a8c97`, resolved `#24a043`.
- Severity: critical `#e5484d`, high `#f76b15`, medium `#f5a524`, low `#8b8d98`. Status: open `#8b8d98`, in progress `#f5a524`, resolved `#30d158`.
- Fonts: Geist (UI) and Geist Mono (keys, timestamps). Display 48-52px medium at -0.04em, body 16px (line-height 1.5), dense issue rows 15px, nothing below 12px.
- Spacing on a 4px base; list rows 36px.
- Radius: 0 on marketing buttons, 6px in-app.
- Shadows: none; hairline borders and hatch patterns (`repeating-linear-gradient`) for texture.
- Motion: 120ms hover, 200ms sheet slide.

### Components & interactions
ReportForm (inline errors, disabled submit while pending, success toast showing the new key), SeveritySelect (radio cards), StatusTabs (count badges), IssueRow (hover, selected, focus), Filters (clear-all), AssigneePicker (search, unassigned state), DetailSheet (loading skeleton, not-found error), CommentBox (empty state), AuditTrail, AnalyticsCharts (empty state for new teams), ThemeToggle. Realtime changes animate the affected row briefly.

### Data & state
`bugs(id, key, title, severity, status, steps, expected, actual, env jsonb, reporter_id, assignee_id, due_at, created_at, resolved_at)`, `bug_events(id, bug_id, actor_id, kind, from_value, to_value, created_at)` written by a trigger on update, `comments(id, bug_id, author_id, body, created_at)` and `profiles(id, name, role)`. Keep filters in URL params. Seed about 30 bugs for a fictional app, with invented teammates.

### Accessibility
Never use color alone for severity and status: pair each marker with a text label or icon. Slate `#7c8a9c` passes as text on `#0e0e10` (5.5:1); in light mode use `#657385`. Every form field has a label and hint text, and errors are announced. The side sheet traps focus. Charts include table alternatives. Theme toggle state is exposed with `aria-pressed`.
Verified contrast: body: #e6e6e6 on #0e0e10 = 15.5:1; slate: #7c8a9c on #0e0e10 = 5.5:1; light body: #18181b on #fafafa = 17.0:1.

### Security
RLS: authenticated team members can read bugs; reporters can insert; only assignees, engineers or admins can update status; only admins delete. Store roles in a separate table and check them in policies. Validate every field with zod on the client and with DB constraints (enums, length limits). Render comments and steps as plain text or sanitized markdown (DOMPurify). If attachments are added, use a private bucket with signed URLs, MIME and size limits. Rate-limit report submission.

### Performance & SEO
Split the landing page from the app. Virtualize long lists. Index `status`, `severity` and `created_at`. Add meta/OG tags on the landing page; noindex the app. Target Lighthouse 90+.

### Guardrails
- Write fresh copy and illustrations; the mock uses fictional keys and names.
- Mark sample quotes as illustrative.
- Collect only the environment details the team needs.
- Keep components small and typed; no `any`. Show errors visibly.
- Done when: (1) submitting creates a keyed bug visible live to other sessions; (2) severity and status filters combine correctly; (3) every change is logged in the audit trail; (4) RLS enforces role rules; (5) analytics match the underlying data.

Open the builderAll templatesThis palette on its own