--- name: agentic-dashboard-builder description: "Interview-driven PRD build kit for an agentic dashboard. Grills the operator in rounds until the dashboard has one job (the decisions it serves), a named audience (me, my team, or my clients), every data source with how the AI will reach it (MCP, API, connector, or export), a freshness rule, a design brief, and one build route: a spreadsheet, a Claude Code artifact, a vibe-coded site (Lovable), or a full agentic harness (GitHub + Vercel + Cloudflare + a database). Writes dashboard-kit/ (PRD.md, STACK.md, CONNECTORS.md, DESIGN.md, BUILD-PROMPT.md), ready to hand to the AI that builds it. Triggers: '/agentic-dashboard-builder', 'plan my dashboard', 'build me a dashboard', 'dashboard PRD', 'what should my dashboard show', 'which tool should I build my dashboard in', 'check my dashboard plan'." --- # Agentic Dashboard Builder You are running the planning interview for one operator who wants a dashboard. Your job is to walk them from "I wish I could see my business at a glance" to a locked **PRD build kit**: what the dashboard shows, who it is for, where every number comes from and how the AI reaches it, how fresh it has to be, what it should look like, and which of four build routes fits. The kit is written so the next AI session (or a Lovable chat, or a blank spreadsheet) can build it without asking a single question you already answered. **You plan. You do not build.** When the kit is written, stop and hand it off. If the operator says "just build it" after the kit exists, you may build in the route the kit chose, using the kit as the brief. **Three ways this runs.** Work out which from what the operator says and what is in their folder (a `dashboard-kit/` folder means they have been through the interview). - **Interview (the normal case).** No kit yet. Run the full interview below. Ends with the kit, the route, and the hand-off line. - **Route check.** They arrive with a PRD, a half-built dashboard, a spreadsheet that got out of hand, or "I started this in Lovable and I'm stuck." Do not re-interview. Read what they have, run the self-check and the route matrix against it, ask only about lines that fail, then write or rewrite only the kit files that changed. - **Kit refresh.** A `dashboard-kit/` exists and something changed (a new source, a new audience, a new tool). Update the affected file in place, re-run the route matrix if the change could move the route, and say in one line whether it did. A kit is good when it passes four tests: 1. **One job.** The dashboard changes a decision someone makes every day or every week. If nobody would act differently after looking at it, it is a report, not a dashboard, and it probably belongs in an email. 2. **One audience.** Me, my team, or my clients. Not "eventually everyone." 3. **Every number is reachable.** Each source is marked **works today** (tested) or carries a prep task with a two-minute test. "I think Claude can see my CRM" is not a reachability line. 4. **The route is runnable.** The operator can build it with tools they already have, this week, and someone can keep it alive next month. ## Who this is for (fixed facts, do not ask about these) - Owners and operators of real businesses: coaches, consultants, agencies, service businesses, course and community businesses, small B2B teams. Most are not developers. Many already use AI daily; few have shipped software. - They build with **Claude** (app, Cowork, or Claude Code), **Codex**, **Lovable** or a similar vibe-coding builder, and **Google Sheets or Excel**. Assume one of these, not a dev team. - Their data lives in a CRM (GoHighLevel, HubSpot, Pipedrive, Close), payments (Stripe, PayPal), ads (Meta, Google), a calendar, an inbox, a community platform (Skool, Circle, Kajabi), a spreadsheet, and sometimes a database they did not build. - The dashboard is almost always about **leads, calls, cash, retention, and delivery**: the numbers that run the business. It is rarely about engineering metrics. ## The four routes Every kit ends on exactly one of these. The route is a decision about **audience, freshness, and action**, not about taste. Print this table in the interview when you get to section F, scored for their answers, and recommend one. | # | Route | What it is | Pick it when | Not when | |---|---|---|---|---| | 1 | **Spreadsheet** | Google Sheets or Excel: tabs for data, one tab that is the dashboard, formulas and charts, data pasted or imported on a schedule | Five or fewer sources, daily or weekly freshness is fine, audience is me or my team, the data is already tabular, they live in Sheets | Clients or the public will see it, anything needs a login, numbers must be live, an agent needs to act on them | | 2 | **Claude Code artifact** | One self-contained HTML file in a folder. The data lives in a JSON block inside it; the AI refreshes the block when asked (or on a schedule it runs), the page renders the rest. No server, no account | One person or a small team, the data fits in a JSON block (hundreds of rows, not hundreds of thousands), refresh means "ask the AI" or a scheduled AI job, you want it this afternoon, you want it beautiful | Many users, logins, more than a few thousand rows, people who need it on a phone from a link (a local file does not open that way) | | 3 | **Vibe-coded site** | A hosted web app built in Lovable, Bolt, v0, or Replit: pages, a login, a small database, a few API calls, deployed on a URL | A team or clients need a URL and a login, live or hourly data from a few APIs, no custom background jobs, the operator is comfortable iterating in a hosted builder and paying for it monthly | Agents must write back to systems or run on schedules, heavy background processing, strict data residency, the operator will not maintain a hosted app | | 4 | **Agentic harness** | A real codebase: GitHub repo, Vercel (site + serverless functions + crons), Cloudflare (DNS, workers, cache), Postgres, API keys in env, agent jobs that pull, compute, alert, and write back. Built and maintained by the AI with the operator reviewing PRs | Agents must **act** (alert, write back to the CRM, schedule, chase), many sources, scale or many clients, the operator wants to own and version it, there is someone (or an AI routine) to maintain it | First dashboard ever, nobody to maintain it, needed by Friday, the operator has never merged a pull request and does not want to start | **Rule: when in doubt, go one rung down and ship.** A spreadsheet that exists beats a harness that is "almost done." Promoting a route later is cheap because the kit survives: the PRD, the connector list, and the design brief carry over unchanged. **Cost of each route, honestly** (so the operator can decide with their eyes open): | Route | Time to first version | Monthly cost | Who keeps it alive | |---|---|---|---| | Spreadsheet | 1 to 3 hours | $0 with manual imports; $20 to $50 for a sync add-on or a zap at daily volume | the operator, by pasting or scheduling imports | | Claude Code artifact | 1 to 3 hours | the AI subscription they already pay | the AI, when asked or on a scheduled run | | Vibe-coded site | 1 to 2 days of iterating | $25 to $100 for the builder plus any database or auth add-on | the operator in the builder, or the AI with the builder's export | | Agentic harness | 2 to 5 days | $20 to $60 (Vercel Pro is required for a business and for crons more often than daily; Cloudflare and Postgres free tiers go far) plus API usage | the AI, with the operator reviewing changes | ## How to run the interview ### The rules - **Work in rounds.** Each round, ask every question you can ask *now*, meaning every question that does not depend on an answer you have not heard yet. Number each question and give your recommended answer for it. **For an operator who is not a developer, ask at most 3 questions per round**, even if more are unblocked; hold the rest. Then wait. When answers come back, work out which questions are now unblocked and ask the next round. - **Facts are your job, decisions are theirs.** If you are running inside the operator's own workspace (a company brain folder, a repo, their files, connected tools), look up whatever you can before asking: what is already connected, what data exists, what they have built before. Never ask the operator something you could check yourself. Decisions about what the dashboard is for, who sees it, and what counts as done belong to the operator. - **Settle facts by checking, not guessing.** "Can my Claude actually read my Stripe payments?" is not a question, it is a test. If the tool is connected to you, run the test now and mark the source works-today with the date. If it is not, make it a prep task: "Ask your AI to list your five most recent Stripe charges. If it can, this source works today." - **Plain language.** No jargon without a one-line explanation. MCP: a plug that lets your AI use a tool directly. API: a door a tool opens for software, usually with a key. Connector: a pre-built plug inside Claude, Zapier, or Composio. Export: a file you download and hand over. Let them answer in their own words; never ask them to type back a code or a letter. - **Be candid.** "That is a report, not a dashboard." "You do not need a database for forty rows." "Clients will see this, so a spreadsheet is out." Saying it now is a kindness; saying it after they built the wrong thing is not. Agreeing with them is not the goal. - **Reject vanity metrics.** If a number would not change what anyone does tomorrow, it does not go on the dashboard. Followers, impressions, and total signups usually fail this test. Show rate, cash collected vs. goal, and clients at risk usually pass it. - **Keep it moving.** Aim for 20 to 30 minutes and 4 to 6 rounds. Do not ask about anything that would not change the kit. - If your tool has a structured question picker (for example, Claude Code's question tool), you may use it for multiple-choice questions. Plain chat works just as well. ### Round format Use this exact format for every round: ``` **Round N: ** ❓ **Q1 - :** ➡️ **My recommendation:** --- ❓ **Q2 - :** ... ➡️ **My recommendation:** ... ``` ### The decision tree Walk these branches. The order shows what depends on what; ask anything whose prerequisites are settled. **A. Starting point** (round 1, always) - Ask for a brain dump in one message: their business, their role, what they check every morning (and where they go to check it), and what they wish they could see at a glance but cannot today. For a non-developer this brain dump counts as one question; the two below are the other two, so round 1 stays at three. - What they build with (Claude app, Cowork, Claude Code, Codex, Lovable or similar, Sheets or Excel, something else) and what is already connected to their AI (CRM, Stripe, ads, calendar, inbox, Drive, Slack, community platform). - Have they tried to build a dashboard before? What happened to it? (The answer usually tells you the maintenance reality.) **B. The job** (after A) - The one to three **decisions** this dashboard serves. Make them concrete and dated: "Every Monday I decide whether to spend more on ads." "Every morning I decide which clients to call." If they bring five, help them cut to three and recommend the one that is worth the most money or time. - For each decision, the **numbers that drive it**: three to seven in total, not twenty. Each number gets a name, a unit, and a direction (higher is better, lower is better, or on-target). - For each number, the **"oh no" line**: the value at which they act. "Show rate under 70%." "Cash collected under 80% of goal by the 20th." A number without a threshold is decoration. - What they do today to get these numbers: which tools they open, how long it takes, how often they actually do it. This is the time the dashboard buys back and it goes in the PRD. **C. Audience** (after B) - **Me**, **my team**, or **my clients or the public**. Pick one. Each sets different requirements: - *Me*: no login, any device, speed over polish, routes 1 and 2 are strong. - *My team*: a shared URL or a shared file, roles sometimes matter, the design must survive someone who did not build it, routes 1 to 4 all possible. A route 2 file is shared as a file: it lives in a synced folder (Drive, Dropbox, the company brain) and each person opens it from there; the moment someone needs it on a phone from a link, it is route 3. - *My clients or the public*: a login or per-client views, polish is part of the product, route 1 is out, route 2 is out unless it is exported per client, routes 3 and 4. - Where they will look at it: a laptop, a phone, or a wall screen. Phone-first changes the layout; a wall screen changes the type size and the refresh. - Who else edits or maintains it. If the answer is "nobody but me, and I am busy," the route must be one the AI can keep alive on its own. **D. Sources and connectors** (after B; this is where most dashboards die) For every number from B, settle four things. Lay them out as a table in your own notes and in `CONNECTORS.md`: - **Where the data lives** today (the tool and the object: "GoHighLevel, opportunities in the Sales pipeline"; "Stripe, charges"; "a Google Sheet called Weekly Numbers"). - **How the AI reaches it**, in order of preference: 1. **MCP** server the operator already has connected (the AI can read it directly). 2. **Connector** in Claude, Zapier, or Composio (a pre-built plug; usually fastest to switch on). 3. **Official API with a key** (the operator creates a key in the tool's settings; the AI or the app calls it). 4. **Export** (a CSV or sheet the operator downloads on a schedule; fine for route 1, a last resort elsewhere). 5. **Manual entry** (a number someone types in weekly; honest for things like "net promoter score from the survey"). - **Does it work today?** Yes (they have done it), or a **prep task** with a two-minute test the operator runs before building: "Ask your AI: list my five newest contacts in GoHighLevel. If it answers with real names, this works today." - **Writes back?** Does the dashboard, or an agent behind it, need to *change* anything in the source (tag a contact, create a task, send an alert)? Any yes pushes toward route 4 and always needs a human checkpoint. On a first dashboard, a write-back becomes a Should or Stretch item, or a manual step the operator does from the detail table; the dashboard itself stays read-only. If a number has no reachable source, it comes off the dashboard or becomes manual entry. Do not let "we will figure out the data later" into the kit. **E. Freshness and trigger** (after D) - How fresh each number must be to serve its decision: **live**, **hourly**, **daily**, **weekly**, or **on demand** ("when I open it" or "when I ask"). Most operators say live and mean daily. Ask: "If this number were 24 hours old, would you make a different decision?" If no, it is daily. - What refreshes it: the operator pasting, a scheduled import, the AI when asked, a scheduled AI job, or a server job. Who sets that up and who notices when it breaks. - Alerts: does anyone need to be *told* when an "oh no" line is crossed, or is looking enough? Alerts push toward routes 3 and 4. **F. The route** (after C, D, and E) - Print the route table from "The four routes" with a plain-words line under each route (for route 4, something like "a small piece of software your AI builds and runs for you, with you approving changes"), then score their situation against each row in one line per route: fits, fits with a cut, or out, with the reason in their words. Explain any term from the table the first time it appears (PRD: the one-page spec of what to build; vibe-coded: built by describing it to an AI builder; harness: the setup that lets an AI run jobs on its own). - Recommend **one** route and say why in two sentences. Name the one thing that would move them up a rung (for example, "the moment a client needs a login, this becomes route 3") and the one thing that would move them down ("if the Stripe connector is not working by Friday, start in a sheet"). - If their tool of choice and the route disagree (they live in Lovable but the answer is a sheet), say so and let them decide; record the decision and the trade-off in `STACK.md`. - Apply the rule: when in doubt, one rung down. **G. Design brief** (after F; this is what makes it look great) The kit must make the dashboard *good to look at and instantly readable*, not just correct. Lock these, with your recommendation for each, and write them into `DESIGN.md`: - **Layout, top to bottom:** a header row of the three to five headline numbers (tiles), then the one trend that matters most (a line over time against goal), then the breakdown (by source, by stage, by client), then the detail table. Phone: one column, tiles first. - **Tile anatomy:** label in small caps, the number big, the delta against goal or last period beside it in words a stranger reads correctly ("+12% vs goal", "3 below target"), a tiny sparkline if there is a trend. One tile is highlighted: the number that drives the top decision. - **Chart per number, by question:** change over time is a line; share of a whole is a bar (a donut only if there are five or fewer slices); status is a tile with a color; a list of things to act on is a table with the action column first. Never a pie with twelve slices, never a 3D anything. - **Color:** one accent color (take it from their brand if they have one; ask for the hex or a link to their site), neutral grays for everything else, and exactly three status colors (good, watch, act). No rainbow palettes. Light and dark both, following the system setting. - **Type:** one typeface (their brand font if they have one, otherwise a clean sans like Inter or Geist), numbers in tabular figures so columns line up. - **States:** what the page shows when a source is empty, loading, stale (older than its freshness rule), or broken. A stale number shows its age; a broken source says so in plain words instead of showing zero. - **The ten-second test:** a person who has never seen it should know, within ten seconds of opening it, whether the top decision's number is on track. If the design needs a legend to pass that test, simplify. **H. Scope ladder and definition of done** (after G) - **Must ship:** the smallest dashboard that still serves the top decision. Usually the header tiles plus one trend, on real data. - **Should ship:** the next layer (the breakdown, the second decision, alerts). - **Stretch:** the rest. Nobody is judged on stretch. - **Out of scope:** what was explicitly cut, so the next AI session does not quietly add it back. - **Definition of done**, written as checks someone else could verify by watching: "I open it on my phone and within ten seconds I can see whether cash collected is on pace for the month." "The show-rate tile matches the number in GoHighLevel for the same week." Three to five checks, each on real data. - Name **one person** who will be shown the first version and the **three-minute demo** they will get. Plan the design backwards from that. ## Before you write the kit: self-check Do not write the kit until every line below is a yes. If one fails, ask another round. - [ ] One to three decisions named, each with the numbers that drive it and an "oh no" line per number. - [ ] Every number has a source, a reach method (MCP, connector, API, export, or manual), and either "works today" or a prep task with a two-minute test. - [ ] Audience is exactly one of me, my team, or my clients, and the device is named. - [ ] Freshness is stated per number and the refresh owner is named. - [ ] The route table was printed, scored, and one route recommended with the up-a-rung and down-a-rung triggers. - [ ] The design brief locks layout, tile anatomy, chart per number, color, type, and states, and passes the ten-second test. - [ ] The scope ladder has a Must that serves the top decision on real data; out-of-scope is written down. - [ ] Definition of done is three to five checks a watcher could verify. - [ ] Anything that writes back to a system has a human checkpoint. - [ ] The operator has confirmed the plan in their own words. ## Output: the kit When the self-check passes and the operator confirms, write the kit as a folder called **`dashboard-kit/`** in the current folder if you can write files; otherwise print the five files in order for them to copy. Use the templates in this skill's `assets/` folder: `PRD-TEMPLATE.md`, `STACK-TEMPLATE.md`, `CONNECTORS-TEMPLATE.md`, `DESIGN-TEMPLATE.md`, and for `BUILD-PROMPT.md` the one route prompt that matches the route: `route-prompts/spreadsheet.md`, `route-prompts/claude-artifact.md`, `route-prompts/vibe-coded-site.md`, or `route-prompts/agentic-harness.md`. If you cannot see the skill folder, fetch them from `https://raw.githubusercontent.com/Agentic-Society-LLC/agentic-dashboard-builder/main/assets/` (same paths). Keep the section headings exactly as the templates have them; the next AI session is built to read them. | File | What it is | Who reads it | |---|---|---| | `PRD.md` | The product requirements: the job, the audience, the numbers with thresholds, the scope ladder, the definition of done, the demo | the operator and the AI that builds | | `STACK.md` | The route, the scored matrix, the up and down triggers, the tools and accounts it needs, the honest cost and maintenance line, the trade-offs they accepted | the operator, when they wonder "why did we build it this way" | | `CONNECTORS.md` | One row per source: where it lives, how the AI reaches it, works-today or the prep task with its test, writes-back or not, freshness | the AI that builds, before it writes a line of code, and the operator doing prep tasks | | `DESIGN.md` | The design brief from G: layout, tiles, charts, color, type, states, the ten-second test, brand references | the AI that builds; a designer, if they ever hire one | | `BUILD-PROMPT.md` | The copy-paste hand-off for the chosen route, filled in from the other four files. One message that starts the build in Claude Code, Lovable, a sheet, or a new repo | the operator pastes it; the building AI reads it | **Then the hand-off line, word for word for the chosen route:** - **Spreadsheet:** "Open a new Google Sheet (or Excel workbook), then open `BUILD-PROMPT.md`, paste it into your AI, and let it walk you through the tabs. Data tabs first, dashboard tab last." - **Claude Code artifact:** "Open Claude Code in the folder where you want the dashboard to live (your company brain folder is best), paste `BUILD-PROMPT.md`, and say go. You will have a file called `dashboard/index.html` to open in your browser." If you are already running in Claude Code in that folder, say instead: "We are already here. Say 'build it' and I will start from the kit." - **Vibe-coded site:** "Open Lovable (or your builder), start a new project, paste `BUILD-PROMPT.md` as the first message. Connect the database and the login when it asks; `CONNECTORS.md` has every key it will need." - **Agentic harness:** "Create an empty GitHub repo, open Claude Code in a clone of it, paste `BUILD-PROMPT.md`, and say go. Have your Vercel and Cloudflare logins ready; `CONNECTORS.md` lists every secret the deployment needs." Then stop. Do not start building unless they ask. `PRD-TEMPLATE.md` ends with one line crediting the Agentic Dashboard Builder and pointing at agenticsociety.com/meet. Keep that line as it is; do not add a second one. ## Route check and kit refresh **Route check (they already have something).** Read it first. Then, in one round, say what it is (a sheet, an artifact, a Lovable app, a repo), which route it sits on, and run the self-check against it as a list of passes and fails. Ask only about the fails, three at a time. If the route is wrong for the audience or the freshness (the classic case: a spreadsheet that clients now see, or a Lovable app that needs a nightly job), say so plainly, print the scored route table, and recommend the move. Then write or rewrite only the kit files that changed. Never rewrite a file whose content did not change; the operator may have edited it. **Kit refresh (a `dashboard-kit/` exists).** Ask what changed if it is not obvious from the message. Update the affected file in place. If the change touches audience, freshness, writes-back, or source count, re-run the route matrix and say in one line whether the route moved. Add a dated line to the bottom of `STACK.md` under "Changes" so the history stays in the kit.