Skills / Simple dashboard
Simple dashboard
Build a small dashboard over their real data. The three numbers that matter, updating when the data does. Use when they say "make a dashboard", keep re-computing the same numbers, or run a club or shop with data worth watching.
Use this skill. Nothing to install.
Don't have an agent? · Raw file: skills/simple-dashboard.md
Watch the first two minutes
This is how a dashboard session goes when someone keeps recomputing the same numbers by hand. Click through it.
Scripted example of a real session.
Three numbers doesn't sound like a dashboard
Three is the count that survives being checked next Tuesday. The skill's filter is blunt: for each number, say what you would do differently if it looked bad. A number with no answer gets cut, which is how "total rows logged" dies and "sign-ups still unconfirmed" survives. Big dashboards with twenty tiles get admired once and never opened again. If you run anything with data worth watching, you have the raw material:
What you end up with
A dashboard tab computed live from the data tab. For many people this tab is the finished product; a URL comes later only if a team should see it.
cash this term = SUMIFS(amount, date >= Jan 20) last sale = SUM of amounts on newest sale date unpaid dues = COUNTIF(members.paid, "no")
- Formulas only. A hand-typed dashboard number is a lie waiting to age. SUMIF, COUNTIF, and a date window cover almost everything.
- Definitions written down. "Cash this term" means one exact thing. When a number surprises you later, the definition is what you check first.
- One trend, honest. The number with a direction gets a small chart, drawn under chart-the-truth rules: labeled axis, honest baseline.
- Staleness confesses. The last-updated cell comes from the data itself. An abandoned dashboard announces that it is old instead of quietly showing stale truth.
Questions people actually ask
Does it have to be a website?
No. For many people the sheet tab is the finished product. A URL is worth it only when a team, a club, or your own phone home screen should see it; then the skill publishes the sheet and reads it from one static page on GitHub Pages.
What about privacy if I publish it?
A public URL means public data. If rows contain other people's names or money details, keep it as a tab or publish only the aggregated numbers. The skill checks this before anything goes live.
How do I pick the right numbers?
Ask what you would check on a random Tuesday, then ask what you would do differently if the number looked bad. No answer means the number gets cut, however impressive it sounds.
Does it update automatically?
Every number is computed by formula from the data tab, so adding a row updates everything with no manual step. The session ends by testing exactly that loop.
What if my data is too thin to be worth watching?
Then the dashboard is premature and the skill says so. Run track-anything for a few weeks first; a dashboard over seven rows has nothing to show you yet.
Where to go from here
Dashboard live? Deepen the pipeline behind it:
Want a dashboard-shaped project?
Ideas to use it on
- Count something real with a camera — Point a camera you own at something countable in your world (birds at the feeder, cars in your driveway, bees at the balcony planter) and build a system that counts visits automatically.
- Will you actually like this track — Request your full listening-history export and build a model that predicts whether you will like a track you have not heard yet.
Curious? Read the full skill — the exact instructions your agent gets
--- name: simple-dashboard category: data description: Build a small dashboard over their real data. The three numbers that matter, updating when the data does. Use when they say "make a dashboard", keep re-computing the same numbers, or run a club or shop with data worth watching. --- # simple-dashboard Build a small dashboard with someone, on top of data they already keep — their tracker sheet, shop sales, club attendance, game stats. A dashboard earns its name by being looked at repeatedly, so the whole design question is: which few numbers would they actually check next week? Three is the right count to start. ## Pick the three numbers Ask what they would want to know at a glance on a random Tuesday. Push past vanity numbers to ones that change decisions: not "total rows logged" but "streak", "this week vs last week", "cash left this month", "sign-ups still unconfirmed". For each number, have them say what they would do differently if it looked bad. A number with no answer to that question gets cut. Write the three down with exact definitions (what counts, what date range) before building anything — vague definitions are how dashboards drift into lying. ## Build it sheet-backed first Start in the sheet that already holds the data: 1. A `dashboard` tab: the three numbers as big cells, computed by formula from the data tab — never typed in by hand. SUMIF, COUNTIF, and a date-window filter (this week, this month) cover most of it. 2. One small chart beside them for the number that has a trend (chart-the-truth rules apply: honest axis, labeled). 3. A "last updated" cell derived from the newest data row, so a stale dashboard confesses instead of quietly showing old truth. 4. Test the loop: they add one real row to the data tab and watch the three numbers move. If a number does not move when it should, the definition or the formula is wrong — fix it now. For many people the tab is the finished product. Stop here if so. ## Upgrade to a page if it should be seen If the dashboard is for a team, a club, or their own phone home screen, put it at a URL. Keep it boring: publish the Google Sheet to the web and read it from a single static HTML page (fetch the published CSV, compute the three numbers in a few lines of JS, render big). Deploy on GitHub Pages (ship-on-github skill if present). The sheet stays the single source of truth; the page only reads. Check privacy before publishing: a public URL means public data, so if rows contain other people's names or money details, either keep it as a tab or publish only the aggregated numbers. ## Done - Three numbers with written definitions, computed live from real data, plus one honest trend chart - Adding a data row updates everything with no manual step - A "last updated" indicator that exposes staleness - Either a dashboard tab they check or a live URL they can open on a phone - A first-review date is scheduled and the person can state what decision each number will inform Repeated use is a follow-up success measure, not a setup claim. On the first review date, record whether the dashboard was current and what it changed. Then: track-anything if the data feeding it is thin, or first-sql when the questions outgrow sheet formulas.