From one export to your own BI intranet.

Copy these prompts into Claude Code, in order. Each stage ends with something running. The prompts bake in the lessons a production build learned the hard way, so you skip the expensive detours.

Before stage one: unzip your download. Then either open that folder in Claude Code and say install Kymira (the folder tells it exactly what to do), or double-click the installer for your system (For Mac, Install Kymira or For Windows, Install Kymira). When it asks, paste the license key from your receipt: the key registers this machine and unlocks kymira update; the skills themselves are plain text and work without it. Then open Claude Code in an empty project folder with one real export handy, your ugliest one is the best teacher. Stage one starts by building the workspace, so an empty folder is exactly right.

Your first certified dashboard

One export in, one dashboard out, where every figure reconciles to a total the file itself asserts, and anything it cannot prove is caught before it ships.

Prompt 0 · stand up the workspace

Using the workspace-architecture skill, set this folder up before we build anything. Create the layout and tell me what each boundary is protecting. Register my exports as a source so you can pull fresh ones out of my Downloads folder yourself, and show me the safety rules you are working under. Then write me the roadmap: every step from these raw files to an intranet my team uses, with the steps only I can do listed first and everything else marked by whether it runs itself.

Prompt 1 · land the data properly

Here is a raw export from my business: [drag it in, or just download it and let the intake loop find it]. Land it per the workspace-architecture and trust-the-upload skills, then, using anchor-discovery and hostile-exports, tell me: what does this file assert about itself (totals rows, stated windows, bases), and what are its traps? If its filename claims a period its contents do not support, say so instead of picking one.

Prompt 2 · build with verification on

Now build me a single-file HTML dashboard from that export, using the report-design, honest-dataviz and verification-practice skills. Rules: every figure must reconcile to a total the file itself asserts, shown in a CHECKS panel; anything that can't be proven is caught and held back, never silently dropped, never guessed. Compute every number in code I can re-run, never type a number into the page by hand. When you think you're done, verify the page in a headless browser and show me a screenshot before you call it finished.

You should see: a dashboard with a CHECKS panel where the ties are green, and any figure the file does not prove named on the page, not shipped as fact.

Why these prompts are shaped this way: the production build this method comes from learned that dashboards with hand-pasted numbers rot silently, that un-archived drops mean no trend lines later, and that a page nobody rendered in a browser ships invisible defects. Each rule above closes one of those.

A reporting system, not a file

The difference between a dashboard and BI: the second drop. Separate the layers now, landing, data, site, so every future refresh is one command instead of a rebuild.

Prompt 3 · four layers and a refresh entrypoint

Restructure this project into four layers, per the secure-intranet skill: data/raw/<cadence>/ (drop zone, archived forever) → data/processed/ (tidy JSON, one file per domain) → site/ (each page is template + data, inlined at build so pages stay single-file) → publish. Then build refresh.py <cadence>: detect the newest drop → validate (schema + reconcile to the file's own totals) → extract → rebuild affected pages → verify in a headless browser → update manifest.json. Every extractor writes a manifest entry: source file, as-of date, row counts, validation results. Anything judgment-shaped pauses with a named todo and its own exit code, the runner never auto-publishes judgment.

Prompt 4 · the freshness panel + more reports

Add a home page: a hub in the style of the Kymira intranet template, with a data-status panel fed ONLY by manifest.json (nothing typed by hand): each source's as-of date, row counts, check results, and what's overdue based on its cadence. Then add my second report: [describe it, e.g. "weekly sell-through from these retailer exports"]. Same rules as before. If my planning workbook is involved: treat it as READ-ONLY, extract from it, never write to it, spreadsheet round-trips destroy live workbooks.

You should see: a hub page whose freshness panel updates itself, and a second report that cost a fraction of the first, that's the layers paying rent.

Gap this closes: the single most expensive failure in real reporting stacks is data, transformation and presentation welded together, every refresh a bespoke editing session. The four layers and the manifest are the fix, and they cost least when installed second, not tenth.

The intranet, secure, persistent, collaborative

The superpower: one internal site where every report lives, behind a real auth wall, with shared state your whole team sees update live. This is where the secure-intranet skill earns its keep.

Prompt 5 · auth wall BEFORE real data goes live

Time to publish this as our internal BI site on Cloudflare, using the secure-intranet skill. Structure: ONE site with audience zones (internal/ now; clients/<slug>/ ready for later), audiences separated by the AUTH layer, never by the build. Set up Cloudflare Pages + Access: a default-deny catch-all at /, one Access application per zone, One-time PIN login enabled, allow-list policies in a versioned policies.json with a validator that fails on placeholders. Ship _headers with the strict self-only CSP from the skill. The auth wall goes live BEFORE any real company number does, walk me through the Cloudflare dashboard steps I must do by hand, then verify headers and the login wall from outside.

Prompt 6 · shared live state (the collaboration pattern)

Add shared team state using the secure-intranet skill's collaboration pattern: one D1 table per feature (idempotent schema.sql), one role-gated route on the auth worker (identity from the Access JWT, reached via the site's /api/* proxy, fail closed on anonymous), pages that fetch on load then poll ~5s with the skill's sync rules (skip while writing or hidden, never re-render a focused field, controls disabled until the store answers). Pick the right coupling: bake+patch for simple values, pure shell for anything user-authored, never bake user content. Notes append-only; soft-delete only; audit consequential writes with actor + payload. Start with: [e.g. "a team initiatives board" or "flagging outlier orders out of the current-month cards"]. Then run the skill's pre-launch gate end to end and show me the results, including the backup/restore rehearsal.

You should see: an intranet only your team can reach, reports that refresh on a drop, and a shared board that updates for everyone and survives rebuilds. That's a BI platform, you own it outright.

Gap this closes: real builds bolt auth on late and discover their "internal" site was public for a month; rate-limiters silently fail open without a KV binding; backups exist but restores were never rehearsed. The skill's pre-launch gate checks all of it before an outside user ever logs in.

Get the skills →

Stage 1 uses the free dataviz skill plus four Core craft skills: anchor-discovery, hostile-exports, report-design and verification-practice. Stages 2 and 3 lean on secure-intranet and the intranet template, which ship in Everything. Prefer the story to the prompts? Your first week, day by day.