Report Builder

# Report Builder

The owner describes a report once. You build it, run it, and save the definition so it never has to be described again.

Owners are pulling numbers out of three dashboards by hand and trying to find the story themselves. The job is to end that.

## Step 1 — Check for an existing definition

Before anything else, read `reference/saved_reports.md` and check whether this report already exists. Also check for a `report-definitions.md` in the working directory — that's where definitions land when the skill folder isn't writable (see Step 7).

If the owner says "same report as last time," "run the weekly one," or names a report you have a definition for, skip straight to Step 4 and run it. Re-interviewing someone about a report they already defined is the fastest way to make this skill feel broken.

If nothing matches, continue.

## Step 2 — Turn the description into a spec

Owners describe reports loosely: "every Monday, sales by location versus last year, AR aging, and labor percent." That sentence contains four separate decisions. Resolve them into a spec using the format in `reference/report_spec.md`:

- **Metrics** — each one named, with its formula and source - **Grouping** — by location, product, customer, channel, rep - **Comparison** — versus prior period, versus last year, versus target - **Period** — the window each run covers - **Cadence** — one-off, weekly, monthly, quarterly

Infer what you reasonably can. "Sales by location vs last year" gives you the metric, the grouping, and the comparison — don't ask about those. Ask only about what's genuinely ambiguous, and ask it in one batch rather than one question at a time.

The two questions worth asking almost every time:

- Which period does each run cover — calendar month, trailing 30 days, month-to-date? - Is a number like "labor percent" measured against revenue or against total costs?

Getting these wrong produces a report that looks right and is quietly wrong, which is worse than asking.

## Step 3 — Confirm the spec, once

Show the resolved spec back in a compact block. Ask for one confirmation, then build. Do not walk the owner through the spec field by field — they described this in one sentence and expect one answer.

If they correct something, apply it and go. Do not re-confirm a second time.

## Step 4 — Pull the data

Dispatch every source call in a single parallel batch. See `reference/data_sources.md` for the metric-to-tool mapping.

Sources, tried simultaneously:

- **The ledger** — MYOB, NetSuite, QuickBooks, Xero, or Zoho Books, whichever is connected; peers per `../../shared/connector-neutrality.md`. P&L lines, revenue, expenses, AR aging, AP, class and location splits. MYOB is P&L, AR, and payables only, three financial years back. If two ledgers are connected, ask which is the source of record and take totals from that one - **HubSpot** — deals, stages, owners, close dates, pipeline value - **PayPal, Square, Stripe** — settlements, fees, refunds, transaction detail - **Shopify** — orders, SKU-level revenue, fulfillment status - **Ramp, Expensify** — card spend and expense detail. Both are read sources here; Expensify is read-only search

If a source errors or returns nothing, record it and move on. Never block the whole report on one bad connector.

**No connectors at all is a supported path, not a failure.** Ask for a CSV or XLSX export, read it, and build the identical report from the file. Say so plainly: "I don't see a connected data source. Export the sales report from your system and drop it here — I'll build the same report from that." Owners with tool sprawl live in this mode, and the report is just as good.

## Step 5 — Compute and sanity-check

Compute every metric named in the spec. Then check the results before showing them. Read `reference/gotchas.md` for the failure modes that actually happen.

The checks that catch real errors:

- **Period boundaries.** A partial current month compared against a full prior month always looks like a collapse. Either compare like-for-like or label the partial period explicitly. - **Double-counting.** A Shopify order and its Stripe settlement are one sale. If both sources are connected, pick one as the revenue source and note which. - **Empty groups.** A location with no sales this period should appear with a zero, not vanish. A disappearing row reads as a data problem. - **Totals that don't tie.** If the grouped rows don't sum to the total, say so rather than publishing a number you can't defend.

## Step 6 — Deliver

Two artifacts, always, in this order.

**The chat summary comes first.** Follow `reference/output_template.md`. Lead with what changed and what it means, not with a table dump. The owner asked for a report because they want a decision, not a spreadsheet.

Writing rules, same as every reporting skill in this plugin:

- Numbers lead, words follow. Not "sales were strong" — "USD 43,200, up 8% versus last year." - Every number carries its comparison. A figur