Please refer to the custom charts article here if you have not already.
Start with the data shape. Sketch the exact rows/columns, dimensions and measures, and any edge cases. Define the slots you’ll expose (and their types) to match that shape: standard charts have predictable slot contracts (for example, a bar chart typically needs a category dimension plus one or more measures, while a number box usually needs a single measure and an optional label), whereas highly custom visuals often require extra or different slots and options.
Respect the chart lifecycle: render, resize, and optionally buildQuery are the functions Luzmo calls.
Design the manifest as a contract: explicit slots, types and sensible defaults make your chart plug-and-play.
Test two ways: in the Builder and as a packaged upload.
Providing a screenshot or sample data always helps when crafting a custom chart. A quick image of the desired visual outcome plus a matching small JSON/CSV fixture lets vibecoders reproduce the look and behavior immediately.
Prompts such as “It is a variant of a bar chart, but I would like XYZ…” work well. Be explicit about what “XYZ” means (e.g., stacked by category, fixed axis range, annotation on hover), and include a tiny fixture that shows the exact columns and a few rows to cover normal, empty, and edge cases.
Practical tips
- Anonymize sensitive fields in shared fixtures (IDs, PII).
- Give a 1–2 sentence priority list (what must exist vs what’s “nice to have”) so the vibecoder knows whether to aim for a minimal prototype or a near-production implementation.
render, resize, buildQueryrender — always compute from the data you receive and re-render from scratch if needed. resize — debounce resizing, recompute scales, and respect devicePixelRatio for crisp canvas/SVG rendering. buildQuery (optional) — use it when you want to translate slot configuration and options into Luzmo Data API queries rather than requiring a fixed backend shape.These three are the main hooks Luzmo calls, so keep them clean and well-tested.
dimension or measure, mark required slots, and provide readable labels and defaults. manifest.json as clear as possible and ensure that all the types are supported. Note: LLMs can sometimes hallucinate unsupported types, so prefer explicitness.chart.css if you require special formatting and design. Make sure your CSS reads dashboard theme tokens so the chart adapts to light/dark modes and spacing rules.Works in Builder, fails when uploaded — check manifest correctness, asset paths, and third-party library loading order. Upload to a sandbox account and watch console logs.
Edge cases — always test empty datasets, single-row results, and very large numbers. Keep a minimal fixture for each case.
Analyze the query output — printing the actual query output the chart receives helps diagnose unexpected results.
render and resize buildQuery if you control queries from chart options chart.css Vibecoding is fast by design: prioritize quick feedback loops, guard rails (a clear manifest, small fixtures), and a final packaging validation. The combination of a tiny one-file prototype + a disciplined lifecycle implementation (render / resize / buildQuery) is the pattern that repeatedly saves time and support headaches.