docs: drop project-costs/example.md, the last commentary file

Every principle in it was already stated generically in SKILL.md — leading with
the cloud split, dollarizing spikes before judging them, using the daily
<details> block to attribute a spike to a date, normalizing partial edge weeks,
reading SQL Serverless silence as a finding, reconciling attributed spend before
trusting the per-job table, and comparing per active day. The file re-narrated
those against one window's numbers.

Two points were not already generic and moved into SKILL.md: that a batch-vs-SDP
gap becomes a finding through durability (holding across the window and
repeating in a second environment) rather than size, and that the example is to
be read for shape, not for figures.

sql-diagram lost its example.md for the same reason last commit, so tooling.md
now states the rule in its general form instead of justifying one exception.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: andre-salvati

.claude/skills/project-costs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: project-costs
-description: Run the project cost report and write the analysis into it. Use when asked about this project's cloud spend, cost anomalies, spikes or trends, DBU/DSU consumption, per-job or per-pipeline cost, or the AWS vs Databricks split. Runs `make project-costs` (AWS Cost Explorer + Databricks system.billing), then analyses the generated report and replaces its Analysis placeholder. See example.md for a committed report read end to end.
+description: Run the project cost report and write the analysis into it. Use when asked about this project's cloud spend, cost anomalies, spikes or trends, DBU/DSU consumption, per-job or per-pipeline cost, or the AWS vs Databricks split. Runs `make project-costs` (AWS Cost Explorer + Databricks system.billing), then analyses the generated report and replaces its Analysis placeholder. See examples/ for a finished report.
 ---
 
 # Project cost analysis
@@ -69,7 +69,9 @@ to dollars before calling them big or small.
   the days someone deployed, so compare *per active day*, never raw totals. The `Days` column is
   what makes that comparison possible.
 - Compare `job1_*` against its `job1_sdp_*` counterpart: they produce the same medallion tables by
-  different execution models, so a persistent gap between them is a real finding, not noise.
+  different execution models, so a persistent gap between them is a real finding, not noise. What
+  makes it a finding is **durability** — a gap that holds across the whole window *and* repeats in a
+  second environment is an argument; the same gap seen once is a number.
 - Watch the integration-test jobs. They are easy to overlook and can rival the pipeline they test.
 - Reconcile before trusting: the attributed total is always *less* than the Databricks total, since
   SQL warehouse and interactive compute carry no `job_id`. The note under the table gives the
@@ -84,8 +86,9 @@ to dollars before calling them big or small.
   charging the AWS account for EC2. AWS spend is therefore a *proxy for job activity*, never a
   measure of pipeline cost.
 
-`example.md` walks a committed report showing what each of these sections looks like when written
-against real numbers.
+`examples/2026-07-22.md` is a finished report showing what these sections look like written against
+real numbers. Read it for shape, not for figures — they are a snapshot of one 30-day window, and a
+live run writes a fresh `reports/cost/YYYY-MM-DD.md`.
 
 ## Caveats to respect
 

.claude/skills/project-costs/example.md

@@ -156,12 +156,12 @@ run would produce much the same document, so one example is enough. An investiga
 output — its example is kept for the **findings**, which are live defects in `prod`, and a second
 investigation would be a second example rather than a replacement.
 
-The other two take different forms, and the difference is the rule worth copying. `sql-diagram` ships
-`job_spend_plan.html`, which *is* the deliverable — diagram plus a data trace — so it needs no prose
-companion; it had one, and the file was deleted once the page demonstrated with data what the prose
-had asserted. `project-costs` ships `example.md` beside its report, because a page of cost tables
-does not explain why its analysis is written the way it is. **Add a commentary file only when the
-artifact cannot speak for itself**; two files narrating one artifact will drift.
+**An example is the artifact, never a commentary file beside it.** Both `sql-diagram` and
+`project-costs` once shipped an `example.md` explaining their example; both were deleted, and in each
+case the explanation belonged in one of two places — the artifact itself, or the `SKILL.md` as
+guidance that applies to every run, not just to the committed one. Two files narrating one artifact
+will drift, and the prose is the copy that goes stale. If an example needs a companion to be
+intelligible, fix the example.
 
 One gotcha on the kit's skills. Some have a frontmatter `name:` that differs from their directory
 (`databricks` declares `databricks-core`; `analyze-mlflow-trace` declares `analyzing-mlflow-trace`)