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.

Before stage one: install the skills (each is a folder, the install guide ships with every tier, and the free skill works for a taste), open Claude Code in an empty project folder, and have one real export file handy, your ugliest one is the best teacher.

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 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 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.