QUICK START · THREE STAGES
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.
Your first certified dashboard
One export in, one dashboard out, where every figure reconciles to a total the file itself asserts, and anything unprovable says so on the page.
Prompt 1 · land the data properly
Here is a raw export from my business: [drag the file in]. Before any analysis: create a landing zone at data/raw/ and archive this file there, named YYYY-MM-DD__<source>.<ext> using the file's own as-of date, never today's date, and warn me if you can't prove the as-of date from the file's contents. Raw files are never edited and never overwritten; a re-drop of the same name gets a new name. Then, using the anchor-discovery and hostile-exports skills, tell me: what does this file assert about itself (totals rows, stated windows, bases), and what are its traps?
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 labelled UNPROVEN, 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 at least one honest UNPROVEN if your file doesn't prove everything. That label is the product working.
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.
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.
Stage 1 works with the free skill alone (charts + honesty basics). Stages 2 and 3 lean on the full pack, anchor-discovery, hostile-exports, verification-practice, and secure-intranet ship in Everything.