diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 586eec2..3d50586 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -112,9 +112,9 @@ usually what it admits.
 - **Say what the tool cannot do.** The analytics skills in `startup-data-kit`
   have a "what this cannot tell you" section, because the alternative is an
   agent producing a confident answer to a question the data cannot answer.
-- **Say what the user has to decide.** `revenue-analytics` has ten decisions it
-  cannot make for you, because MRR genuinely depends on them. A resource that
-  picks silently teaches the user that a hard question is settled.
+- **Say what the user has to decide.** The startup-data-kit skills list what
+  usually needs the user's input, because the numbers genuinely depend on it. A
+  resource that picks silently teaches the user that a hard question is settled.
 - **Name the traps specific to that data.** Generic advice gets skipped. "GA4
   thresholding means totals will not equal the sum of a breakdown" does not.
 - **Write to the agent, imperatively.** Not prose about the tool.
diff --git a/README.md b/README.md
index 1fa7b76..a884c5e 100644
--- a/README.md
+++ b/README.md
@@ -41,6 +41,10 @@ questions from it. One domain per folder:
 | [`product-analytics`](resources/startup-data-kit/product-analytics/) | experimental | approval-required | Activation, feature adoption, retention, usage-based churn signals. PostHog, Mixpanel, Amplitude |
 | [`web-analytics`](resources/startup-data-kit/web-analytics/) | experimental | approval-required | Traffic, landing pages, channels, funnel drop-off. GA4, Search Console |
 | [`ai-search-visibility`](resources/startup-data-kit/ai-search-visibility/) | experimental | approval-required | SEO, GEO and AEO. Search Console, AI crawler traffic, whether assistants mention you |
+| [`finance-accounting`](resources/startup-data-kit/finance-accounting/) | experimental | approval-required | Receivables and aging, invoiced vs collected, customer concentration, vendor balances. QuickBooks Online |
+| [`support-analytics`](resources/startup-data-kit/support-analytics/) | experimental | approval-required | Ticket volume, response and resolution time, CSAT, backlog, support load per customer. Gorgias, Zendesk, Intercom |
+| [`ai-coding-spend`](resources/startup-data-kit/ai-coding-spend/) | experimental | approval-required | AI coding tool adoption, usage and estimated cost by team, model and platform. Claude Code, Cursor |
+| [`sheets-and-notion`](resources/startup-data-kit/sheets-and-notion/) | experimental | approval-required | Hand-maintained plans, targets, budgets and mappings, joined to the other domains. Google Sheets, Notion |
 
 **[`data-engineering-skills`](resources/data-engineering-skills/)**: keeping
 pipelines healthy. Install Bruin's seven maintained skills, then add the
@@ -72,10 +76,7 @@ ship code you run yourself, with your own credentials.
 | [`blog-image-generator`](resources/tools/blog-image-generator/) | experimental | approval-required | Finding a licence-friendly Unsplash photo and turning it into a cropped, treated cover image |
 | [`linkedin-enrichment`](resources/tools/linkedin-enrichment/) | experimental | approval-required | Pulling public LinkedIn company, person, post or job data through paid Apify actors |
 
-Everything is `experimental` today: the commands in `bruin-agent` were verified
-against a live Bruin CLI, and the connector and template lists came from Bruin's
-own tooling, but nobody other than the author has used any of these end to end.
-A resource becomes `stable` when someone else has.
+Everything is `experimental` today.
 
 **Risk** is the worst a resource can do when followed as written. `read-only`
 reads and produces local files. `approval-required` can write, run or send
diff --git a/resources/startup-data-kit/README.md b/resources/startup-data-kit/README.md
index f635511..bc2f84c 100644
--- a/resources/startup-data-kit/README.md
+++ b/resources/startup-data-kit/README.md
@@ -5,13 +5,8 @@
 > is stale. Each skill states the version and date it was written against.
 > Checked 2026-10-01.
 
-Getting a startup's data into shape and answering questions from it. Each skill
-has an agent work with the user to set up a maintained Bruin template and
-customise it to how the business actually works, then answer questions from
-what it built. One resource per domain, because the traps are domain-specific:
-what ruins a revenue number is not what ruins an attribution number.
-
-Each folder is an independent skill. Take the ones you need.
+One skill per domain: an agent sets up a maintained Bruin template with the
+user, customises it, then answers questions from it. Take the folders you need.
 
 | Resource | Domain | Example sources |
 |---|---|---|
@@ -20,39 +15,34 @@ Each folder is an independent skill. Take the ones you need.
 | [`product-analytics`](product-analytics/) | Usage and activation | PostHog, Mixpanel, Amplitude, Firebase |
 | [`web-analytics`](web-analytics/) | Traffic and acquisition | GA4, Search Console |
 | [`ai-search-visibility`](ai-search-visibility/) | SEO, GEO, AEO | Search Console, server logs, third-party sampling tools |
+| [`finance-accounting`](finance-accounting/) | Bookkeeping and accounting | QuickBooks Online |
+| [`support-analytics`](support-analytics/) | Customer support | Gorgias, Zendesk, Intercom, Freshdesk |
+| [`ai-coding-spend`](ai-coding-spend/) | AI coding tools | Claude Code, Cursor |
+| [`sheets-and-notion`](sheets-and-notion/) | Hand-maintained data | Google Sheets, Notion |
 
-The sources are examples, not the supported list. Check what Bruin can ingest
-today with the local Bruin MCP server's `bruin_get_docs_tree` (the `ingestion/`
-section), and read `ingestion/<source>` before promising one.
+Sources are examples; read `ingestion/<source>` before promising one. Get one
+domain reconciling against its source before adding a second.
 
 ## How each skill works
 
-Every folder holds the same three kinds of file:
+Every folder holds exactly these three files:
 
 | File | What it is |
 |---|---|
 | `SKILL.md` | What is specific to the domain: which templates to consider, what usually needs the user's input, what to reconcile against |
-| `workflow.md` | The shared process: check Bruin is installed and its MCP server connected, work inside the user's git repository, confirm the warehouse, pick a template, set up credentials, then ask, customise, run and reconcile |
+| `workflow.md` | The shared setup process, from installing Bruin to reconciling the first run |
 | `analysis.md` | How to answer questions once the pipeline exists |
 
-`workflow.md` is identical in every folder, so a skill copied on its own still
-works. `tests/check.py` fails if the copies drift apart; edit one and copy it to
-the rest.
-
-The skills do not carry a fixed list of questions. Templates change, so the
-agent reads the template as it is and works out what this user needs to decide.
-Answers go in a `decisions.md` beside the pipeline.
-
-## Start here
+`workflow.md` is identical in every folder, so a skill copied alone still works.
+`tests/check.py` fails if the copies drift; edit one and copy it to the rest.
 
-Take the domain that answers the question you actually have. Most startups
-should get one domain reconciling against its own source before adding a second.
-Connecting five sources before any of them is trusted produces a dashboard
-nobody believes.
+The skills carry no fixed list of questions: the agent reads the template as it
+is today and works out what this user must decide. Answers go in `decisions.md`
+beside the pipeline.
 
 ## The joins are where the value is
 
-Each domain answers useful questions alone. The ones worth the setup cross two:
+The questions worth the setup cross domains:
 
 | Question | Domains |
 |---|---|
@@ -60,7 +50,8 @@ Each domain answers useful questions alone. The ones worth the setup cross two:
 | Which channels bring customers who stay | marketing + revenue |
 | Where the funnel actually leaks | web + product + revenue |
 | Whether content investment pays back | ai-search-visibility + web + revenue |
+| Which customers cost more to support than they pay | support + revenue |
+| Actuals against the plan | sheets-and-notion + revenue or finance |
 
-Every one of these depends on a stable shared identifier existing between the
-two sources. When it does not, that is the work, and the skills say so rather
-than producing a number from whichever side is available.
+Each needs a stable identifier shared by the sources. Where there is none, that
+is the work, and the skills say so rather than answer from one side.
diff --git a/resources/startup-data-kit/ai-coding-spend/SKILL.md b/resources/startup-data-kit/ai-coding-spend/SKILL.md
new file mode 100644
index 0000000..620eed8
--- /dev/null
+++ b/resources/startup-data-kit/ai-coding-spend/SKILL.md
@@ -0,0 +1,66 @@
+---
+name: ai-coding-spend
+description: Use when a startup wants AI coding tool usage and spend set up or answered. Sets up the ai-coding-usage template (Claude Code and Cursor into DuckDB) and answers adoption, active user, token, estimated cost and model mix questions by team.
+---
+
+# AI coding spend
+
+**Status:** experimental · **Risk:** approval-required
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
+> Anthropic's or Cursor's API documentation, those are right and this file is
+> stale. Written against Bruin CLI `v0.11.766`, checked 2026-10-01.
+
+Sets up a Claude Code and Cursor usage pipeline and answers adoption and cost
+questions from it. It exists to prevent an estimated cost being read as the
+bill, and usage data being turned into a ranking of engineers.
+
+## Set up
+
+Follow [workflow.md](workflow.md).
+
+> **Important: do not ask a fixed list of questions.** Read the template as it
+> is today and work out which of its choices this user needs to confirm.
+> Templates change, so the questions change with them.
+
+**Templates:** `ai-coding-usage`; confirm with `bruin init --help`. Not on
+DuckDB: read `ingestion/anthropic` and `ingestion/cursor`; the modelling is
+theirs to build.
+
+**Watch for:**
+
+- Coverage is Claude Code on the first-party Anthropic API, and Cursor; Bedrock, Vertex AI, Foundry, Claude Platform on AWS, Claude Enterprise claude.ai users and every other tool are silently missing.
+- Cost columns are estimates, not the bill, built differently per vendor, with no seat fees; no seat list is ingested.
+- History lives only in the marts; `--full-refresh` drops it.
+
+**Usually needs the user's input:**
+
+- What "cost" should mean: spend, consumption, or both.
+- Billing model: seats, pay-as-you-go or mixed, and whether to carry it into the marts.
+- Identity: the cross-platform join is lowercased email; aliases, contractors, second accounts.
+- Teams: neither source has one; a mapping from email to team, and where it lives.
+- Seats: utilisation needs a seat or member list added.
+- Users to exclude: test accounts, shared or CI keys, departed staff.
+- How far back history matters.
+
+**Reconcile against:** each vendor's own usage page for one settled UTC day;
+tokens and active users should match, cost only once "cost" is defined.
+
+## Answer questions
+
+Read [analysis.md](analysis.md).
+
+## Never
+
+- Ask for or print a credential; write, run, backfill, `--full-refresh` or
+  touch production without a yes; put personal data in output.
+- Rank, score or judge individual engineers from usage; report at team or organisation level.
+- Call estimated cost "spend" or "the bill" without saying what it includes.
+- Write to Anthropic or Cursor, or use an admin key outside the pipeline's ingestion.
+
+## Unverified
+
+- Whether rerunning a day duplicates Claude Code rows; after a rerun, check `raw.claude_code_usage` for repeated keys.
+- How Anthropic computes `estimated_cost`, and whether it is filled for subscription usage; compare one day with the Console.
+- Whether a read-only Cursor key covers the analytics endpoints; with approval, try one on a one-day run.
diff --git a/resources/startup-data-kit/ai-coding-spend/analysis.md b/resources/startup-data-kit/ai-coding-spend/analysis.md
new file mode 100644
index 0000000..5a61264
--- /dev/null
+++ b/resources/startup-data-kit/ai-coding-spend/analysis.md
@@ -0,0 +1,31 @@
+# Answering AI coding spend questions
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
+> Anthropic's or Cursor's API documentation, those are right and this file is
+> stale. Written against Bruin CLI `v0.11.766`, checked 2026-10-01.
+
+Read `decisions.md` beside the pipeline's `pipeline.yml` first. The Never rules
+in [SKILL.md](SKILL.md) apply.
+
+## Before answering
+
+- Read the mart assets before writing SQL, and query the marts; raw and staging may hold only the last run's window.
+- Check freshness: the last runs (Bruin Cloud MCP or `bruin cloud runs list`), then gaps per platform; one vendor missing days reads as a usage drop or a tool shift.
+- State the definition, exact UTC window, coverage and what cost includes with every number.
+
+## Traps
+
+- Estimated cost is consumption at the vendor's rate, not spend; say which vendor dominates a total.
+- When cost moves, check tokens and model mix first; cache reads inflate token totals cheaply.
+- `sessions`, `requests` and `lines_added` are different measures per platform; compare platforms on tokens, active users and active days.
+- Anthropic rows using several models arrive combined as a model set; do not split them, show their share.
+- API-key actors are not people but count as active users; separate them, and check email overlap before counting cross-platform users.
+- Adoption needs a denominator (seats or headcount) from outside the pipeline, and "active" needs the user's definition.
+
+## What this data cannot tell you
+
+- Productivity, quality or value; lines, tokens and commits measure activity.
+- Who is a good engineer; heavy and light use each have good and bad explanations.
+- ROI, without an outcome measure from elsewhere, and then only as a correlation.
+- Use outside the covered channels.
diff --git a/resources/startup-data-kit/ai-coding-spend/workflow.md b/resources/startup-data-kit/ai-coding-spend/workflow.md
new file mode 100644
index 0000000..a3300e7
--- /dev/null
+++ b/resources/startup-data-kit/ai-coding-spend/workflow.md
@@ -0,0 +1,108 @@
+# Setting up a template with the user
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html) or `bruin <command>
+> --help`, upstream is right and this file is stale. Written against Bruin CLI
+> `v0.11.766`, checked 2026-10-01.
+
+Identical in every startup-data-kit skill. Work in order.
+
+## Working with the user
+
+- **Check before acting;** say what you found. Never redo working steps.
+- **Ask before every write** (install, init, config, model, run); show the diff, wait for a yes.
+- **Ask a few questions at a time,** each with its default and the term in plain words.
+- **Do not guess.** If the user does not know, record the default as unconfirmed.
+- **When only the user can do a step,** give exact steps and wait.
+- **Record answers in `decisions.md` beside `pipeline.yml`:** choice, pick, confirmed or default, date.
+
+## Look it up live
+
+- Commands and flags: `bruin <command> --help`.
+- Docs: Bruin MCP `bruin_get_doc_content` for `getting-started/templates-docs/<name>-README`, `ingestion/<source>`, `platforms/<warehouse>`; or `https://getbruin.com/docs/bruin/<path>.html`.
+- The user's pipelines, runs and connections: Bruin Cloud MCP (`cloud/mcp-setup`), if they run Bruin Cloud.
+
+## 1. Bruin is installed
+
+`bruin version`. If `Latest` is newer than `Current`, offer `bruin upgrade`. If missing, ask, then `curl -LsSf https://getbruin.com/install/cli | sh`; on Windows or failure, read `getting-started/introduction/installation`.
+
+## 2. The Bruin MCP server is connected
+
+If you lack the `bruin_get_doc_content` tool, read `getting-started/bruin-mcp`.
+
+- If you can edit the host's MCP config, show the exact command (Claude Code: `claude mcp add bruin -- bruin mcp`) and its project or global scope; run it only after approval.
+- Otherwise give the user the snippet; the host usually needs a restart.
+
+## 3. You are inside the user's own git repository
+
+`git rev-parse --show-toplevel`.
+
+- **Not a repository:** ask which folder, then `git init`; otherwise `bruin init` creates a `bruin/` wrapper with its own git.
+- **A repository:** confirm it is the user's, not a public catalogue or another Bruin project (a parent `.bruin.yml` gets picked up).
+- **Bruin project exists:** ask whether to add (`--merge`; read `commands/init`) or start fresh.
+
+## 4. Confirm the warehouse
+
+Ask where the data lands; do not pick. It decides which templates exist.
+
+- **None yet:** list destinations this domain's templates support (`bruin init --help`) and their setup cost; some run on local DuckDB.
+- **No template supports it:** say so; offer the closest template elsewhere, or ingestion alone. Never improvise one.
+
+## 5. Choose the template
+
+1. `bruin init --help` for current names; keep those matching source and warehouse.
+2. Read each candidate's README; if none, say so and read the scaffolded `README.md`.
+3. Tell the user what each builds, needs and omits. Let them choose.
+4. After a yes, `bruin init <template>`. If it opens an interactive wizard, give the user the command.
+5. Read the scaffolded files, run `bruin validate <pipeline-folder>`, and tell the user anywhere they disagree with the README or fail.
+
+If nothing fits, say so; agree before building modelling yourself. If no pipeline is needed, say so.
+
+## 6. Credentials into `.bruin.yml`
+
+The README and assets name the connections. A sample's inline key is a shape, not a value.
+
+**Never ask for a credential in chat or pass one as a command argument.** If the user pastes one, tell them to rotate it.
+
+1. Read `ingestion/<source>` or `platforms/<warehouse>` for the fields.
+2. Walk the user to the narrowest credential: read-only or restricted, never admin when narrower exists.
+3. The user sets an env var (gitignored `.env` or secret manager); you write `${VAR_NAME}` (`secrets/bruinyml`). Or the user runs `bruin connections add` with no flags.
+4. `bruin connections test --name <connection>`. Report the result, never the value.
+
+`git check-ignore .bruin.yml`; if not ignored, stop and fix first. Bruin Cloud: `bruin cloud login` or exported `BRUIN_CLOUD_API_KEY`, never `--api-key`.
+
+## 7. Work out what to ask
+
+> **The questions come from the template, not from a list.** Templates change:
+> variables are added, defaults move, reports appear and disappear. Do not work
+> from a remembered or hard-coded set of questions, including any in these
+> files. Read the template as it is today, list every choice it makes on the
+> user's behalf, and decide which ones this user needs to confirm.
+
+- Read the README, `pipeline.yml` variables, asset filters, checks, and report metric definitions.
+- Drop choices that do not apply; `SKILL.md` is a lens, not a script.
+- Add what the template cannot infer (test accounts, history needed); lead with what moves headline numbers.
+
+## 8. Customise
+
+- Prefer a `pipeline.yml` variable to SQL edits; keep SQL edits small and update the asset description.
+- After each change: `bruin validate <pipeline-folder>`, show the diff, record it.
+
+## 9. First run, bounded
+
+Agree and state back, then `bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>`:
+
+- **Environment:** `bruin environments list`; creating one needs approval.
+- **Window:** a local run defaults to yesterday only. Say the expected scan.
+- **README first-load steps:** if one is `--full-refresh`, name what it replaces before asking.
+
+## 10. Reconcile with the user
+
+Compare one number from the source's own dashboard.
+
+- **Differs only by a recorded decision:** note it in `decisions.md`.
+- **Differs unexplained:** stop; investigate before anyone uses the reports.
+
+## 11. Hand off
+
+Report template, warehouse, environment, window, unconfirmed decisions, what is scheduled (nothing unless asked), and what to connect next. Then follow `analysis.md`.
diff --git a/resources/startup-data-kit/ai-search-visibility/SKILL.md b/resources/startup-data-kit/ai-search-visibility/SKILL.md
index 1fb4c17..0315be9 100644
--- a/resources/startup-data-kit/ai-search-visibility/SKILL.md
+++ b/resources/startup-data-kit/ai-search-visibility/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: ai-search-visibility
-description: Use when a startup wants SEO, GEO or AEO measurement set up or answered. Works out with the user which question they have (Search Console performance, appearing in AI assistant answers, or AI crawlers such as GPTBot and ClaudeBot fetching the site), sets up and customises the closest Bruin template or ingestion, says plainly where Bruin has no connector, then answers visibility and content questions from it.
+description: Use when a startup wants SEO, GEO or AEO visibility set up or answered. Sets up Search Console data or AI crawler logs, says where Bruin has no connector, and answers classic search, AI answer and AI crawler questions.
 ---
 
 # Search and AI answer visibility
@@ -8,164 +8,59 @@ description: Use when a startup wants SEO, GEO or AEO measurement set up or answ
 **Status:** experimental · **Risk:** approval-required
 
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
-> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, Google's
-> Search Console documentation, or a measurement tool's own documentation, those
-> are right and this file is stale. This area moves faster than any other in
-> this repository, so treat specifics here as a starting point rather than
-> current fact. Written against Bruin CLI `v0.11.765`, checked 2026-10-01.
-
-Two jobs. **Set up:** work with the user to get the data for the question they
-actually have, from the closest Bruin template or ingestion, customised to this
-site. **Answer:** questions from what it built, in [analysis.md](analysis.md).
-
-Three overlapping things sit under this heading:
-
-- **SEO**, ranking in classic search results. Mature, measurable, Search Console.
-- **GEO / AEO**, appearing in AI-generated answers. New, measurable only through
-  third-party sampling, and heavily hyped.
-- **AI crawler traffic**, whether assistants are fetching the site at all.
-  Measurable from server logs today.
-
-They need different data and have very different evidence quality. Be straight
-about which one a request is actually about.
-
-## Look it up live
-
-This file says what to reach for and what to be careful about. For the facts
-themselves, ask the tool, and tell the user if it disagrees with this file:
-
-- **Flags:** `bruin <command> --help`. The docs lag the CLI.
-- **Docs:** the local Bruin MCP server, `bruin_get_doc_content('<path>')`, or
-  `https://getbruin.com/docs/bruin/<path>.html` without it. For this skill:
-  `getting-started/templates-docs/google-web-analytics-README` for the template,
-  `ingestion/gsc` and `ingestion/google_analytics` for the Google connectors,
-  `ingestion/s3` and `ingestion/gcs` for loading log files, and `ingestion/g2`
-  and `ingestion/trustpilot` for review sites.
-- **A sampling tool:** its own documentation or MCP server. It is not Bruin.
-- **The user's environment:** Bruin Cloud MCP, or
-  `bruin cloud ... --output json`.
-
-## Setting it up
-
-Follow [workflow.md](workflow.md) from the top: install, MCP, repository,
-warehouse, template, credentials, then the questions. It is the same process
-for every skill in this kit. What is specific to search and AI visibility is
-below.
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`,
+> Google's Search Console documentation, or a measurement tool's own
+> documentation, those are right and this file is stale. Written against Bruin
+> CLI `v0.11.766`, checked 2026-10-01.
+
+Sets up data for whichever of three questions the user has (ranking in classic
+search, appearing in AI answers, or AI crawlers fetching the site) and answers
+from it. It exists to prevent sampled or inferred AI visibility being presented
+as measured.
+
+## Set up
+
+Follow [workflow.md](workflow.md).
 
 > **Important: do not ask a fixed list of questions.** Read the template as it
 > is today and work out which of its choices this user needs to confirm.
-> Templates change, so the questions change with them. Workflow step 7 says how.
-
-Start by asking which of the three questions the user has. The answer decides
-which path below applies, and whether a Bruin pipeline is needed at all.
-
-### Templates to consider
-
-There is no Bruin template for AI answer visibility. Check `bruin init --help`
-for anything new, then match each question to a path:
-
-| Path | SEO | AI answer visibility | AI crawler traffic |
-|---|---|---|---|
-| `google-web-analytics` template | Yes | No | No |
-| `ingestion/gsc` alone | Yes, unmodelled | No | No |
-| Logs through `ingestion/s3` or `ingestion/gcs` | No | No | Yes, unmodelled |
-| A third-party sampling tool, such as Peec AI | No | Yes, sampled | No |
-
-- **`google-web-analytics`** is BigQuery only and ingests nothing. It reads the
-  GA4 BigQuery export and the Search Console bulk data export, which must
-  already be running. Neither export backfills, so history starts the day each
-  was enabled. It needs the GA4 streaming export (`events_intraday_*`); without
-  it every GA4 model is silently empty. Read the README's scope section before
-  the first run.
-- **`ingestion/gsc`** reads the Search Console API into any warehouse, with
-  roughly 16 months of history and no reports. Use it when the warehouse is not
-  BigQuery, the bulk export is not enabled, or history before the export
-  matters. The modelling is yours; agree that before starting.
-- **Crawler logs** have no template. `ingestion/s3` and `ingestion/gcs` read
-  CSV, JSONL and Parquet, gzipped or not. A log in any other shape needs
-  converting before it loads. Classifying user agents is modelling you build.
-- **AI answer visibility has no Bruin connector.** That measurement comes from
-  third-party tools that sample assistant responses on a schedule. Set it up in
-  the tool, following its own documentation. Say so rather than implying the
-  pipeline can produce it. If this is the only question, no Bruin pipeline is
-  needed.
-- **Review sites:** `ingestion/g2` and `ingestion/trustpilot` load presence on
-  sites assistants may cite. Ingestion only.
-- **Cloudflare Radar** (`ingestion/cloudflare-radar`) is Internet-wide aggregate
-  data, not this site's traffic or crawler logs. Use it for context only. Its
-  docs page says runs fail until Bruin's pinned ingestr version includes it.
-
-### What usually matters here
-
-A lens for reading the template, not a script. For each, find what the template
-or ingestion does, then ask only where this site makes it matter.
-
-- **Which of the three questions:** often more than one, rarely all three.
-- **Search Console properties:** Domain or URL-prefix, and whether subdomains
-  or a separate blog are their own properties. The service account has to be
-  added as a user on each property before anything loads.
-- **Export state:** whether the GA4 and Search Console BigQuery exports are
-  enabled, and since when.
-- **Brand and competitor names:** branded demand measures awareness, not SEO
-  work. Splitting it out changes every headline trend.
-- **Site structure:** which paths are product, content, docs or support, and
-  whether URLs carry meaningful query parameters or locale prefixes.
-- **Outcomes after the click:** which events count, and how they are valued.
-  Modelled value is not revenue.
-- **Assistant referrals:** whether `chatgpt.com`, `perplexity.ai` and similar
-  should be their own channel. Check how the template classifies channels.
-- **Logs:** which source exists (CDN, origin server), where it writes, and in
-  what format.
-- **Log retention:** how long the bucket keeps logs. Once older logs expire,
-  the warehouse is the only copy.
-- **Which crawlers to track:** start from the list in
-  [analysis.md](analysis.md), and check `robots.txt` before reading absence as
-  a signal.
-- **Sampling tool setup:** the prompt set, the competitors and the assistants
-  sampled. A change to any of them moves the score.
-- **History:** how far back it matters, and whether this path can reach it.
-
-### Reconcile against
-
-- **Search Console:** clicks and impressions in the Search Console interface
-  for a settled window, excluding the last three days. Compare property-level
-  totals, not URL or query rows, which do not sum to them.
-- **Crawler logs:** row counts for one day against the CDN's or server's own
-  request analytics for the same window and timezone.
-- **Sampling tools:** nothing in Bruin to reconcile. Read the tool's own
-  dashboard, and state its prompt set and date range with any number.
-
-Record each gap and its explanation in `decisions.md`.
-
-## Answering questions afterwards
-
-Read [analysis.md](analysis.md): what Search Console can and cannot show, how to
-report sampled AI visibility, what crawler logs measure, and which content work
-has evidence behind it. If the user is on a template, read its report assets
-before writing any SQL.
+> Templates change, so the questions change with them.
+
+**Templates:** `google-web-analytics` for SEO, none for AI visibility; confirm
+with `bruin init --help`. Otherwise read `ingestion/gsc`, or `ingestion/s3` or
+`ingestion/gcs` for crawler logs; the modelling is theirs to build. AI answer
+visibility comes only from a third-party sampling tool such as Peec AI, set up
+in that tool.
+
+**Watch for:**
+
+- `google-web-analytics` is BigQuery only and ingests nothing: it needs the GA4 streaming export and the Search Console bulk export running, and neither backfills.
+- `ingestion/gsc` reaches back roughly 16 months.
+- Logs load only as CSV, JSONL or Parquet.
+- If AI answer visibility is the only question, no Bruin pipeline is needed; say so.
+
+**Usually needs the user's input:**
+
+- Which of the three questions; often more than one.
+- Search Console properties: Domain or URL-prefix, and whether subdomains or a blog are separate; the service account must be a user on each.
+- Brand and competitor names; branded demand measures awareness, not SEO work.
+- Which paths are product, content, docs or support, and any meaningful query parameters or locale prefixes.
+- Whether assistant referrers (`chatgpt.com`, `perplexity.ai`) get their own channel.
+- Which log source exists, where it writes, its format and its retention; expired logs leave the warehouse as the only copy.
+- The sampling tool's prompt set, competitors and assistants; any change moves the score.
+
+**Reconcile against:** Search Console's property-level clicks and impressions
+for a window ending at least three days ago, and one day of crawler log rows
+against the CDN's own request analytics; a sampling tool has nothing to
+reconcile, so quote its dashboard with prompt set and dates.
+
+## Answer questions
+
+Read [analysis.md](analysis.md).
 
 ## Never
 
-- **Ask for a credential** in chat or as a command argument. A Google service
-  account key is a private key. If offered one, say not to send it and to rotate
-  it if already sent. Workflow step 6 has the safe path.
-- **Print a credential**, including in errors, summaries and generated files.
-- **Run against production** unless asked by name. Say which environment you used.
-- **Pull raw log rows or session records into context** when an aggregate
-  answers the question.
-- **Put a raw URL in output without stripping its parameters.** Query strings
-  carry session tokens, reset links and personal data.
-- **Publish content.** Drafting is fine; pushing to a CMS, a repository or a
-  live site is a write. Propose it and let a person publish.
-- **Change `robots.txt` or crawler directives** without explicit approval. A
-  wrong line here can deindex a site.
-- **Write without asking.** Installing, initialising, editing configuration or
-  models, and running a pipeline all wait for the user's yes.
-
-Stop and ask before any write to a source system, outbound message,
-publication, credential change, production access, `--full-refresh` or backfill.
-`--full-refresh` drops and recreates tables. On `google-web-analytics` the first
-run and any change to a classification variable need one on staging; scope it
-to the earliest export date and say the expected scan. On a log table whose
-bucket has expired old files, it discards history the source no longer holds.
-Name that consequence.
+- Ask for or print a credential; write, run, backfill, `--full-refresh` or
+  touch production without a yes; put personal data in output.
+- Publish content to a CMS, repository or live site; draft it and let a person publish.
+- Change `robots.txt` or crawler directives without explicit approval.
diff --git a/resources/startup-data-kit/ai-search-visibility/analysis.md b/resources/startup-data-kit/ai-search-visibility/analysis.md
index e2740d8..c817a7c 100644
--- a/resources/startup-data-kit/ai-search-visibility/analysis.md
+++ b/resources/startup-data-kit/ai-search-visibility/analysis.md
@@ -1,140 +1,33 @@
 # Answering search and AI visibility questions
 
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
-> docs](https://getbruin.com/docs/bruin/overview.html), Google's Search Console
-> documentation, or a measurement tool's own documentation, those are right and
-> this file is stale. This area moves faster than any other in this repository,
-> so treat specifics here as a starting point rather than current fact. Written
-> against Bruin CLI `v0.11.765`, checked 2026-10-01.
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`,
+> Google's Search Console documentation, or a measurement tool's own
+> documentation, those are right and this file is stale. Written against Bruin
+> CLI `v0.11.766`, checked 2026-10-01.
 
-Read this once data exists and the user is asking questions of it. If
-`decisions.md` sits beside the pipeline's `pipeline.yml`, read it first: it
-records which choices this setup follows. The `Never` rules in `SKILL.md` apply
-here too.
+Read `decisions.md` beside the pipeline's `pipeline.yml` first. The Never rules
+in [SKILL.md](SKILL.md) apply.
 
 ## Before answering
 
-1. **Name which of the three the question is about.** SEO, AI answer
-   visibility, or AI crawler traffic. They need different data and have very
-   different evidence quality.
-2. **Read the model before querying it.** If the user is on a template, read its
-   report assets and their descriptions before writing any SQL.
-3. **Check freshness first.** Read the last runs from Bruin Cloud MCP or
-   `bruin cloud runs list --output json`, then the maximum date in the raw
-   table.
+- On `google-web-analytics`, read the report assets before writing SQL.
+- Check freshness: the last runs (Bruin Cloud MCP or `bruin cloud runs list`), then the maximum date in the table.
+- Name which of the three the question is about: Search Console is measured, crawler logs are observed, AI answers are sampled.
+- Quote any AI visibility number with the tool, prompt set, assistants sampled and date range; without them it means nothing.
 
-## Search Console, the honest baseline
+## Traps
 
-This is where real, verifiable data lives.
+- Search Console clicks will not match GA4 organic sessions; anonymised queries count in totals but not rows; never average average position; leave the last three days out.
+- The template's value columns are modelled from key-event weights, not revenue.
+- Brand mention and source citation are separate reads; prompt-set changes move the score, and branded prompts inflate it.
+- Split crawlers into training, search-index and live user fetches (`GPTBot`, `OAI-SearchBot`, `ChatGPT-User`, `ClaudeBot`, `Claude-User`, `PerplexityBot`, `Google-Extended`, `Bytespider`, `Applebot-Extended`, `CCBot`); a live fetch is the nearest thing to a conversion signal.
+- Check `robots.txt` before reading a crawler's absence as a signal.
+- Push back on `llms.txt` as a ranking lever, keyword density, word-count targets, mass-generated content, or any fixed technique that "gets you into ChatGPT".
 
-- No sessions, no revenue. GSC clicks will not match GA4 organic sessions.
-- Roughly 16 months of history through the API. Load it into the warehouse if
-  longer matters. The bulk data export starts the day it was enabled and does
-  not backfill.
-- Two to three days of lag, and past days are revised in place. Leave the most
-  recent days out of any comparison.
-- Anonymised queries are excluded from query-level rows but counted in totals,
-  so breakdowns will not sum to the total. Do not try to reconcile them.
-- Average position is an average across impressions, weighted oddly. Averaging
-  it across queries compounds the problem. Prefer distributions.
+## What this data cannot tell you
 
-If the user is on the `google-web-analytics` template, it already builds query
-opportunities (`gsc_query_opportunities`), page decay (`gsc_page_trend`), new
-and lost queries (`gsc_new_and_lost_queries`) and the landing-page join to GA4
-(`ga4_gsc_landing_page_performance`). Read its README and use those before
-writing your own. Its value columns are modelled from weights on key events, not
-recognised revenue, so say so. Which organic pages produce paying customers
-still needs a landing-page-to-signup key.
-
-## Measuring AI answer visibility
-
-There is no crawl you can run to answer "do we appear in ChatGPT". Assistant
-answers vary by user, by session, by phrasing and by date. Any measurement is
-sampling, not observation.
-
-What that means in practice:
-
-- **Sampling tools** run a fixed prompt set on a schedule against several
-  assistants and record whether a brand was mentioned and which sources were
-  cited. [Peec AI](https://peec.ai) is one such tool and exposes an MCP server,
-  so an agent can query it directly. There are others. None of them observe real
-  user conversations.
-- **Brand mention and source citation are independent.** Being cited as a source
-  and being recommended are different outcomes and need separate reads.
-- **Prompt sets determine the score.** Adding, removing or reweighting prompts
-  moves visibility without anything changing about what assistants say. Never
-  treat prompt-set changes as an improvement, and be suspicious of branded
-  prompts, which score high only because the brand is in the question.
-- **Position and share of voice** are only comparable within a fixed prompt set
-  over time.
-
-When asked "how visible are we in AI search", the honest answer names the tool,
-the prompt set, the assistants sampled, and the date range. Without those the
-number means nothing.
-
-## AI crawler traffic, the measurable part
-
-Server and CDN logs show which AI crawlers fetch the site. This is real
-observation rather than sampling, and it is underused.
-
-Common agents to look for: `GPTBot`, `OAI-SearchBot`, `ChatGPT-User`,
-`ClaudeBot`, `Claude-User`, `PerplexityBot`, `Google-Extended`, `Bytespider`,
-`Applebot-Extended`, `CCBot`.
-
-Worth distinguishing: training crawlers, search-index crawlers, and live
-user-triggered fetches. A live fetch means a real person asked something and an
-assistant went to the site to answer it, which is the closest thing to a
-conversion signal this category has.
-
-Check `robots.txt` first: if these agents are disallowed, absence is the
-explanation and no amount of content work will change it.
-
-## Referral traffic from assistants
-
-GA4 shows referrals from `chatgpt.com`, `perplexity.ai`, `claude.ai` and
-similar. Volumes are usually small but the traffic often converts unusually well,
-because the person arrived with intent already formed.
-
-Track it as its own channel rather than letting it fall into direct or generic
-referral. It is the only place where AI visibility connects to revenue with
-evidence rather than inference.
-
-## Content work: what the evidence actually supports
-
-Keep recommendations to things with a mechanism, not a listicle.
-
-Reasonable:
-
-- Answer a specific question directly and early on the page. Both search
-  features and assistants extract passages.
-- Keep facts current and dated. Stale figures get cited and embarrass you.
-- Structured data where it maps to a real entity or product.
-- Be citable: clear claims, primary sources, a stable URL.
-- Presence on the sites assistants actually cite for your category, which is
-  often documentation, comparison sites and communities rather than your blog.
-- Allow the crawlers you want to be cited by.
-
-Unsupported, and worth pushing back on:
-
-- `llms.txt` as a ranking lever. No major assistant has committed to it.
-- Keyword density, word count targets, and generated content at volume.
-- Any claim of a fixed technique that "gets you into ChatGPT".
-
-Google's own guidance for AI search still points back to useful, original,
-trustworthy content. Say that when asked for a shortcut.
-
-## What this cannot tell you
-
-| Asked | Actually needed |
-|---|---|
-| "Are we in ChatGPT?" | A sampled prompt set with a stated date. There is no ground truth. |
-| "Why did rankings drop?" | Usually an algorithm update or a site change. Check the deploy log and update timelines before theorising. |
-| "How much revenue does SEO bring?" | Landing page carried through to signup and payment. Without that key, organic stops at clicks. |
-| "What should we write next?" | A gap between what people ask and what the site answers. GSC impressions without clicks is the best available proxy. |
-
-Report what is measured, what is sampled, and what is inferred. In this category
-that distinction matters more than in any other.
-
-## Reference
-
-- Traffic side: [../web-analytics/SKILL.md](../web-analytics/SKILL.md)
+- Whether "we are in ChatGPT": only a sampled prompt set on a stated date; there is no ground truth.
+- Why rankings dropped, until algorithm updates and the deploy log are checked.
+- Revenue from SEO, without a landing-page-to-signup key; organic stops at clicks.
+- What to write next, beyond impressions without clicks as a proxy.
diff --git a/resources/startup-data-kit/ai-search-visibility/workflow.md b/resources/startup-data-kit/ai-search-visibility/workflow.md
index 591061d..a3300e7 100644
--- a/resources/startup-data-kit/ai-search-visibility/workflow.md
+++ b/resources/startup-data-kit/ai-search-visibility/workflow.md
@@ -3,158 +3,73 @@
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
 > docs](https://getbruin.com/docs/bruin/overview.html) or `bruin <command>
 > --help`, upstream is right and this file is stale. Written against Bruin CLI
-> `v0.11.765`, checked 2026-10-01.
+> `v0.11.766`, checked 2026-10-01.
 
-Every skill in the startup data kit carries an identical copy of this file.
-The skill's own `SKILL.md` says which templates fit its domain and what tends to
-matter there; this file is the process. Work through it in order.
+Identical in every startup-data-kit skill. Work in order.
 
 ## Working with the user
 
-This is a conversation, not a script. The point of a maintained template is
-that the modelling is done; the point of this process is that it ends up
-modelling *this* startup, not a generic one.
-
-- **Check before acting.** Most users have done some of this already, and
-  redoing a step is how a working setup gets broken. Say what you checked and
-  what you found.
-- **Ask before every write.** Installing, initialising, editing configuration,
-  changing a model, running a pipeline: say exactly what will change and wait
-  for a yes. Show diffs.
-- **Ask a few questions at a time, each with the default.** For every choice,
-  say what the template does today, what the alternative would change, and why
-  it matters. "Keep the default" should be an easy answer.
-- **Explain the term, not just the question.** Many founders are not data
-  people. "MRR counted at month end" means nothing until you say what it does
-  to a mid-month signup.
-- **Do not guess an answer.** If the user does not know, propose the default
-  and record it as unconfirmed. A choice the user did not make should not read
-  as though they did.
-- **When only the user can do a step**, give them the exact steps and wait
-  until they say it is done.
-- **Write the answers down** as you go, in a `decisions.md` beside the
-  pipeline's `pipeline.yml`: each choice, what was picked, whether the user
-  confirmed it or it is still the template's default, and the date. The next
-  agent, and the user in six months, will need it.
+- **Check before acting;** say what you found. Never redo working steps.
+- **Ask before every write** (install, init, config, model, run); show the diff, wait for a yes.
+- **Ask a few questions at a time,** each with its default and the term in plain words.
+- **Do not guess.** If the user does not know, record the default as unconfirmed.
+- **When only the user can do a step,** give exact steps and wait.
+- **Record answers in `decisions.md` beside `pipeline.yml`:** choice, pick, confirmed or default, date.
 
-## 1. Bruin is installed
-
-```bash
-bruin version
-```
+## Look it up live
 
-- **Installed and current:** move on.
-- **Installed, but `Latest` is newer than `Current`:** offer `bruin upgrade`.
-  Do not run it unasked.
-- **Not installed:** ask, then run
-  `curl -LsSf https://getbruin.com/install/cli | sh` and check `bruin version`
-  again. On Windows, or if the install fails, read
-  `getting-started/introduction/installation` rather than guessing.
+- Commands and flags: `bruin <command> --help`.
+- Docs: Bruin MCP `bruin_get_doc_content` for `getting-started/templates-docs/<name>-README`, `ingestion/<source>`, `platforms/<warehouse>`; or `https://getbruin.com/docs/bruin/<path>.html`.
+- The user's pipelines, runs and connections: Bruin Cloud MCP (`cloud/mcp-setup`), if they run Bruin Cloud.
 
-## 2. The Bruin MCP server is connected
+## 1. Bruin is installed
 
-Check whether you already have the `bruin_get_docs_tree` and
-`bruin_get_doc_content` tools. If you do, move on.
+`bruin version`. If `Latest` is newer than `Current`, offer `bruin upgrade`. If missing, ask, then `curl -LsSf https://getbruin.com/install/cli | sh`; on Windows or failure, read `getting-started/introduction/installation`.
 
-If not, register it, because the rest of this skill reads Bruin's docs through
-it. Until then, read the same pages at
-`https://getbruin.com/docs/bruin/<path>.html`; the setup page is
-`getting-started/bruin-mcp`.
+## 2. The Bruin MCP server is connected
 
-- **If your host lets you change its MCP configuration**, show the exact
-  command or snippet from that page, say which file it changes and whether that
-  affects only this project or every project, and run it only after the user
-  approves. For Claude Code the page gives `claude mcp add bruin -- bruin mcp`.
-- **If you cannot**, walk the user through it: the snippet for their host, where
-  it goes, and that the host usually needs a restart or reload before the tools
-  appear.
+If you lack the `bruin_get_doc_content` tool, read `getting-started/bruin-mcp`.
 
-The local server serves Bruin's documentation only. Bruin Cloud MCP is separate
-(`cloud/mcp-setup`) and only worth setting up if the user runs Bruin Cloud.
+- If you can edit the host's MCP config, show the exact command (Claude Code: `claude mcp add bruin -- bruin mcp`) and its project or global scope; run it only after approval.
+- Otherwise give the user the snippet; the host usually needs a restart.
 
 ## 3. You are inside the user's own git repository
 
-```bash
-git rev-parse --show-toplevel
-```
-
-- **Not a repository:** ask which folder the project should live in, then
-  `git init` there. Without a repository, `bruin init` creates a `bruin/`
-  wrapper folder and initialises git inside that instead.
-- **A repository:** confirm it is the user's project. Never scaffold inside a
-  clone of a public catalogue such as this one, or inside another Bruin
-  project. A `.bruin.yml` higher up the tree gets picked up by mistake.
-- **A Bruin project already exists here** (a `.bruin.yml`, a `pipeline.yml`):
-  ask whether to add to it or start fresh. Adding a template to an existing
-  pipeline uses `bruin init <template> <pipeline-folder> --merge`; read
-  `commands/init` first, because it leaves `pipeline.yml` alone.
+`git rev-parse --show-toplevel`.
+
+- **Not a repository:** ask which folder, then `git init`; otherwise `bruin init` creates a `bruin/` wrapper with its own git.
+- **A repository:** confirm it is the user's, not a public catalogue or another Bruin project (a parent `.bruin.yml` gets picked up).
+- **Bruin project exists:** ask whether to add (`--merge`; read `commands/init`) or start fresh.
 
 ## 4. Confirm the warehouse
 
-Ask which database or warehouse the data should land in. Do not pick for them.
-The destination decides which templates exist at all, so ask before choosing a
-template.
+Ask where the data lands; do not pick. It decides which templates exist.
 
-- **They already have one:** use it. Keep the boundary they already run.
-- **They have none:** say which destinations the templates for this domain
-  support (`bruin init --help` lists every template; the destination is usually
-  in the name), and what each costs them in setup. Some templates run on local
-  DuckDB with nothing to provision.
-- **No template supports their warehouse:** say so plainly. Offer the closest
-  template on another destination, or ingestion alone with the modelling left to
-  build. Do not improvise a template.
+- **None yet:** list destinations this domain's templates support (`bruin init --help`) and their setup cost; some run on local DuckDB.
+- **No template supports it:** say so; offer the closest template elsewhere, or ingestion alone. Never improvise one.
 
 ## 5. Choose the template
 
-Use the domain's `SKILL.md` for which templates to consider and their caveats.
-Then confirm against the live list, because templates are added and renamed:
+1. `bruin init --help` for current names; keep those matching source and warehouse.
+2. Read each candidate's README; if none, say so and read the scaffolded `README.md`.
+3. Tell the user what each builds, needs and omits. Let them choose.
+4. After a yes, `bruin init <template>`. If it opens an interactive wizard, give the user the command.
+5. Read the scaffolded files, run `bruin validate <pipeline-folder>`, and tell the user anywhere they disagree with the README or fail.
 
-1. `bruin init --help` for the current names. Keep the ones that match the
-   user's source and the warehouse confirmed in step 4.
-2. Read each candidate's README before recommending it:
-   `getting-started/templates-docs/<name>-README`. Some templates have none; say
-   so and read the `README.md` it scaffolds instead.
-3. Tell the user what each candidate builds, what it needs, and what it does
-   not cover. Let them choose.
-
-Then `bruin init <template>`, after they agree. Some templates, such as
-`ecommerce`, open an interactive wizard and fail without a terminal; give the
-user the command to run themselves, and read what it wrote afterwards. If nothing fits, say so. Ingesting a source with no template means
-building the modelling yourself, which is a project; agree that with the user
-before starting it. Some questions need no pipeline at all; if so, say that
-too, rather than building one.
+If nothing fits, say so; agree before building modelling yourself. If no pipeline is needed, say so.
 
 ## 6. Credentials into `.bruin.yml`
 
-`bruin init` writes a `.bruin.yml` with placeholder connections. The template's README and that file say which connections it needs.
-
-**Never ask for a credential in chat or pass one as a command argument.** If the
-user pastes one, tell them not to send it and to rotate it, because it now sits
-in the transcript.
+The README and assets name the connections. A sample's inline key is a shape, not a value.
 
-For each connection:
+**Never ask for a credential in chat or pass one as a command argument.** If the user pastes one, tell them to rotate it.
 
-1. **Read what it needs.** `ingestion/<source>` for a source and
-   `platforms/<warehouse>` for a destination list the required fields and link
-   to the provider's own instructions.
-2. **Walk the user through getting it.** Where to click at the provider, and the
-   smallest scope that works: a read-only or restricted key, a service account
-   with read access, never an admin or live secret key when a narrower one
-   exists. A read-only credential is a control; a promise in a file is not.
-3. **Keep the value out of the file.** The user stores the secret in an
-   environment variable (a gitignored `.env` or `.envrc`, or their secret
-   manager) and you write `${VAR_NAME}` into `.bruin.yml` (`secrets/bruinyml`).
-   Or the user runs `bruin connections add` with no flags and answers its
-   prompts; its flag mode puts the secret on the command line.
-4. **Test it.** `bruin connections test --name <connection>`. Report the result,
-   never the value.
+1. Read `ingestion/<source>` or `platforms/<warehouse>` for the fields.
+2. Walk the user to the narrowest credential: read-only or restricted, never admin when narrower exists.
+3. The user sets an env var (gitignored `.env` or secret manager); you write `${VAR_NAME}` (`secrets/bruinyml`). Or the user runs `bruin connections add` with no flags.
+4. `bruin connections test --name <connection>`. Report the result, never the value.
 
-Then confirm `.bruin.yml` is ignored: `git check-ignore .bruin.yml`. If it is
-not, stop and fix that before anything else is committed.
-
-If the user runs Bruin Cloud, the same rule holds: `bruin cloud login`, or an
-exported `BRUIN_CLOUD_API_KEY`, never `--api-key` on the command line.
-`bruin auth status` shows which one is active without printing it.
+`git check-ignore .bruin.yml`; if not ignored, stop and fix first. Bruin Cloud: `bruin cloud login` or exported `BRUIN_CLOUD_API_KEY`, never `--api-key`.
 
 ## 7. Work out what to ask
 
@@ -164,69 +79,30 @@ exported `BRUIN_CLOUD_API_KEY`, never `--api-key` on the command line.
 > files. Read the template as it is today, list every choice it makes on the
 > user's behalf, and decide which ones this user needs to confirm.
 
-Where templates make choices:
-
-- **The README:** configuration sections, metric policy, first-run and
-  backfill steps, stated limitations.
-- **`pipeline.yml`:** variables and their defaults, schedule, start date.
-- **The assets:** descriptions, filters and `WHERE` clauses (statuses,
-  currencies, test accounts), materialisation, column checks.
-- **The report assets:** what each metric includes and excludes.
-
-Then filter. Use what you know about the business, and ask what you do not: a
-question about annual plans only matters if they sell annual plans. The domain's
-`SKILL.md` lists the areas that usually matter there. Treat it as a lens for
-spotting choices, not as the questions to ask.
-
-Group what is left by topic, lead with the ones that change the headline
-numbers, and ask. Add any business context the template needs but cannot infer,
-such as test or internal accounts to exclude, or how much history matters.
+- Read the README, `pipeline.yml` variables, asset filters, checks, and report metric definitions.
+- Drop choices that do not apply; `SKILL.md` is a lens, not a script.
+- Add what the template cannot infer (test accounts, history needed); lead with what moves headline numbers.
 
 ## 8. Customise
 
-Change the template to match the answers, one topic at a time.
-
-- **Prefer configuration to code.** A variable in `pipeline.yml` survives a
-  template update; an edited `WHERE` clause has to be carried forward by hand.
-- **When SQL has to change,** keep the edit small, and update the asset's
-  description to state the convention it now follows.
-- **After each change,** run `bruin validate <pipeline-folder>`, show the diff,
-  and record the decision in `decisions.md`.
+- Prefer a `pipeline.yml` variable to SQL edits; keep SQL edits small and update the asset description.
+- After each change: `bruin validate <pipeline-folder>`, show the diff, record it.
 
 ## 9. First run, bounded
 
-Before running, agree three things with the user and state them back:
-
-- **The environment.** `bruin environments list`. Most templates create only
-  `default`; creating or cloning another (`commands/environments`) is a change
-  that needs approval.
-- **The window.** `--start-date` and `--end-date`; a local run defaults to
-  yesterday only. Say the expected scan.
-- **The template's own first-load steps** from its README. If one is
-  `--full-refresh`, name what it replaces before asking.
+Agree and state back, then `bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>`:
 
-```bash
-bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>
-```
+- **Environment:** `bruin environments list`; creating one needs approval.
+- **Window:** a local run defaults to yesterday only. Say the expected scan.
+- **README first-load steps:** if one is `--full-refresh`, name what it replaces before asking.
 
-## 10. Check it against the source, together
+## 10. Reconcile with the user
 
-A pipeline that ran and a pipeline that loaded the right data are different
-claims. Pick one number the user can see in the source's own dashboard (last
-month's revenue, active subscriptions, sessions) and reconcile it with them.
+Compare one number from the source's own dashboard.
 
-- **The numbers match, or differ only because of a recorded decision:** say so,
-  and note the explanation in `decisions.md`.
-- **They differ and you cannot say why:** stop. Investigate before anyone uses
-  the reports.
+- **Differs only by a recorded decision:** note it in `decisions.md`.
+- **Differs unexplained:** stop; investigate before anyone uses the reports.
 
 ## 11. Hand off
 
-Tell the user, briefly:
-
-- the template, warehouse, environment and window that ran;
-- each decision, and which ones are still unconfirmed defaults;
-- what is scheduled (nothing, unless they asked for it);
-- what to connect next, if a question they care about needs a second domain.
-
-From here, questions about the data follow the domain's `analysis.md`.
+Report template, warehouse, environment, window, unconfirmed decisions, what is scheduled (nothing unless asked), and what to connect next. Then follow `analysis.md`.
diff --git a/resources/startup-data-kit/finance-accounting/SKILL.md b/resources/startup-data-kit/finance-accounting/SKILL.md
new file mode 100644
index 0000000..4ed496d
--- /dev/null
+++ b/resources/startup-data-kit/finance-accounting/SKILL.md
@@ -0,0 +1,69 @@
+---
+name: finance-accounting
+description: Use when a startup wants QuickBooks Online data set up or answered. Sets up the quickbooks-bigquery template and answers accounts receivable, aging, invoiced versus collected, customer concentration and vendor questions, and how the books differ from MRR.
+---
+
+# Finance and accounting
+
+**Status:** experimental · **Risk:** approval-required
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
+> Intuit's QuickBooks Online documentation, those are right and this file is
+> stale. Written against Bruin CLI `v0.11.766`, checked 2026-10-01.
+
+Sets up the QuickBooks template to how this company keeps its books and answers
+AR, collections and concentration questions from it. It exists to prevent a
+figure that looks like the books but was summed from a partial copy: the wrong
+company, mixed currencies, deleted transactions or an unclosed month.
+
+## Set up
+
+Follow [workflow.md](workflow.md).
+
+> **Important: do not ask a fixed list of questions.** Read the template as it
+> is today and work out which of its choices this user needs to confirm.
+> Templates change, so the questions change with them.
+
+**Templates:** `quickbooks-bigquery`; confirm with `bruin init --help`. Not on
+BigQuery: read `ingestion/quickbooks`; the modelling is theirs to build. No
+Xero or NetSuite connector existed when written; check the docs tree.
+
+**Watch for:**
+
+- Ingestion only, no reports: every AR or concentration figure is SQL you write.
+- Bills, expenses, credit memos, sales receipts and journal entries are not loaded: no P&L, balance sheet, burn or vendor spend.
+- Deletes are not picked up and inactive records still read active; only a full-window `--full-refresh` catches them.
+- Invoices are not MRR; with a billing system, MRR belongs to `revenue-analytics`.
+
+**Usually needs the user's input:**
+
+- Which company: the realm, production or sandbox (sandbox numbers are test data), and whether several companies must stay separate.
+- How revenue reaches the books: QuickBooks invoices, a billing sync posting invoices or sales receipts, or journal entries; only invoices load.
+- Cash or accrual, and which months the bookkeeper has closed.
+- Home currency, multi-currency and the FX policy; amounts are in transaction currency only.
+- Whether figures are before or after tax; invoice totals include it.
+- Customer grain (sub-customers are separate rows), and aging by due or invoice date, with buckets.
+- Deletes or voids, how often to full-refresh, and test, internal or intercompany customers to exclude.
+
+**Reconcile against:** QuickBooks' A/R aging summary against open invoice
+balances less unapplied payments, and one closed month's invoice total against
+its invoice list, on the same basis and as-of date.
+
+## Answer questions
+
+Read [analysis.md](analysis.md).
+
+## Never
+
+- Ask for or print a credential; write, run, backfill, `--full-refresh` or
+  touch production without a yes; put personal data in output.
+- Write to QuickBooks, whatever the OAuth scope allows, or `--full-refresh` a window narrower than the README's.
+- Sum amounts across currencies without a recorded FX policy.
+- Present a figure as the books, a financial statement or tax advice.
+
+## Unverified
+
+- Whether balances update when a new transaction posts; compare one bank account with QuickBooks after a busy day.
+- Whether Intuit offers a narrower scope than `com.intuit.quickbooks.accounting`; until its scope docs say so, treat the token as able to write.
+- Whether a credit memo application appears as a zero-amount payment; read `LinkedTxn` types on zero-total payments before cohorting collections.
diff --git a/resources/startup-data-kit/finance-accounting/analysis.md b/resources/startup-data-kit/finance-accounting/analysis.md
new file mode 100644
index 0000000..be83869
--- /dev/null
+++ b/resources/startup-data-kit/finance-accounting/analysis.md
@@ -0,0 +1,32 @@
+# Answering finance and accounting questions
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
+> Intuit's QuickBooks Online documentation, those are right and this file is
+> stale. Written against Bruin CLI `v0.11.766`, checked 2026-10-01.
+
+Read `decisions.md` beside the pipeline's `pipeline.yml` first. The Never rules
+in [SKILL.md](SKILL.md) apply.
+
+## Before answering
+
+- Read the asset descriptions before writing SQL.
+- Check freshness: the last runs (Bruin Cloud MCP or `bruin cloud runs list`), and that the period is closed; a reopened month changing is the bookkeeper's change, not a bug.
+- Check the company and environment; two companies are not one business until someone says how to consolidate.
+- State the basis, as-of date, currency and company, and which unloaded transaction types bear on the answer.
+
+## Traps
+
+- Invoiced (accrual billing, including tax) is not recognised revenue, and collected is not cash in the bank; never relabel one as another.
+- Balances are open amounts at the last load, so past-date AR means rebuilding from payment lines; subtract unapplied payments, and expect QuickBooks' aging to read lower by the open credit memos.
+- Measure cash from payment totals, not summed applied lines; one payment covers many invoices, and an application can be a credit.
+- A deleted invoice keeps its last balance until a full refresh, and there is no void flag; check before chasing an "overdue" invoice.
+- Concentration on a short window is mostly timing; report by QuickBooks ID, not name.
+- Books and billing will not match: an annual plan is twelve months of MRR and one invoice, there is no shared customer key, and a synced charge added to billing is the same money twice.
+
+## What this data cannot tell you
+
+- Burn, runway or vendor spend: bills, expenses, payroll and bank balances are not loaded.
+- Gross margin, P&L or balance sheet: use QuickBooks' own reports.
+- MRR: use the billing system, in `revenue-analytics`.
+- Tax owed: that is the accountant's; never answer it from this data.
diff --git a/resources/startup-data-kit/finance-accounting/workflow.md b/resources/startup-data-kit/finance-accounting/workflow.md
new file mode 100644
index 0000000..a3300e7
--- /dev/null
+++ b/resources/startup-data-kit/finance-accounting/workflow.md
@@ -0,0 +1,108 @@
+# Setting up a template with the user
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html) or `bruin <command>
+> --help`, upstream is right and this file is stale. Written against Bruin CLI
+> `v0.11.766`, checked 2026-10-01.
+
+Identical in every startup-data-kit skill. Work in order.
+
+## Working with the user
+
+- **Check before acting;** say what you found. Never redo working steps.
+- **Ask before every write** (install, init, config, model, run); show the diff, wait for a yes.
+- **Ask a few questions at a time,** each with its default and the term in plain words.
+- **Do not guess.** If the user does not know, record the default as unconfirmed.
+- **When only the user can do a step,** give exact steps and wait.
+- **Record answers in `decisions.md` beside `pipeline.yml`:** choice, pick, confirmed or default, date.
+
+## Look it up live
+
+- Commands and flags: `bruin <command> --help`.
+- Docs: Bruin MCP `bruin_get_doc_content` for `getting-started/templates-docs/<name>-README`, `ingestion/<source>`, `platforms/<warehouse>`; or `https://getbruin.com/docs/bruin/<path>.html`.
+- The user's pipelines, runs and connections: Bruin Cloud MCP (`cloud/mcp-setup`), if they run Bruin Cloud.
+
+## 1. Bruin is installed
+
+`bruin version`. If `Latest` is newer than `Current`, offer `bruin upgrade`. If missing, ask, then `curl -LsSf https://getbruin.com/install/cli | sh`; on Windows or failure, read `getting-started/introduction/installation`.
+
+## 2. The Bruin MCP server is connected
+
+If you lack the `bruin_get_doc_content` tool, read `getting-started/bruin-mcp`.
+
+- If you can edit the host's MCP config, show the exact command (Claude Code: `claude mcp add bruin -- bruin mcp`) and its project or global scope; run it only after approval.
+- Otherwise give the user the snippet; the host usually needs a restart.
+
+## 3. You are inside the user's own git repository
+
+`git rev-parse --show-toplevel`.
+
+- **Not a repository:** ask which folder, then `git init`; otherwise `bruin init` creates a `bruin/` wrapper with its own git.
+- **A repository:** confirm it is the user's, not a public catalogue or another Bruin project (a parent `.bruin.yml` gets picked up).
+- **Bruin project exists:** ask whether to add (`--merge`; read `commands/init`) or start fresh.
+
+## 4. Confirm the warehouse
+
+Ask where the data lands; do not pick. It decides which templates exist.
+
+- **None yet:** list destinations this domain's templates support (`bruin init --help`) and their setup cost; some run on local DuckDB.
+- **No template supports it:** say so; offer the closest template elsewhere, or ingestion alone. Never improvise one.
+
+## 5. Choose the template
+
+1. `bruin init --help` for current names; keep those matching source and warehouse.
+2. Read each candidate's README; if none, say so and read the scaffolded `README.md`.
+3. Tell the user what each builds, needs and omits. Let them choose.
+4. After a yes, `bruin init <template>`. If it opens an interactive wizard, give the user the command.
+5. Read the scaffolded files, run `bruin validate <pipeline-folder>`, and tell the user anywhere they disagree with the README or fail.
+
+If nothing fits, say so; agree before building modelling yourself. If no pipeline is needed, say so.
+
+## 6. Credentials into `.bruin.yml`
+
+The README and assets name the connections. A sample's inline key is a shape, not a value.
+
+**Never ask for a credential in chat or pass one as a command argument.** If the user pastes one, tell them to rotate it.
+
+1. Read `ingestion/<source>` or `platforms/<warehouse>` for the fields.
+2. Walk the user to the narrowest credential: read-only or restricted, never admin when narrower exists.
+3. The user sets an env var (gitignored `.env` or secret manager); you write `${VAR_NAME}` (`secrets/bruinyml`). Or the user runs `bruin connections add` with no flags.
+4. `bruin connections test --name <connection>`. Report the result, never the value.
+
+`git check-ignore .bruin.yml`; if not ignored, stop and fix first. Bruin Cloud: `bruin cloud login` or exported `BRUIN_CLOUD_API_KEY`, never `--api-key`.
+
+## 7. Work out what to ask
+
+> **The questions come from the template, not from a list.** Templates change:
+> variables are added, defaults move, reports appear and disappear. Do not work
+> from a remembered or hard-coded set of questions, including any in these
+> files. Read the template as it is today, list every choice it makes on the
+> user's behalf, and decide which ones this user needs to confirm.
+
+- Read the README, `pipeline.yml` variables, asset filters, checks, and report metric definitions.
+- Drop choices that do not apply; `SKILL.md` is a lens, not a script.
+- Add what the template cannot infer (test accounts, history needed); lead with what moves headline numbers.
+
+## 8. Customise
+
+- Prefer a `pipeline.yml` variable to SQL edits; keep SQL edits small and update the asset description.
+- After each change: `bruin validate <pipeline-folder>`, show the diff, record it.
+
+## 9. First run, bounded
+
+Agree and state back, then `bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>`:
+
+- **Environment:** `bruin environments list`; creating one needs approval.
+- **Window:** a local run defaults to yesterday only. Say the expected scan.
+- **README first-load steps:** if one is `--full-refresh`, name what it replaces before asking.
+
+## 10. Reconcile with the user
+
+Compare one number from the source's own dashboard.
+
+- **Differs only by a recorded decision:** note it in `decisions.md`.
+- **Differs unexplained:** stop; investigate before anyone uses the reports.
+
+## 11. Hand off
+
+Report template, warehouse, environment, window, unconfirmed decisions, what is scheduled (nothing unless asked), and what to connect next. Then follow `analysis.md`.
diff --git a/resources/startup-data-kit/marketing-analytics/SKILL.md b/resources/startup-data-kit/marketing-analytics/SKILL.md
index d5de40a..e244dfb 100644
--- a/resources/startup-data-kit/marketing-analytics/SKILL.md
+++ b/resources/startup-data-kit/marketing-analytics/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: marketing-analytics
-description: Use when a startup wants marketing analytics set up or answered. Walks the user through installing Bruin, choosing a template or ingesting their ad, email and CRM sources (Google Ads, Meta, TikTok, LinkedIn, HubSpot, Klaviyo, Salesforce), customising attribution, currency, timezone and cost definitions to their business, then answers CAC, ROAS, attribution and campaign questions from it.
+description: Use when a startup wants marketing analytics set up or answered. Sets up ad, email and CRM sources (Google Ads, Meta, TikTok, LinkedIn, HubSpot, Klaviyo, Salesforce) and answers CAC, ROAS, attribution and campaign questions.
 ---
 
 # Marketing analytics
@@ -9,137 +9,53 @@ description: Use when a startup wants marketing analytics set up or answered. Wa
 
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
 > docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or an ad
-> platform's own documentation, those are right and this file is stale. Ad
-> platform metric definitions and attribution windows change often and without
-> notice; check them rather than trusting a description here. Written against
-> Bruin CLI `v0.11.765`, checked 2026-10-01. Each platform's own spend report is
-> the reference you reconcile against, not this file.
-
-Two jobs. **Set up:** work with the user to ingest their marketing sources, on a
-maintained Bruin template where one fits, and customise it to how this business
-buys and counts. **Answer:** questions from what it built, in
-[analysis.md](analysis.md).
-
-Attribution is a modelling choice, not a measurement. The failure mode is a
-precise, well presented ROAS that means nothing. Most of it is prevented during
-setup, by asking the user what the model would otherwise assume.
-
-## Look it up live
-
-This file says what to reach for and what to be careful about. For the facts
-themselves, ask the tool, and tell the user if it disagrees with this file:
-
-- **Flags:** `bruin <command> --help`. The docs lag the CLI.
-- **Docs:** the local Bruin MCP server, `bruin_get_doc_content('<path>')`, or
-  `https://getbruin.com/docs/bruin/<path>.html` without it. For this skill:
-  `bruin_get_docs_tree` (the `ingestion/` section) for which ad, lifecycle, CRM
-  and attribution sources exist, `ingestion/<source>` (for example
-  `ingestion/google-ads`, `ingestion/facebook-ads`) for a source's tables and
-  connection fields, `getting-started/templates-docs/ecommerce-README`,
-  `ingestion/frankfurter` for FX rates, and `quality/overview`. Page names can
-  differ from the connection type key (`google-ads` is `googleads`).
-- **The user's environment:** Bruin Cloud MCP, or
-  `bruin cloud ... --output json`.
-
-## Setting it up
-
-Follow [workflow.md](workflow.md) from the top: install, MCP, repository,
-warehouse, template, credentials, then the questions. It is the same process
-for every skill in this kit. What is specific to marketing is below.
+> platform's documentation, those are right and this file is stale. Written
+> against Bruin CLI `v0.11.766`, checked 2026-10-01.
+
+Sets up the user's ad, lifecycle and CRM sources, on a template where one fits,
+and answers CAC, ROAS and campaign questions. It exists to prevent a precise,
+well presented ROAS that means nothing: attribution is a modelling choice, not
+a measurement.
+
+## Set up
+
+Follow [workflow.md](workflow.md).
 
 > **Important: do not ask a fixed list of questions.** Read the template as it
 > is today and work out which of its choices this user needs to confirm.
-> Templates change, so the questions change with them. Workflow step 7 says how.
-
-### Templates to consider
-
-Ask which ad platforms they spend on, and which carries most of the spend. Ask
-which email or lifecycle tool and which CRM they use, and where revenue lives,
-since CAC and ROAS need it. Start with the biggest platform and get it
-reconciling before adding the next.
-
-Then check `bruin init --help`. Few templates cover marketing. At the time of
-writing, only `ecommerce` modelled ad spend. Caveats the README will not flag:
-
-- **`ecommerce`** always includes Shopify. Its wizard offers ClickHouse,
-  BigQuery or Snowflake; Shopify Payments or Stripe; Klaviyo or HubSpot;
-  Facebook, Google and TikTok ads; GA4 or Mixpanel. It is not a general
-  marketing template. Without Shopify it does not fit.
-- **The wizard needs an interactive terminal.** `bruin init ecommerce` fails
-  without one. Give the user the command and let them answer its prompts, then
-  read what it generated.
-- **Its `rpt_marketing_roi` is not attribution.** As checked in `v0.11.765`, it
-  joins paid orders to web sessions on date alone, so its `attributed_revenue`
-  and `roas` overcount. `stg_marketing_spend` labels every ad platform
-  `paid_ads`, while GA4 sessions from Google or TikTok land in `paid_search` or
-  `other`. `cost_per_acquisition` sums platform-reported conversions across
-  platforms. Show the user the SQL and agree a fix before anyone quotes it.
-- **`demo-snowflake-salesforce`** is a demo. Its seed asset writes dummy records
-  into Salesforce, and its first run uses `--full-refresh`. Never point it at
-  the user's real org.
-- **`google-web-analytics`** is organic search from GA4 and Search Console, with
-  no ad spend. That is the `web-analytics` skill.
-
-For anything else (LinkedIn, Reddit, Snapchat, Apple Ads, AppsFlyer, Adjust,
-HubSpot, Salesforce, Klaviyo without Shopify), read `ingestion/<source>`.
-Ingesting it is easy; the channel mapping, attribution and join to revenue are
-the work. Say that no template fits, and agree the modelling with the user
-before starting.
-
-### What usually matters here
-
-A lens for reading the template, not a script. For each, find what the template
-or ingested source does, then ask only where this business makes it matter.
-[analysis.md](analysis.md) explains why each one moves the number.
-
-- **Attribution model and window:** platform reported, last touch, first touch,
-  or self-reported at signup, and each platform's click and view windows.
-- **Which conversions count:** platform-reported conversions, or new customers
-  from billing. View-through in or out.
-- **Channel mapping:** how sources, mediums and campaigns map to channels.
-- **Currency:** each ad account's currency, and whether to convert or report per
-  currency.
-- **Timezone:** each ad account's timezone against the warehouse and billing.
-- **Cost basis:** spend gross or net of platform fees, agency fees, credits and
-  rebates.
-- **Revenue basis:** ROAS on gross or net of refunds.
-- **Identity join to revenue:** the shared identifier between ad, web and billing
-  data (click ID, UTM, customer ID). If none exists, building it is the work.
-- **What to exclude:** test or internal accounts, and campaigns or accounts that
-  belong to another business line.
-- **History and late conversions:** how far back matters, and whether the load
-  re-reads recent days while conversions are still landing.
-
-### Reconcile against
-
-Each ad platform's own spend report for one recent full month, in the account's
-currency and timezone. Reconcile spend first: it is deterministic. Platform
-conversions will not match billing by design; compare new customers against the
-billing system instead. Record each gap and its explanation.
-
-## Answering questions afterwards
-
-Read [analysis.md](analysis.md): what to check before answering, why platform
-numbers disagree, and what marketing data cannot tell you. If the user is on a
-template, read its report assets before writing any SQL. Rebuilding that logic
-inline is how two answers to the same question start to differ.
+> Templates change, so the questions change with them.
+
+**Templates:** `ecommerce`; confirm with `bruin init --help`. For anything else
+(LinkedIn, Reddit, Snapchat, Apple Ads, AppsFlyer, Adjust, HubSpot, Salesforce,
+Klaviyo without Shopify), read `ingestion/<source>`; the modelling is theirs to
+build.
+
+**Watch for:**
+
+- `ecommerce` always includes Shopify; without Shopify it does not fit.
+- `google-web-analytics` is organic search with no ad spend; that is `web-analytics`.
+
+**Usually needs the user's input:**
+
+- Attribution: platform reported, last touch, first touch or self-reported; click and view windows; platform conversions or new customers from billing.
+- Channel mapping: how sources, mediums and campaigns map to channels.
+- Currency and timezone of each ad account, against the warehouse and billing.
+- Cost basis (gross or net of platform and agency fees, credits, rebates) and revenue basis (gross or net of refunds).
+- Identity join to revenue: click ID, UTM or customer ID; if none exists, building it is the work.
+- Exclusions: test or internal accounts, and campaigns from another business line.
+- History, and whether the load re-reads recent days while conversions land.
+
+**Reconcile against:** each ad platform's own spend report for one recent full
+month, in the account's currency and timezone, biggest-spend platform first;
+compare new customers against billing, not platform conversions.
+
+## Answer questions
+
+Read [analysis.md](analysis.md).
 
 ## Never
 
-- **Ask for a credential** in chat or as a command argument. If offered one, say
-  not to send it and to rotate it if already sent. Workflow step 6 has the
-  safe path.
-- **Print a credential**, including in errors, summaries and generated files.
-- **Write to an ad platform.** Pausing a campaign, changing a budget or sending
-  an email is a write with immediate money and reputation consequences. Read
-  only. Propose the change and let a person make it.
-- **Send marketing email.** Even a test. Stop and ask.
-- **Run against production** unless asked by name. Say which environment you used.
-- **Pull contact lists into context.** Names, emails and phone numbers are rarely
-  needed for analysis. Aggregate or use identifiers.
-- **Write without asking.** Installing, initialising, editing configuration or
-  models, and running a pipeline all wait for the user's yes.
-
-Stop and ask before any write to a source system, outbound message,
-publication, credential change, production access, `--full-refresh` or backfill.
-Name what a `--full-refresh` replaces before asking.
+- Ask for or print a credential; write, run, backfill, `--full-refresh` or
+  touch production without a yes; put personal data in output.
+- Write to an ad platform (pause a campaign, change a budget) or send marketing email, even a test.
+- Point `demo-snowflake-salesforce` at a real Salesforce org; its seed asset writes dummy records.
diff --git a/resources/startup-data-kit/marketing-analytics/analysis.md b/resources/startup-data-kit/marketing-analytics/analysis.md
index d1c68ca..7b7b6f4 100644
--- a/resources/startup-data-kit/marketing-analytics/analysis.md
+++ b/resources/startup-data-kit/marketing-analytics/analysis.md
@@ -2,118 +2,31 @@
 
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
 > docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or an ad
-> platform's own documentation, those are right and this file is stale. Ad
-> platform metric definitions and attribution windows change often and without
-> notice; check them rather than trusting a description here. Written against
-> Bruin CLI `v0.11.765`, checked 2026-10-01.
+> platform's documentation, those are right and this file is stale. Written
+> against Bruin CLI `v0.11.766`, checked 2026-10-01.
 
-Read this once a marketing pipeline exists and the user is asking questions of
-it. If `decisions.md` sits beside the pipeline's `pipeline.yml`, read it first:
-it records which attribution model, currency, timezone and cost basis this model
-follows. The `Never` rules in `SKILL.md` apply here too.
+Read `decisions.md` beside the pipeline's `pipeline.yml` first. The Never rules
+in [SKILL.md](SKILL.md) apply.
 
-Marketing data is the easiest place to produce a number that is precise, well
-presented, and meaningless. Attribution is a modelling choice, not a
-measurement, and the main job here is keeping that visible.
+## Before answering
 
-## Before answering any marketing question
+- Read the report and model assets before writing SQL; channel mapping and joins live there, not in column names.
+- Check freshness per platform: the last runs (Bruin Cloud MCP or `bruin cloud runs list`), then the maximum date in each raw ad table; one platform failing to load reads as that channel's spend dropping.
+- State source, window, attribution model, currency and cost basis with every number.
+- CAC, ROAS and payback need spend joined to billing; if that identity join does not exist, say so rather than answering from one side.
 
-1. **Read the model before querying it.** Asset descriptions and SQL say how
-   channels are mapped and what is joined to what. Do not infer meaning from
-   column names.
-2. **Prefer report tables over raw tables**, after reading the report's SQL.
-3. **Check freshness.** Read the last runs from Bruin Cloud MCP or
-   `bruin cloud runs list --output json`, then the maximum date in each raw ad
-   table. One platform failing to load reads as that channel's spend dropping.
+## Traps
 
-If the user is on the `ecommerce` template, read `rpt_marketing_roi` before
-quoting it. As checked against the template shipped with `v0.11.765`, its
-`attributed_revenue` joins paid orders to web sessions on date alone, so each
-day's paid revenue is counted against every channel with sessions that day, once
-per session row. That is not an attribution model, and its `roas` inherits the
-problem. Read the SQL in the user's copy, since the template may have changed
-or been customised.
-
-## Start with one platform, not all of them
-
-Connecting five ad platforms before any of them reconciles produces a dashboard
-nobody trusts. Get one platform matching its own UI first, then add the next.
-
-Ask which platform carries most of the spend and start there.
-
-## The numbers only mean something together
-
-Spend alone is an expense report. These are the joins that make it analysis:
-
-| Question | Needs |
-|---|---|
-| CAC by channel | Ad spend joined to new customers from billing |
-| ROAS | Ad spend joined to revenue, over a stated window |
-| Payback period | CAC joined to the revenue curve per cohort |
-| Which channel brings customers who stay | Acquisition channel carried through to retention |
-| Pipeline conversion | CRM stages joined to closed revenue |
-
-Every one of these crosses into another source. If the identity join does not
-exist, that is the work, not a detail of it. Say so rather than producing a
-number from whichever side happens to be available.
-
-## Attribution is a choice, so name it
-
-Platform-reported conversions do not agree with each other and do not agree with
-your billing data. This is expected, not a bug.
-
-- **Each platform claims credit for the same conversion.** Sum them and you get
-  more conversions than you had customers. Never add conversions across
-  platforms.
-- **Attribution windows differ per platform and are configurable.** A 7-day
-  click window and a 28-day window are different questions.
-- **View-through conversions** inflate platform numbers relative to anything
-  you can verify yourself.
-- **iOS ATT and cookie loss** mean platform attribution degraded years ago.
-
-State which attribution model is in use with any channel-level claim: platform
-reported, last touch, first touch, or self-reported at signup. Say when the
-model cannot settle a question, and say what would.
-
-Self-reported attribution ("how did you hear about us") is unfashionable and
-often the most honest signal available for early-stage companies.
-
-## Currency, timezone and cost definitions
-
-Small things that cause persistent unexplained gaps:
-
-- **Currency.** Ad platforms report in the account currency. Decide the
-  conversion policy, same as for revenue.
-- **Timezone.** Platforms report in the ad account's timezone, which is often
-  not the warehouse timezone or the billing timezone. A daily join across two
-  timezones is off by a partial day, every day.
-- **Cost basis.** Is spend gross or net of platform fees, agency fees, credits
-  and rebates? Say which.
-- **Refunds.** ROAS on gross revenue and ROAS on net revenue are different
-  numbers.
-
-## Traps worth checking before reporting
-
-- **Averaging rates.** The average of daily CTRs is not the CTR. Sum the
-  numerators and denominators, then divide.
-- **Comparing periods of different length.** A 28-day month against a 31-day
-  month is a 10% difference before anything happened.
-- **Small denominators.** A campaign with 40 clicks and 2 conversions has a 5%
-  conversion rate and also almost no information. Report the denominator.
-- **Late attribution.** Recent days are undercounted because conversions are
-  still landing. Never compare an incomplete recent window against a complete
-  older one without labelling it.
-- **Renamed campaigns.** A renamed campaign looks like one ending and another
-  starting. Join on ID, not name.
+- Never add conversions across platforms; each claims credit for the same one.
+- Attribution windows differ per platform, view-through inflates platform numbers, and iOS ATT and cookie loss degraded platform attribution.
+- A daily join across two timezones is off by a partial day, every day.
+- The average of daily rates is not the rate: sum numerators and denominators, and report the denominator.
+- Recent days undercount while conversions land, and months differ in length; label incomplete or unequal windows.
+- A renamed campaign looks like one ending and another starting; join on ID, not name.
 
 ## What this data cannot tell you
 
-| Asked | Actually needed |
-|---|---|
-| "Which channel caused this growth?" | An experiment or a holdout. Correlated spend and growth is a hypothesis. |
-| "Should we cut this channel?" | Incrementality, not attributed ROAS. A channel can score well and be claiming credit for customers who would have arrived anyway. |
-| "Why did CPMs rise?" | Usually auction dynamics you cannot see. Say so rather than inventing a reason. |
-| "What is our true CAC?" | A decision about which costs count: paid only, plus salaries, plus tooling. Ask. |
-
-Say what is missing and offer the concrete next step. Do not produce an
-approximation without labelling it as one.
+- Which channel caused growth: that needs an experiment or holdout.
+- Whether to cut a channel: that needs incrementality, not attributed ROAS.
+- Why CPMs rose: usually auction dynamics you cannot see; say so.
+- True CAC: which costs count (paid only, salaries, tooling) is a decision; ask.
diff --git a/resources/startup-data-kit/marketing-analytics/workflow.md b/resources/startup-data-kit/marketing-analytics/workflow.md
index 591061d..a3300e7 100644
--- a/resources/startup-data-kit/marketing-analytics/workflow.md
+++ b/resources/startup-data-kit/marketing-analytics/workflow.md
@@ -3,158 +3,73 @@
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
 > docs](https://getbruin.com/docs/bruin/overview.html) or `bruin <command>
 > --help`, upstream is right and this file is stale. Written against Bruin CLI
-> `v0.11.765`, checked 2026-10-01.
+> `v0.11.766`, checked 2026-10-01.
 
-Every skill in the startup data kit carries an identical copy of this file.
-The skill's own `SKILL.md` says which templates fit its domain and what tends to
-matter there; this file is the process. Work through it in order.
+Identical in every startup-data-kit skill. Work in order.
 
 ## Working with the user
 
-This is a conversation, not a script. The point of a maintained template is
-that the modelling is done; the point of this process is that it ends up
-modelling *this* startup, not a generic one.
-
-- **Check before acting.** Most users have done some of this already, and
-  redoing a step is how a working setup gets broken. Say what you checked and
-  what you found.
-- **Ask before every write.** Installing, initialising, editing configuration,
-  changing a model, running a pipeline: say exactly what will change and wait
-  for a yes. Show diffs.
-- **Ask a few questions at a time, each with the default.** For every choice,
-  say what the template does today, what the alternative would change, and why
-  it matters. "Keep the default" should be an easy answer.
-- **Explain the term, not just the question.** Many founders are not data
-  people. "MRR counted at month end" means nothing until you say what it does
-  to a mid-month signup.
-- **Do not guess an answer.** If the user does not know, propose the default
-  and record it as unconfirmed. A choice the user did not make should not read
-  as though they did.
-- **When only the user can do a step**, give them the exact steps and wait
-  until they say it is done.
-- **Write the answers down** as you go, in a `decisions.md` beside the
-  pipeline's `pipeline.yml`: each choice, what was picked, whether the user
-  confirmed it or it is still the template's default, and the date. The next
-  agent, and the user in six months, will need it.
+- **Check before acting;** say what you found. Never redo working steps.
+- **Ask before every write** (install, init, config, model, run); show the diff, wait for a yes.
+- **Ask a few questions at a time,** each with its default and the term in plain words.
+- **Do not guess.** If the user does not know, record the default as unconfirmed.
+- **When only the user can do a step,** give exact steps and wait.
+- **Record answers in `decisions.md` beside `pipeline.yml`:** choice, pick, confirmed or default, date.
 
-## 1. Bruin is installed
-
-```bash
-bruin version
-```
+## Look it up live
 
-- **Installed and current:** move on.
-- **Installed, but `Latest` is newer than `Current`:** offer `bruin upgrade`.
-  Do not run it unasked.
-- **Not installed:** ask, then run
-  `curl -LsSf https://getbruin.com/install/cli | sh` and check `bruin version`
-  again. On Windows, or if the install fails, read
-  `getting-started/introduction/installation` rather than guessing.
+- Commands and flags: `bruin <command> --help`.
+- Docs: Bruin MCP `bruin_get_doc_content` for `getting-started/templates-docs/<name>-README`, `ingestion/<source>`, `platforms/<warehouse>`; or `https://getbruin.com/docs/bruin/<path>.html`.
+- The user's pipelines, runs and connections: Bruin Cloud MCP (`cloud/mcp-setup`), if they run Bruin Cloud.
 
-## 2. The Bruin MCP server is connected
+## 1. Bruin is installed
 
-Check whether you already have the `bruin_get_docs_tree` and
-`bruin_get_doc_content` tools. If you do, move on.
+`bruin version`. If `Latest` is newer than `Current`, offer `bruin upgrade`. If missing, ask, then `curl -LsSf https://getbruin.com/install/cli | sh`; on Windows or failure, read `getting-started/introduction/installation`.
 
-If not, register it, because the rest of this skill reads Bruin's docs through
-it. Until then, read the same pages at
-`https://getbruin.com/docs/bruin/<path>.html`; the setup page is
-`getting-started/bruin-mcp`.
+## 2. The Bruin MCP server is connected
 
-- **If your host lets you change its MCP configuration**, show the exact
-  command or snippet from that page, say which file it changes and whether that
-  affects only this project or every project, and run it only after the user
-  approves. For Claude Code the page gives `claude mcp add bruin -- bruin mcp`.
-- **If you cannot**, walk the user through it: the snippet for their host, where
-  it goes, and that the host usually needs a restart or reload before the tools
-  appear.
+If you lack the `bruin_get_doc_content` tool, read `getting-started/bruin-mcp`.
 
-The local server serves Bruin's documentation only. Bruin Cloud MCP is separate
-(`cloud/mcp-setup`) and only worth setting up if the user runs Bruin Cloud.
+- If you can edit the host's MCP config, show the exact command (Claude Code: `claude mcp add bruin -- bruin mcp`) and its project or global scope; run it only after approval.
+- Otherwise give the user the snippet; the host usually needs a restart.
 
 ## 3. You are inside the user's own git repository
 
-```bash
-git rev-parse --show-toplevel
-```
-
-- **Not a repository:** ask which folder the project should live in, then
-  `git init` there. Without a repository, `bruin init` creates a `bruin/`
-  wrapper folder and initialises git inside that instead.
-- **A repository:** confirm it is the user's project. Never scaffold inside a
-  clone of a public catalogue such as this one, or inside another Bruin
-  project. A `.bruin.yml` higher up the tree gets picked up by mistake.
-- **A Bruin project already exists here** (a `.bruin.yml`, a `pipeline.yml`):
-  ask whether to add to it or start fresh. Adding a template to an existing
-  pipeline uses `bruin init <template> <pipeline-folder> --merge`; read
-  `commands/init` first, because it leaves `pipeline.yml` alone.
+`git rev-parse --show-toplevel`.
+
+- **Not a repository:** ask which folder, then `git init`; otherwise `bruin init` creates a `bruin/` wrapper with its own git.
+- **A repository:** confirm it is the user's, not a public catalogue or another Bruin project (a parent `.bruin.yml` gets picked up).
+- **Bruin project exists:** ask whether to add (`--merge`; read `commands/init`) or start fresh.
 
 ## 4. Confirm the warehouse
 
-Ask which database or warehouse the data should land in. Do not pick for them.
-The destination decides which templates exist at all, so ask before choosing a
-template.
+Ask where the data lands; do not pick. It decides which templates exist.
 
-- **They already have one:** use it. Keep the boundary they already run.
-- **They have none:** say which destinations the templates for this domain
-  support (`bruin init --help` lists every template; the destination is usually
-  in the name), and what each costs them in setup. Some templates run on local
-  DuckDB with nothing to provision.
-- **No template supports their warehouse:** say so plainly. Offer the closest
-  template on another destination, or ingestion alone with the modelling left to
-  build. Do not improvise a template.
+- **None yet:** list destinations this domain's templates support (`bruin init --help`) and their setup cost; some run on local DuckDB.
+- **No template supports it:** say so; offer the closest template elsewhere, or ingestion alone. Never improvise one.
 
 ## 5. Choose the template
 
-Use the domain's `SKILL.md` for which templates to consider and their caveats.
-Then confirm against the live list, because templates are added and renamed:
+1. `bruin init --help` for current names; keep those matching source and warehouse.
+2. Read each candidate's README; if none, say so and read the scaffolded `README.md`.
+3. Tell the user what each builds, needs and omits. Let them choose.
+4. After a yes, `bruin init <template>`. If it opens an interactive wizard, give the user the command.
+5. Read the scaffolded files, run `bruin validate <pipeline-folder>`, and tell the user anywhere they disagree with the README or fail.
 
-1. `bruin init --help` for the current names. Keep the ones that match the
-   user's source and the warehouse confirmed in step 4.
-2. Read each candidate's README before recommending it:
-   `getting-started/templates-docs/<name>-README`. Some templates have none; say
-   so and read the `README.md` it scaffolds instead.
-3. Tell the user what each candidate builds, what it needs, and what it does
-   not cover. Let them choose.
-
-Then `bruin init <template>`, after they agree. Some templates, such as
-`ecommerce`, open an interactive wizard and fail without a terminal; give the
-user the command to run themselves, and read what it wrote afterwards. If nothing fits, say so. Ingesting a source with no template means
-building the modelling yourself, which is a project; agree that with the user
-before starting it. Some questions need no pipeline at all; if so, say that
-too, rather than building one.
+If nothing fits, say so; agree before building modelling yourself. If no pipeline is needed, say so.
 
 ## 6. Credentials into `.bruin.yml`
 
-`bruin init` writes a `.bruin.yml` with placeholder connections. The template's README and that file say which connections it needs.
-
-**Never ask for a credential in chat or pass one as a command argument.** If the
-user pastes one, tell them not to send it and to rotate it, because it now sits
-in the transcript.
+The README and assets name the connections. A sample's inline key is a shape, not a value.
 
-For each connection:
+**Never ask for a credential in chat or pass one as a command argument.** If the user pastes one, tell them to rotate it.
 
-1. **Read what it needs.** `ingestion/<source>` for a source and
-   `platforms/<warehouse>` for a destination list the required fields and link
-   to the provider's own instructions.
-2. **Walk the user through getting it.** Where to click at the provider, and the
-   smallest scope that works: a read-only or restricted key, a service account
-   with read access, never an admin or live secret key when a narrower one
-   exists. A read-only credential is a control; a promise in a file is not.
-3. **Keep the value out of the file.** The user stores the secret in an
-   environment variable (a gitignored `.env` or `.envrc`, or their secret
-   manager) and you write `${VAR_NAME}` into `.bruin.yml` (`secrets/bruinyml`).
-   Or the user runs `bruin connections add` with no flags and answers its
-   prompts; its flag mode puts the secret on the command line.
-4. **Test it.** `bruin connections test --name <connection>`. Report the result,
-   never the value.
+1. Read `ingestion/<source>` or `platforms/<warehouse>` for the fields.
+2. Walk the user to the narrowest credential: read-only or restricted, never admin when narrower exists.
+3. The user sets an env var (gitignored `.env` or secret manager); you write `${VAR_NAME}` (`secrets/bruinyml`). Or the user runs `bruin connections add` with no flags.
+4. `bruin connections test --name <connection>`. Report the result, never the value.
 
-Then confirm `.bruin.yml` is ignored: `git check-ignore .bruin.yml`. If it is
-not, stop and fix that before anything else is committed.
-
-If the user runs Bruin Cloud, the same rule holds: `bruin cloud login`, or an
-exported `BRUIN_CLOUD_API_KEY`, never `--api-key` on the command line.
-`bruin auth status` shows which one is active without printing it.
+`git check-ignore .bruin.yml`; if not ignored, stop and fix first. Bruin Cloud: `bruin cloud login` or exported `BRUIN_CLOUD_API_KEY`, never `--api-key`.
 
 ## 7. Work out what to ask
 
@@ -164,69 +79,30 @@ exported `BRUIN_CLOUD_API_KEY`, never `--api-key` on the command line.
 > files. Read the template as it is today, list every choice it makes on the
 > user's behalf, and decide which ones this user needs to confirm.
 
-Where templates make choices:
-
-- **The README:** configuration sections, metric policy, first-run and
-  backfill steps, stated limitations.
-- **`pipeline.yml`:** variables and their defaults, schedule, start date.
-- **The assets:** descriptions, filters and `WHERE` clauses (statuses,
-  currencies, test accounts), materialisation, column checks.
-- **The report assets:** what each metric includes and excludes.
-
-Then filter. Use what you know about the business, and ask what you do not: a
-question about annual plans only matters if they sell annual plans. The domain's
-`SKILL.md` lists the areas that usually matter there. Treat it as a lens for
-spotting choices, not as the questions to ask.
-
-Group what is left by topic, lead with the ones that change the headline
-numbers, and ask. Add any business context the template needs but cannot infer,
-such as test or internal accounts to exclude, or how much history matters.
+- Read the README, `pipeline.yml` variables, asset filters, checks, and report metric definitions.
+- Drop choices that do not apply; `SKILL.md` is a lens, not a script.
+- Add what the template cannot infer (test accounts, history needed); lead with what moves headline numbers.
 
 ## 8. Customise
 
-Change the template to match the answers, one topic at a time.
-
-- **Prefer configuration to code.** A variable in `pipeline.yml` survives a
-  template update; an edited `WHERE` clause has to be carried forward by hand.
-- **When SQL has to change,** keep the edit small, and update the asset's
-  description to state the convention it now follows.
-- **After each change,** run `bruin validate <pipeline-folder>`, show the diff,
-  and record the decision in `decisions.md`.
+- Prefer a `pipeline.yml` variable to SQL edits; keep SQL edits small and update the asset description.
+- After each change: `bruin validate <pipeline-folder>`, show the diff, record it.
 
 ## 9. First run, bounded
 
-Before running, agree three things with the user and state them back:
-
-- **The environment.** `bruin environments list`. Most templates create only
-  `default`; creating or cloning another (`commands/environments`) is a change
-  that needs approval.
-- **The window.** `--start-date` and `--end-date`; a local run defaults to
-  yesterday only. Say the expected scan.
-- **The template's own first-load steps** from its README. If one is
-  `--full-refresh`, name what it replaces before asking.
+Agree and state back, then `bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>`:
 
-```bash
-bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>
-```
+- **Environment:** `bruin environments list`; creating one needs approval.
+- **Window:** a local run defaults to yesterday only. Say the expected scan.
+- **README first-load steps:** if one is `--full-refresh`, name what it replaces before asking.
 
-## 10. Check it against the source, together
+## 10. Reconcile with the user
 
-A pipeline that ran and a pipeline that loaded the right data are different
-claims. Pick one number the user can see in the source's own dashboard (last
-month's revenue, active subscriptions, sessions) and reconcile it with them.
+Compare one number from the source's own dashboard.
 
-- **The numbers match, or differ only because of a recorded decision:** say so,
-  and note the explanation in `decisions.md`.
-- **They differ and you cannot say why:** stop. Investigate before anyone uses
-  the reports.
+- **Differs only by a recorded decision:** note it in `decisions.md`.
+- **Differs unexplained:** stop; investigate before anyone uses the reports.
 
 ## 11. Hand off
 
-Tell the user, briefly:
-
-- the template, warehouse, environment and window that ran;
-- each decision, and which ones are still unconfirmed defaults;
-- what is scheduled (nothing, unless they asked for it);
-- what to connect next, if a question they care about needs a second domain.
-
-From here, questions about the data follow the domain's `analysis.md`.
+Report template, warehouse, environment, window, unconfirmed decisions, what is scheduled (nothing unless asked), and what to connect next. Then follow `analysis.md`.
diff --git a/resources/startup-data-kit/product-analytics/SKILL.md b/resources/startup-data-kit/product-analytics/SKILL.md
index 1011533..7d0bf0e 100644
--- a/resources/startup-data-kit/product-analytics/SKILL.md
+++ b/resources/startup-data-kit/product-analytics/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: product-analytics
-description: Use when a startup wants product analytics set up or answered. Walks the user through installing Bruin, choosing and customising a maintained product template (PostHog, Firebase) to their events, identity and accounts, then answers activation, feature adoption, engagement, retention and usage-based churn questions, including PostHog, Mixpanel or Amplitude usage joined to revenue.
+description: Use when a startup wants product analytics set up or answered. Sets up a PostHog or Firebase template customised to their events, identity and accounts and answers activation, adoption, retention and usage-based churn questions, including usage joined to revenue.
 ---
 
 # Product analytics
@@ -10,159 +10,55 @@ description: Use when a startup wants product analytics set up or answered. Walk
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
 > docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
 > PostHog, Mixpanel, Amplitude or Firebase documentation, those are right and
-> this file is stale. Written against Bruin CLI `v0.11.765`, checked 2026-10-01.
-> The product analytics tool's own UI is also the reference you reconcile
-> against, not this file.
-
-Two jobs. **Set up:** work with the user to install a maintained Bruin product
-analytics template and customise it to their events, users and accounts.
-**Answer:** questions from what it built, in [analysis.md](analysis.md).
-
-Event data is the one source that can explain *why* revenue moved. It is also
-the one where the data you need most often turns out never to have been
-captured. The failure mode is a confident adoption or retention number built on
-the wrong identity, the template's example events, or an activation nobody
-defined. Most of it is prevented during setup, by asking the user what the
-template would otherwise assume.
-
-## Look it up live
-
-This file says what to reach for and what to be careful about. For the facts
-themselves, ask the tool, and tell the user if it disagrees with this file:
-
-- **Flags:** `bruin <command> --help`. The docs lag the CLI.
-- **Docs:** the local Bruin MCP server, `bruin_get_doc_content('<path>')`, or
-  `https://getbruin.com/docs/bruin/<path>.html` without it. For this skill:
-  `getting-started/templates-docs/<name>-README` for what a template builds and
-  needs, `ingestion/<source>` (for example `ingestion/posthog` or
-  `ingestion/mixpanel`) for a source's tables and connection fields, and
-  `commands/init` for `--merge`.
-- **The user's environment:** Bruin Cloud MCP, or
-  `bruin cloud ... --output json`.
-
-## Setting it up
-
-Follow [workflow.md](workflow.md) from the top: install, MCP, repository,
-warehouse, template, credentials, then the questions. It is the same process
-for every skill in this kit. What is specific to product analytics is below.
+> this file is stale. Written against Bruin CLI `v0.11.766`, checked 2026-10-01.
+
+Sets up PostHog or Firebase product analytics and answers activation, adoption
+and retention questions, joined to revenue. It exists to prevent a confident
+adoption or retention number built on the wrong identity, the template's
+example events, or an activation nobody defined.
+
+## Set up
+
+Follow [workflow.md](workflow.md).
 
 > **Important: do not ask a fixed list of questions.** Read the template as it
 > is today and work out which of its choices this user needs to confirm.
-> Templates change, so the questions change with them. Workflow step 7 says how.
-
-### Templates to consider
-
-Ask which product analytics tool they use, and whether billing data already sits
-in the warehouse, because the join to revenue is where most of the value is.
-Then check `bruin init --help`; at the time of writing the candidates were
-`posthog-bigquery` and `firebase`, plus Mixpanel as an option inside
-`ecommerce`.
-
-Caveats that change what the user can report:
-
-- **`posthog-bigquery`: backfill `posthog_raw.events` one day per run.** A wider
-  window silently returns partial data. Plan the first-run window (workflow
-  step 9) around this. The README has the loop, and notes the end date is the
-  next day.
-- **`posthog-bigquery`: the account layer needs person properties** set by
-  `identify`. Without `company`, `accounts` and the account-grain reports are
-  empty; without `signup_date`, retention cohorts are empty; without `plan`,
-  every account reads `unknown`. `persons` is current state, so today's plan is
-  carried onto past months. Identity resolves through
-  `posthog_stage.person_distinct_ids`, accounts through `posthog_stage.accounts`.
-- **`posthog-bigquery`: the event lists are examples.** The `pipeline.yml`
-  variables ship the template author's own event names. None of them will match
-  this product until replaced.
-- **`posthog-bigquery`: `bruin validate` reports `in_string_list is not
-  callable`** on assets that call its macros. The README says this is harmless.
-  Do not "fix" it.
-- **`firebase`** models a Firebase Analytics export that is already in BigQuery.
-  There is no Firebase ingestion connector, so the export has to be switched on
-  first. Read the `README.md` it scaffolds as well as the docs page: the
-  scaffolded one has the setup steps (rename `analytics_123456789` to their
-  analytics ID, choose the intraday or daily export, work through the `TODO`
-  comments).
-- **`ecommerce`** offers Mixpanel as its web analytics option, but always
-  includes Shopify. It is not a product analytics template.
-- **Mixpanel, Amplitude, RevenueCat, Adapty** have connectors and no template.
-  Read `ingestion/<source>`. Ingesting is easy; modelling activation and
-  retention from it is the work. Agree that with the user before starting.
-
-**Adding PostHog to an existing billing pipeline** uses
-`bruin init posthog-bigquery <existing-pipeline-folder> --merge`. It copies
-assets and macros, never overwrites, and leaves `pipeline.yml` alone. The
-PostHog raw assets take their `source_connection` from the template's ingestr
-`default:` block, and its `variables` are missing too. Merged into a pipeline
-with its own `default:` block, such as `stripe-bigquery`, the PostHog raw assets
-inherit the wrong connection. Copy what they need across, set the connection on
-those assets, or keep PostHog as its own pipeline. Show the diff to
-`pipeline.yml` before applying it.
-
-### What usually matters here
-
-A lens for reading the template, not a script. For each, find what the template
-does, then ask only where this business makes it matter.
-[analysis.md](analysis.md) explains the identity and activation points in depth.
-
-- **Identity:** which ID ties a product user to a billing customer, and whether
-  it exists on both sides. Agree it before anything is built on it, then check
-  the match rate. `posthog-bigquery` exposes `company` and `email` on
-  `posthog_stage.persons`; the `firebase` template keys users on `user_id`, with
-  a `TODO` to switch to `user_pseudo_id`. If no stable key exists, the fix is in
-  the product, not the pipeline. Say so.
-- **Account or user grain:** B2B accounts with seats, or individual users. On
-  `posthog-bigquery`, ask whether seat activation should count against known
-  users or contracted seats (`seat_denominator`).
-- **Activation and "active user":** which event, in which window. Ask for the
-  definition; if there is none, propose one, label it provisional, and record it
-  in `decisions.md`. `posthog-bigquery` has no activation setting; the nearest
-  choices are its `product_action_events` and `conversion_events` lists.
-- **Which events matter:** the product's own event names, and when each was
-  instrumented or renamed. An instrumentation date reads as an adoption trend.
-- **Person and plan properties:** whether the product sends the ones the
-  template reads, under which names. If billing is already in the warehouse,
-  ask whether plan and MRR should come from there instead of person properties.
-- **Users to exclude:** employees, test accounts, staging projects, anonymous
-  visitors. Check whether the template filters any of them.
-- **History:** how far back it matters. The tool's own retention window bounds
-  what exists, and PostHog history loads one day per run.
-
-### Reconcile against
-
-The product analytics tool's own UI: one event's count for one fully loaded
-recent day, or weekly active users over a recent window if both define "active"
-the same way. Compare the raw table first, then the staged one. Expect
-deduplication, identity merges and excluded users to explain most gaps, and
-record each one.
-
-## Answering questions afterwards
-
-Read [analysis.md](analysis.md): what to check before answering, the identity
-join and instrumentation gaps, activation, retention curves, and why
-correlation is not cause. If the user is on a template, read its report assets
-before writing any SQL. Rebuilding that logic inline is how two answers to the
-same question start to differ.
+> Templates change, so the questions change with them.
+
+**Templates:** `posthog-bigquery`, `firebase`; confirm with `bruin init --help`.
+`ecommerce` offers Mixpanel but always includes Shopify. Mixpanel, Amplitude,
+RevenueCat and Adapty have connectors and no template: read
+`ingestion/<source>`; the modelling is theirs to build.
+
+**Watch for:**
+
+- `posthog-bigquery`'s event lists in `pipeline.yml` are the template author's examples; none match this product until replaced.
+- `posthog-bigquery` account reports and retention cohorts are empty unless the product sets person properties with `identify`; those are current state, so today's plan is carried onto past months.
+- `firebase` models a Firebase Analytics export already in BigQuery; there is no Firebase connector, so the export must be switched on first.
+
+> **Note:** backfill `posthog-bigquery` events one day per run. A wider window
+> silently returns partial data. The README has the loop.
+
+**Usually needs the user's input:**
+
+- Identity: which ID ties a product user to a billing customer, and whether it exists on both sides; if none, the fix is in the product.
+- Grain: B2B accounts with seats or individual users; seat activation against known users or contracted seats.
+- Activation and "active user": which event in which window; if none, propose one labelled provisional.
+- Which events matter, and when each was instrumented or renamed.
+- Person and plan properties: whether the product sends them, under which names, or whether plan comes from billing.
+- Users to exclude: employees, test accounts, staging projects, anonymous visitors.
+- History: how far back matters; the tool's own retention bounds what exists.
+
+**Reconcile against:** one event's count for one fully loaded recent day in the
+product analytics tool's own UI, raw table first, then staged.
+
+## Answer questions
+
+Read [analysis.md](analysis.md).
 
 ## Never
 
-- **Ask for a credential** in chat or as a command argument. If offered one, say
-  not to send it and to rotate it if already sent. Workflow step 6 has the
-  safe path.
-- **Print a credential**, including in errors, summaries and generated files.
-- **Run against production** unless asked by name. Say which environment you used.
-- **Send an event or write to the product analytics tool.** Read only.
-- **Pull raw user-level event streams into context.** They are enormous and
-  usually contain personal data. Aggregate first, in SQL, then look.
-- **Include personal data in output.** Event payloads carry emails, names, IPs,
-  URLs with tokens, and sometimes more. Mask or aggregate before it reaches a
-  summary. Use identifiers over names and contact details.
-- **Treat an event property as trustworthy** because it exists. Check the fill
-  rate before segmenting on it.
-- **Write without asking.** Installing, initialising, editing configuration or
-  models, and running a pipeline all wait for the user's yes.
-
-Stop and ask before any write to a source system, outbound message,
-publication, credential change, production access, `--full-refresh` or backfill.
-On `posthog-bigquery`, `--full-refresh` truncates `posthog_raw.events` and
-reloads only the run's window, so every earlier day has to be backfilled again,
-one day per run. Name that consequence.
+- Ask for or print a credential; write, run, backfill, `--full-refresh` or
+  touch production without a yes; put personal data in output.
+- Send an event or write to the product analytics tool.
+- Pull raw user-level event streams into context; aggregate in SQL first.
diff --git a/resources/startup-data-kit/product-analytics/analysis.md b/resources/startup-data-kit/product-analytics/analysis.md
index 8364e11..d6e90b3 100644
--- a/resources/startup-data-kit/product-analytics/analysis.md
+++ b/resources/startup-data-kit/product-analytics/analysis.md
@@ -3,132 +3,29 @@
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
 > docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
 > PostHog, Mixpanel, Amplitude or Firebase documentation, those are right and
-> this file is stale. Written against Bruin CLI `v0.11.765`, checked 2026-10-01.
-> The product analytics tool's own UI is the reference you reconcile against,
-> not this file.
+> this file is stale. Written against Bruin CLI `v0.11.766`, checked 2026-10-01.
 
-Read this once a product analytics pipeline exists and the user is asking
-questions of it. If `decisions.md` sits beside the pipeline's `pipeline.yml`,
-read it first: it records the identity key, the activation definition and the
-events this model counts. The `Never` rules in `SKILL.md` apply here too.
+Read `decisions.md` beside the pipeline's `pipeline.yml` first. The Never rules
+in [SKILL.md](SKILL.md) apply.
 
-Event data is the one source that can explain *why* revenue moved. It is also
-the one where the data you need most often turns out never to have been
-captured.
+## Before answering
 
-## Before answering any product question
+- Read the report assets before writing SQL, and respect their completeness and reportability guard columns.
+- Check freshness: the last runs (Bruin Cloud MCP or `bruin cloud runs list`), then the maximum event date in raw; a missing load reads as a usage drop.
+- State source, window, the activation or "active" definition and the cohort basis with every number.
+- Before joining usage to revenue, confirm the identity key exists and report the match rate; do not call the matched share the customer base.
 
-1. **Read the model before querying it.** Asset descriptions state the grain
-   and what is excluded. Do not infer meaning from column names.
-2. **Prefer report tables over raw tables.** On `posthog-bigquery`, read the
-   `posthog_reports` assets first, and respect their guard columns:
-   `is_complete_week` on retention, `is_reportable` and `was_enabled` on feature
-   adoption.
-3. **Check freshness first.** Read the last runs from Bruin Cloud MCP or
-   `bruin cloud runs list --output json`, then the maximum event date in the
-   raw table. A missing recent load reads as a usage drop.
+## Traps
 
-## Establish the identity join first
+- An event never instrumented looks identical to one never done; adoption starting at zero often marks the day the event shipped.
+- A renamed event looks like one feature dying and another being born.
+- A property is not trustworthy because it exists; check its fill rate before segmenting.
+- One account has many users, and anonymous, multi-device and sales-led identities may not be stitched.
+- Cohort by signup or first activation and say which; mark incomplete recent cohorts; do not extrapolate an unflattened curve into LTV.
+- Client-side events are lost to ad blockers, offline use and crashes; server-side counts are more complete.
 
-This is the whole job, and doing it second means redoing everything built on top.
+## What this data cannot tell you
 
-Product events identify a **user**. Billing identifies an **account**. They are
-different grains, and the mapping between them is your problem:
-
-- One account has many users. Usage is per account, seats are per user, and the
-  two questions have different answers.
-- Anonymous events before signup may or may not be stitched to the person after.
-- A person may appear under several identifiers across devices.
-- Self-serve and sales-led signups often carry different identifiers entirely.
-
-**Before joining usage to revenue, verify the key exists and check the match
-rate.** Report it: "82% of paying accounts matched to product usage" is a useful
-caveat. Silently analysing the 82% and calling it the customer base is not.
-
-If no stable key exists, say that the join is the work. It usually means a
-change in the product, not in the pipeline.
-
-## Event data does not tell you what was never instrumented
-
-The most important sentence in this skill.
-
-An event that was never captured and an event that never happened look
-identical downstream. Before concluding a feature is unused, check whether it
-was ever instrumented, and when instrumentation was added.
-
-- **Instrumentation dates create fake trends.** Adoption that starts at zero in
-  March often means the event shipped in March.
-- **Renamed events break history.** A rename looks like one feature dying and
-  another being born.
-- **Missing properties cannot be recovered retroactively.** If plan tier was
-  never on the event, you cannot segment history by it.
-- **Client-side events are lost** to ad blockers, offline use and crashes.
-  Server-side events are more complete and usually fewer.
-
-Always say which of these you could not rule out.
-
-**Check a property's fill rate before segmenting on it.** A property is not
-trustworthy because it exists.
-
-## Define activation before measuring it
-
-"Activation" is meaningless until someone writes down the event and the window.
-It should be the action that best predicts a customer still being there in
-ninety days, not the first thing they do.
-
-Ask for the definition. If nobody has one, propose a candidate, say why, and
-label it as provisional. Do not silently pick one. Record it in `decisions.md`.
-
-The same applies to "active user". Daily, weekly and monthly actives depend
-entirely on what counts as an action. A login is usually a bad choice; a session
-that includes the core action is usually better.
-
-## The questions worth asking of the join
-
-| Question | Signal |
-|---|---|
-| Paying accounts with declining usage | The strongest churn predictor billing data cannot see |
-| New accounts that never reach activation | Onboarding failure, visible weeks before it becomes churn |
-| Accounts at seat limits with rising usage | Expansion opportunity |
-| Revenue growing while adoption flattens | Monetising existing customers harder rather than growing |
-| Adoption growing while revenue flattens | Value delivered and not captured |
-| Feature adoption by plan tier | Whether packaging matches behaviour |
-
-The first is where most of the value is. A paying account whose weekly usage
-halved over six weeks is the call to make this week.
-
-## Retention curves, carefully
-
-- **Cohort by signup or by first activation**, and say which. They give very
-  different curves.
-- **A retention curve that has not flattened is not yet a retention curve.**
-  Do not extrapolate it into LTV.
-- **Incomplete cohorts.** The most recent cohort has not had time to churn.
-  Never put it on the same chart as complete ones without marking it.
-- **Survivorship.** Retention among accounts that survived to month six is not
-  retention.
-
-## When an event count looks wrong
-
-1. **Check the run and freshness**, as above.
-2. **Check how the history was loaded.** On `posthog-bigquery`, a backfill of
-   `posthog_raw.events` covering more than one day per run silently returns
-   partial data. Compare daily counts in the raw table against the PostHog UI
-   before blaming the model.
-3. **Check instrumentation**, as above: when the event shipped, and whether it
-   was renamed.
-
-If the model and the source genuinely disagree, show the gap. Do not adjust a
-model to match a number someone expected.
-
-## Correlation is not cause
-
-Usage falling before churn is a hypothesis with a date on it, and it is a good
-one. It is still not a cause. Say what evidence would settle it: an experiment,
-a holdout, or asking the customers.
-
-Report the relationship, the strength, the sample size, and what you cannot rule
-out. A small sample deserves both readings: "three of eleven at-risk accounts
-churned" is 27% and is also three accounts.
-
-For the revenue side of the join, see the `revenue-analytics` skill.
+- Cause: usage falling before churn is a hypothesis; an experiment, a holdout or asking customers settles it. Give the sample size.
+- Whether a feature that was never instrumented is used.
+- History segmented by a property that was never captured.
diff --git a/resources/startup-data-kit/product-analytics/workflow.md b/resources/startup-data-kit/product-analytics/workflow.md
index 591061d..a3300e7 100644
--- a/resources/startup-data-kit/product-analytics/workflow.md
+++ b/resources/startup-data-kit/product-analytics/workflow.md
@@ -3,158 +3,73 @@
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
 > docs](https://getbruin.com/docs/bruin/overview.html) or `bruin <command>
 > --help`, upstream is right and this file is stale. Written against Bruin CLI
-> `v0.11.765`, checked 2026-10-01.
+> `v0.11.766`, checked 2026-10-01.
 
-Every skill in the startup data kit carries an identical copy of this file.
-The skill's own `SKILL.md` says which templates fit its domain and what tends to
-matter there; this file is the process. Work through it in order.
+Identical in every startup-data-kit skill. Work in order.
 
 ## Working with the user
 
-This is a conversation, not a script. The point of a maintained template is
-that the modelling is done; the point of this process is that it ends up
-modelling *this* startup, not a generic one.
-
-- **Check before acting.** Most users have done some of this already, and
-  redoing a step is how a working setup gets broken. Say what you checked and
-  what you found.
-- **Ask before every write.** Installing, initialising, editing configuration,
-  changing a model, running a pipeline: say exactly what will change and wait
-  for a yes. Show diffs.
-- **Ask a few questions at a time, each with the default.** For every choice,
-  say what the template does today, what the alternative would change, and why
-  it matters. "Keep the default" should be an easy answer.
-- **Explain the term, not just the question.** Many founders are not data
-  people. "MRR counted at month end" means nothing until you say what it does
-  to a mid-month signup.
-- **Do not guess an answer.** If the user does not know, propose the default
-  and record it as unconfirmed. A choice the user did not make should not read
-  as though they did.
-- **When only the user can do a step**, give them the exact steps and wait
-  until they say it is done.
-- **Write the answers down** as you go, in a `decisions.md` beside the
-  pipeline's `pipeline.yml`: each choice, what was picked, whether the user
-  confirmed it or it is still the template's default, and the date. The next
-  agent, and the user in six months, will need it.
+- **Check before acting;** say what you found. Never redo working steps.
+- **Ask before every write** (install, init, config, model, run); show the diff, wait for a yes.
+- **Ask a few questions at a time,** each with its default and the term in plain words.
+- **Do not guess.** If the user does not know, record the default as unconfirmed.
+- **When only the user can do a step,** give exact steps and wait.
+- **Record answers in `decisions.md` beside `pipeline.yml`:** choice, pick, confirmed or default, date.
 
-## 1. Bruin is installed
-
-```bash
-bruin version
-```
+## Look it up live
 
-- **Installed and current:** move on.
-- **Installed, but `Latest` is newer than `Current`:** offer `bruin upgrade`.
-  Do not run it unasked.
-- **Not installed:** ask, then run
-  `curl -LsSf https://getbruin.com/install/cli | sh` and check `bruin version`
-  again. On Windows, or if the install fails, read
-  `getting-started/introduction/installation` rather than guessing.
+- Commands and flags: `bruin <command> --help`.
+- Docs: Bruin MCP `bruin_get_doc_content` for `getting-started/templates-docs/<name>-README`, `ingestion/<source>`, `platforms/<warehouse>`; or `https://getbruin.com/docs/bruin/<path>.html`.
+- The user's pipelines, runs and connections: Bruin Cloud MCP (`cloud/mcp-setup`), if they run Bruin Cloud.
 
-## 2. The Bruin MCP server is connected
+## 1. Bruin is installed
 
-Check whether you already have the `bruin_get_docs_tree` and
-`bruin_get_doc_content` tools. If you do, move on.
+`bruin version`. If `Latest` is newer than `Current`, offer `bruin upgrade`. If missing, ask, then `curl -LsSf https://getbruin.com/install/cli | sh`; on Windows or failure, read `getting-started/introduction/installation`.
 
-If not, register it, because the rest of this skill reads Bruin's docs through
-it. Until then, read the same pages at
-`https://getbruin.com/docs/bruin/<path>.html`; the setup page is
-`getting-started/bruin-mcp`.
+## 2. The Bruin MCP server is connected
 
-- **If your host lets you change its MCP configuration**, show the exact
-  command or snippet from that page, say which file it changes and whether that
-  affects only this project or every project, and run it only after the user
-  approves. For Claude Code the page gives `claude mcp add bruin -- bruin mcp`.
-- **If you cannot**, walk the user through it: the snippet for their host, where
-  it goes, and that the host usually needs a restart or reload before the tools
-  appear.
+If you lack the `bruin_get_doc_content` tool, read `getting-started/bruin-mcp`.
 
-The local server serves Bruin's documentation only. Bruin Cloud MCP is separate
-(`cloud/mcp-setup`) and only worth setting up if the user runs Bruin Cloud.
+- If you can edit the host's MCP config, show the exact command (Claude Code: `claude mcp add bruin -- bruin mcp`) and its project or global scope; run it only after approval.
+- Otherwise give the user the snippet; the host usually needs a restart.
 
 ## 3. You are inside the user's own git repository
 
-```bash
-git rev-parse --show-toplevel
-```
-
-- **Not a repository:** ask which folder the project should live in, then
-  `git init` there. Without a repository, `bruin init` creates a `bruin/`
-  wrapper folder and initialises git inside that instead.
-- **A repository:** confirm it is the user's project. Never scaffold inside a
-  clone of a public catalogue such as this one, or inside another Bruin
-  project. A `.bruin.yml` higher up the tree gets picked up by mistake.
-- **A Bruin project already exists here** (a `.bruin.yml`, a `pipeline.yml`):
-  ask whether to add to it or start fresh. Adding a template to an existing
-  pipeline uses `bruin init <template> <pipeline-folder> --merge`; read
-  `commands/init` first, because it leaves `pipeline.yml` alone.
+`git rev-parse --show-toplevel`.
+
+- **Not a repository:** ask which folder, then `git init`; otherwise `bruin init` creates a `bruin/` wrapper with its own git.
+- **A repository:** confirm it is the user's, not a public catalogue or another Bruin project (a parent `.bruin.yml` gets picked up).
+- **Bruin project exists:** ask whether to add (`--merge`; read `commands/init`) or start fresh.
 
 ## 4. Confirm the warehouse
 
-Ask which database or warehouse the data should land in. Do not pick for them.
-The destination decides which templates exist at all, so ask before choosing a
-template.
+Ask where the data lands; do not pick. It decides which templates exist.
 
-- **They already have one:** use it. Keep the boundary they already run.
-- **They have none:** say which destinations the templates for this domain
-  support (`bruin init --help` lists every template; the destination is usually
-  in the name), and what each costs them in setup. Some templates run on local
-  DuckDB with nothing to provision.
-- **No template supports their warehouse:** say so plainly. Offer the closest
-  template on another destination, or ingestion alone with the modelling left to
-  build. Do not improvise a template.
+- **None yet:** list destinations this domain's templates support (`bruin init --help`) and their setup cost; some run on local DuckDB.
+- **No template supports it:** say so; offer the closest template elsewhere, or ingestion alone. Never improvise one.
 
 ## 5. Choose the template
 
-Use the domain's `SKILL.md` for which templates to consider and their caveats.
-Then confirm against the live list, because templates are added and renamed:
+1. `bruin init --help` for current names; keep those matching source and warehouse.
+2. Read each candidate's README; if none, say so and read the scaffolded `README.md`.
+3. Tell the user what each builds, needs and omits. Let them choose.
+4. After a yes, `bruin init <template>`. If it opens an interactive wizard, give the user the command.
+5. Read the scaffolded files, run `bruin validate <pipeline-folder>`, and tell the user anywhere they disagree with the README or fail.
 
-1. `bruin init --help` for the current names. Keep the ones that match the
-   user's source and the warehouse confirmed in step 4.
-2. Read each candidate's README before recommending it:
-   `getting-started/templates-docs/<name>-README`. Some templates have none; say
-   so and read the `README.md` it scaffolds instead.
-3. Tell the user what each candidate builds, what it needs, and what it does
-   not cover. Let them choose.
-
-Then `bruin init <template>`, after they agree. Some templates, such as
-`ecommerce`, open an interactive wizard and fail without a terminal; give the
-user the command to run themselves, and read what it wrote afterwards. If nothing fits, say so. Ingesting a source with no template means
-building the modelling yourself, which is a project; agree that with the user
-before starting it. Some questions need no pipeline at all; if so, say that
-too, rather than building one.
+If nothing fits, say so; agree before building modelling yourself. If no pipeline is needed, say so.
 
 ## 6. Credentials into `.bruin.yml`
 
-`bruin init` writes a `.bruin.yml` with placeholder connections. The template's README and that file say which connections it needs.
-
-**Never ask for a credential in chat or pass one as a command argument.** If the
-user pastes one, tell them not to send it and to rotate it, because it now sits
-in the transcript.
+The README and assets name the connections. A sample's inline key is a shape, not a value.
 
-For each connection:
+**Never ask for a credential in chat or pass one as a command argument.** If the user pastes one, tell them to rotate it.
 
-1. **Read what it needs.** `ingestion/<source>` for a source and
-   `platforms/<warehouse>` for a destination list the required fields and link
-   to the provider's own instructions.
-2. **Walk the user through getting it.** Where to click at the provider, and the
-   smallest scope that works: a read-only or restricted key, a service account
-   with read access, never an admin or live secret key when a narrower one
-   exists. A read-only credential is a control; a promise in a file is not.
-3. **Keep the value out of the file.** The user stores the secret in an
-   environment variable (a gitignored `.env` or `.envrc`, or their secret
-   manager) and you write `${VAR_NAME}` into `.bruin.yml` (`secrets/bruinyml`).
-   Or the user runs `bruin connections add` with no flags and answers its
-   prompts; its flag mode puts the secret on the command line.
-4. **Test it.** `bruin connections test --name <connection>`. Report the result,
-   never the value.
+1. Read `ingestion/<source>` or `platforms/<warehouse>` for the fields.
+2. Walk the user to the narrowest credential: read-only or restricted, never admin when narrower exists.
+3. The user sets an env var (gitignored `.env` or secret manager); you write `${VAR_NAME}` (`secrets/bruinyml`). Or the user runs `bruin connections add` with no flags.
+4. `bruin connections test --name <connection>`. Report the result, never the value.
 
-Then confirm `.bruin.yml` is ignored: `git check-ignore .bruin.yml`. If it is
-not, stop and fix that before anything else is committed.
-
-If the user runs Bruin Cloud, the same rule holds: `bruin cloud login`, or an
-exported `BRUIN_CLOUD_API_KEY`, never `--api-key` on the command line.
-`bruin auth status` shows which one is active without printing it.
+`git check-ignore .bruin.yml`; if not ignored, stop and fix first. Bruin Cloud: `bruin cloud login` or exported `BRUIN_CLOUD_API_KEY`, never `--api-key`.
 
 ## 7. Work out what to ask
 
@@ -164,69 +79,30 @@ exported `BRUIN_CLOUD_API_KEY`, never `--api-key` on the command line.
 > files. Read the template as it is today, list every choice it makes on the
 > user's behalf, and decide which ones this user needs to confirm.
 
-Where templates make choices:
-
-- **The README:** configuration sections, metric policy, first-run and
-  backfill steps, stated limitations.
-- **`pipeline.yml`:** variables and their defaults, schedule, start date.
-- **The assets:** descriptions, filters and `WHERE` clauses (statuses,
-  currencies, test accounts), materialisation, column checks.
-- **The report assets:** what each metric includes and excludes.
-
-Then filter. Use what you know about the business, and ask what you do not: a
-question about annual plans only matters if they sell annual plans. The domain's
-`SKILL.md` lists the areas that usually matter there. Treat it as a lens for
-spotting choices, not as the questions to ask.
-
-Group what is left by topic, lead with the ones that change the headline
-numbers, and ask. Add any business context the template needs but cannot infer,
-such as test or internal accounts to exclude, or how much history matters.
+- Read the README, `pipeline.yml` variables, asset filters, checks, and report metric definitions.
+- Drop choices that do not apply; `SKILL.md` is a lens, not a script.
+- Add what the template cannot infer (test accounts, history needed); lead with what moves headline numbers.
 
 ## 8. Customise
 
-Change the template to match the answers, one topic at a time.
-
-- **Prefer configuration to code.** A variable in `pipeline.yml` survives a
-  template update; an edited `WHERE` clause has to be carried forward by hand.
-- **When SQL has to change,** keep the edit small, and update the asset's
-  description to state the convention it now follows.
-- **After each change,** run `bruin validate <pipeline-folder>`, show the diff,
-  and record the decision in `decisions.md`.
+- Prefer a `pipeline.yml` variable to SQL edits; keep SQL edits small and update the asset description.
+- After each change: `bruin validate <pipeline-folder>`, show the diff, record it.
 
 ## 9. First run, bounded
 
-Before running, agree three things with the user and state them back:
-
-- **The environment.** `bruin environments list`. Most templates create only
-  `default`; creating or cloning another (`commands/environments`) is a change
-  that needs approval.
-- **The window.** `--start-date` and `--end-date`; a local run defaults to
-  yesterday only. Say the expected scan.
-- **The template's own first-load steps** from its README. If one is
-  `--full-refresh`, name what it replaces before asking.
+Agree and state back, then `bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>`:
 
-```bash
-bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>
-```
+- **Environment:** `bruin environments list`; creating one needs approval.
+- **Window:** a local run defaults to yesterday only. Say the expected scan.
+- **README first-load steps:** if one is `--full-refresh`, name what it replaces before asking.
 
-## 10. Check it against the source, together
+## 10. Reconcile with the user
 
-A pipeline that ran and a pipeline that loaded the right data are different
-claims. Pick one number the user can see in the source's own dashboard (last
-month's revenue, active subscriptions, sessions) and reconcile it with them.
+Compare one number from the source's own dashboard.
 
-- **The numbers match, or differ only because of a recorded decision:** say so,
-  and note the explanation in `decisions.md`.
-- **They differ and you cannot say why:** stop. Investigate before anyone uses
-  the reports.
+- **Differs only by a recorded decision:** note it in `decisions.md`.
+- **Differs unexplained:** stop; investigate before anyone uses the reports.
 
 ## 11. Hand off
 
-Tell the user, briefly:
-
-- the template, warehouse, environment and window that ran;
-- each decision, and which ones are still unconfirmed defaults;
-- what is scheduled (nothing, unless they asked for it);
-- what to connect next, if a question they care about needs a second domain.
-
-From here, questions about the data follow the domain's `analysis.md`.
+Report template, warehouse, environment, window, unconfirmed decisions, what is scheduled (nothing unless asked), and what to connect next. Then follow `analysis.md`.
diff --git a/resources/startup-data-kit/revenue-analytics/SKILL.md b/resources/startup-data-kit/revenue-analytics/SKILL.md
index a084e2b..f880342 100644
--- a/resources/startup-data-kit/revenue-analytics/SKILL.md
+++ b/resources/startup-data-kit/revenue-analytics/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: revenue-analytics
-description: Use when a startup wants revenue analytics set up or answered. Walks the user through installing Bruin, choosing and customising a maintained billing template (Stripe, Chargebee, Shopify) to how they actually bill, then answers MRR, ARR, churn, expansion, failed payment and cash collection questions from it.
+description: Use when a startup wants revenue analytics set up or answered. Sets up a Stripe, Chargebee or Shopify billing template customised to how they bill and answers MRR, ARR, churn, expansion, failed payment and cash collection questions.
 ---
 
 # Revenue analytics
@@ -8,111 +8,57 @@ description: Use when a startup wants revenue analytics set up or answered. Walk
 **Status:** experimental · **Risk:** approval-required
 
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
-> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or your
-> billing provider's own documentation, those are right and this file is stale.
-> Written against Bruin CLI `v0.11.765`, checked 2026-10-01. The provider's own
-> reporting is also the reference you reconcile against, not this file.
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or the
+> billing provider's documentation, those are right and this file is stale.
+> Written against Bruin CLI `v0.11.766`, checked 2026-10-01.
 
-Two jobs. **Set up:** work with the user to install a maintained Bruin billing
-template and customise it to how this business actually bills. **Answer:**
-questions from what it built, in [analysis.md](analysis.md).
+Sets up a billing template customised to how this business bills and answers
+MRR, churn and cash questions. It exists to prevent a confident, well
+formatted, wrong MRR that someone forwards to an investor.
 
-The failure mode is not an error message. It is a confident, well formatted,
-wrong number that someone forwards to an investor. Most of it is prevented
-during setup, by asking the user what the template would otherwise assume.
+## Set up
 
-## Look it up live
-
-This file says what to reach for and what to be careful about. For the facts
-themselves, ask the tool, and tell the user if it disagrees with this file:
-
-- **Flags:** `bruin <command> --help`. The docs lag the CLI.
-- **Docs:** the local Bruin MCP server, `bruin_get_doc_content('<path>')`, or
-  `https://getbruin.com/docs/bruin/<path>.html` without it. For this skill:
-  `getting-started/templates-docs/<name>-README` for what a template builds and
-  the metric policy it ships, `ingestion/<source>` (for example
-  `ingestion/stripe`) for a source's tables and loading modes,
-  `ingestion/frankfurter` and `ingestion/exchangeratesapi` for FX rates,
-  `core-concepts/semantic-layer` and `quality/overview`.
-- **The user's environment:** Bruin Cloud MCP, or
-  `bruin cloud ... --output json`.
-
-## Setting it up
-
-Follow [workflow.md](workflow.md) from the top: install, MCP, repository,
-warehouse, template, credentials, then the questions. It is the same process
-for every skill in this kit. What is specific to revenue is below.
+Follow [workflow.md](workflow.md).
 
 > **Important: do not ask a fixed list of questions.** Read the template as it
 > is today and work out which of its choices this user needs to confirm.
-> Templates change, so the questions change with them. Workflow step 7 says how.
-
-### Templates to consider
-
-Ask which billing system they use, and whether revenue also arrives elsewhere
-(an app store, a second processor, invoices outside the billing system). Then
-check `bruin init --help`; at the time of writing the candidates were the
-`stripe-*`, `chargebee-*` and `shopify-*` templates, plus `ecommerce`.
-
-Caveats the READMEs will not flag:
-
-- **`stripe-databricks`** is bronze ingestion plus one silver table, with no MRR
-  reports, and has no README in the docs. Read the `README.md` it scaffolds.
-- **`shopify-bigquery`** only copies raw Shopify tables. The modelling is yours.
-- **`ecommerce`** always includes Shopify. It is not a general way to combine
-  several billing systems.
-- **There is no DuckDB template for Stripe.** If the user wants Stripe without a
-  warehouse, that is a project, not a flag. Say so.
+> Templates change, so the questions change with them.
 
-For a billing source with no template, read `ingestion/<source>`. Ingesting it
-is easy; modelling MRR from it is the work. Agree that with the user before
-starting.
+**Templates:** `stripe-*`, `chargebee-*`, `shopify-*`, `ecommerce`; confirm
+with `bruin init --help`. Ask whether revenue also arrives elsewhere (an app
+store, a second processor, invoices outside billing). For a billing source with
+no template, read `ingestion/<source>`; the modelling is theirs to build.
 
-### What usually matters here
+**Watch for:**
 
-A lens for reading the template, not a script. For each, find what the template
-does, then ask only where this business makes it matter.
-[metric-decisions.md](metric-decisions.md) explains each one and what to ask.
+- `stripe-databricks` is ingestion plus one silver table, and `shopify-bigquery` copies raw tables only: no MRR reports.
+- There is no DuckDB template for Stripe; Stripe without a warehouse is a project, not a flag.
+- `ecommerce` always includes Shopify; it is not a way to combine billing systems.
+- Stripe and Chargebee MRR comes from daily snapshots: Stripe history starts at the first run and cannot be backfilled; Chargebee backfills subscription episodes but not repricing.
 
-- **Billing intervals:** annual or multi-year plans, and how they spread to MRR.
-- **Currencies:** more than one, and whether to convert or report per currency.
-- **Trials, paused and past-due subscriptions:** which count as MRR.
-- **Discounts, taxes, usage billing and one-off charges:** in or out.
-- **Timing:** MRR observed at month start, month end, or averaged.
-- **Accounts to exclude:** internal, test and free accounts.
-- **History:** how far back it matters, and whether the template can backfill
-  it. Snapshot-based templates often cannot; the README says.
+> **Note:** `stripe-bigquery` loads incrementally on Stripe's `created`
+> timestamp. A cancellation, upgrade, payment or void after the creation window
+> is missed until a wider re-run. Check the README's incremental-loading section.
 
-The Stripe and Chargebee templates already pick defaults for several of these.
-Read the metric policy in the README, say what it picked, and confirm each with
-the user rather than inheriting it.
+**Usually needs the user's input:**
 
-### Reconcile against
+- Annual and multi-year plans: spread across the term, not booked in the month billed.
+- Currencies: fixed rate, rate on the day, or per currency never summed; record the rate and its date.
+- Trials, paused and past-due: which count as MRR and customers, after how many days unpaid one stops counting, and whether a lapsed trial is churn.
+- Discounts, taxes, proration, refunds: MRR net of discount and pre-tax; proration in cash only or MRR; refunds and disputes in the issue or original month.
+- Usage and one-off charges: a separate line, or a labelled smoothing window.
+- Timing: MRR observed at month start, month end or daily average; only one in the reports.
+- Internal, test and free accounts to exclude.
 
-The billing provider's own dashboard: last month's MRR or active subscription
-count is usually the easiest number for the user to check. Expect the
-definitions above to explain most gaps, and record each one.
+**Reconcile against:** last month's MRR or active subscription count in the
+billing provider's own dashboard.
 
-## Answering questions afterwards
+## Answer questions
 
-Read [analysis.md](analysis.md): what to check before answering, what to state
-with every number, and what billing data cannot tell you. If the user is on a
-template, read its report assets before writing any SQL. Rebuilding that logic
-inline is how two answers to the same question start to differ.
+Read [analysis.md](analysis.md).
 
 ## Never
 
-- **Ask for a credential** in chat or as a command argument. If offered one, say
-  not to send it and to rotate it if already sent. Workflow step 6 has the
-  safe path.
-- **Print a credential**, including in errors, summaries and generated files.
-- **Run against production** unless asked by name. Say which environment you used.
-- **Pull raw customer records into context** when an aggregate answers the
-  question. Use identifiers over names and contact details.
-- **Write without asking.** Installing, initialising, editing configuration or
-  models, and running a pipeline all wait for the user's yes.
-
-Stop and ask before any write to a source system, outbound message,
-publication, credential change, production access, `--full-refresh` or backfill.
-On a snapshot-based template, `--full-refresh` after the first load discards MRR
-history that cannot be rebuilt from the source. Name that consequence.
+- Ask for or print a credential; write, run, backfill, `--full-refresh` or
+  touch production without a yes; put personal data in output.
+- `--full-refresh` a snapshot-based template after its first load without naming that it discards MRR history the source cannot rebuild.
diff --git a/resources/startup-data-kit/revenue-analytics/analysis.md b/resources/startup-data-kit/revenue-analytics/analysis.md
index b6d0669..3d4a593 100644
--- a/resources/startup-data-kit/revenue-analytics/analysis.md
+++ b/resources/startup-data-kit/revenue-analytics/analysis.md
@@ -1,123 +1,32 @@
 # Answering revenue questions
 
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
-> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or your
-> billing provider's own documentation, those are right and this file is stale.
-> Written against Bruin CLI `v0.11.765`, checked 2026-10-01. The provider's own
-> reporting is the reference you reconcile against, not this file.
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or the
+> billing provider's documentation, those are right and this file is stale.
+> Written against Bruin CLI `v0.11.766`, checked 2026-10-01.
 
-Read this once a revenue pipeline exists and the user is asking questions of
-it. If `decisions.md` sits beside the pipeline's `pipeline.yml`, read it first:
-it records which conventions this model follows. The `Never` rules in
-`SKILL.md` apply here too.
+Read `decisions.md` beside the pipeline's `pipeline.yml` first. The Never rules
+in [SKILL.md](SKILL.md) apply.
 
-## Before answering any revenue question
+## Before answering
 
-1. **Read the model before querying it.** Asset descriptions state the grain,
-   the MRR convention and what is excluded. Do not infer meaning from column
-   names.
-2. **Prefer named metrics over your own SQL.** If a semantic model exists, use
-   it. A metric asked for by name returns the same definition every time.
-3. **Prefer report tables over raw tables.**
-4. **Check freshness first.** A correct number from a stale pipeline is still
-   the wrong answer. Read the last runs from Bruin Cloud MCP
-   (`pipeline-run-list`, `asset-runs`, or `asset-health` on OXR-orchestrated
-   pipelines) or `bruin cloud runs list --output json`, then the maximum date in
-   the raw table.
+- Read the report assets, and the semantic model if one exists, before writing SQL; ask for metrics by name.
+- Check freshness: the last runs (Bruin Cloud MCP or `bruin cloud runs list`), then the maximum date in the raw table.
+- State the definition, MRR timing convention, window, source asset and any unhandled exclusion with every number.
+- Break a change into new, reactivation, expansion, contraction and churn, check they sum, and say so if they do not.
 
-## Always state these alongside a number
+## Traps
 
-- **The definition.** Which metric, which grain, which convention.
-- **The window.** The exact months.
-- **The source.** Which asset it came from.
-- **What is excluded.** Whichever decisions below apply and are unhandled.
+- Invoices and cash are not MRR: a customer with a failing card still carries MRR; report collection rate beside it.
+- An annual plan booked in the month it was billed is the largest source of overstated MRR.
+- Customers acquired before the window are not new business in month one.
+- Flat net MRR can hide a new customer offsetting a churn; show the components.
+- On snapshot-based templates, movement and retention need two contiguous months of snapshots; empty is not zero.
+- A failed or written-off invoice is a question, not churn; it is as often an expired card.
 
-Never report MRR without saying how it is observed. Never report a change
-without saying what drove it. "MRR fell 3%" is not an answer. "MRR fell 3%
-because one Growth account churned and nothing replaced it" is.
+## What this data cannot tell you
 
-## The definitions that change the number
-
-Not edge cases. Each produces a different, defensible MRR, and a model that
-picks silently teaches the user that a hard question is settled. The Stripe and
-Chargebee templates ship defaults for several of them; read the README's metric
-policy and confirm each default with the user rather than inheriting it.
-
-Full detail in [metric-decisions.md](metric-decisions.md). Read it when building
-or reviewing a model, not for every question.
-
-The short list: annual and multi-year plans, multiple currencies, usage billing,
-trials, paused and past-due subscriptions, discounts, taxes, proration, refunds
-and disputes, and whether MRR is observed at month start, month end or averaged.
-
-## Decompose the change, do not just report it
-
-A month-over-month change should break into new, reactivation, expansion,
-contraction and churn, and those should sum to the change. Check the
-reconciliation before quoting it. If it does not reconcile, say so rather than
-picking the number that looks right.
-
-Two traps to check explicitly:
-
-- **Opening balance reported as new business.** Customers acquired before the
-  window are not new in month one. This is the most common way a revenue report
-  overstates growth.
-- **Flat is not nothing happening.** A new customer exactly offsetting a churn
-  reads as zero net change. Show the components.
-
-## Separate MRR from cash
-
-They will not match, and the gap is usually the interesting part. MRR is
-recurring revenue on a subscription basis. Invoices land on billing
-anniversaries and can go unpaid. A customer whose card is failing still carries
-MRR.
-
-Report collection rate next to MRR. Falling collections under flat MRR is a
-problem that a revenue summary alone hides completely.
-
-## Churn risk from billing alone
-
-Billing signals worth surfacing: unpaid invoices, an invoice written off,
-recent contraction, a downgrade.
-
-Each is a question, not a conclusion. A failed invoice is as often an expired
-card as a departing customer. Say that. Product usage is what makes churn
-prediction real; see the `product-analytics` skill.
-
-## When a number looks wrong
-
-Cheapest first. Usually it is one of the first two.
-
-1. **Check the run.** Every asset succeeded, every quality check passed?
-2. **Check freshness.** Maximum date in raw versus the source. A missing recent
-   load explains most "revenue dropped" reports.
-3. **Reconcile one number by hand.** One month, one customer, from report table
-   back to raw record. Report the trace, not just the conclusion.
-4. **Check the definition against the question.** Most disagreements about a
-   revenue number are disagreements about a definition.
-5. **Check what the load can see.** The `stripe-bigquery` raw assets load
-   incrementally on Stripe's `created` timestamp, so a subscription cancelled or
-   upgraded, or an invoice paid or voided, after its creation window is not
-   picked up until a wider re-run. Read the template README's incremental-loading
-   section and `ingestion/stripe` before blaming the model.
-6. **Check how much history exists.** MRR on the Stripe and Chargebee templates
-   comes from daily snapshots. Stripe history starts at the first run and cannot
-   be backfilled; Chargebee can backfill subscription episodes but not repricing.
-   Movement and retention need two contiguous months of snapshots before they
-   classify anything. Empty is not zero.
-
-If the model and the source genuinely disagree, show the gap. Do not adjust a
-model to match a number someone expected.
-
-## What billing data cannot tell you
-
-| Asked | Actually needed |
-|---|---|
-| "Why did they churn?" | A churn reason, a survey, or product usage. Billing data does not contain it. |
-| "Which feature drives retention?" | Product analytics on a stable shared identity. See `product-analytics`. |
-| "Which channel brings the best customers?" | Ad spend and attribution joined to revenue. See `marketing-analytics`. |
-| "What is our LTV?" | A retention curve and a margin assumption. Both are decisions, not queries. |
-| "Forecast next quarter" | A stated method and its assumptions. Extrapolating a line is not a forecast. |
-
-Say what is missing and offer the concrete next step. Do not produce an
-approximation without labelling it as one.
+- Why a customer churned: that needs a churn reason, a survey or product usage (`product-analytics`).
+- Which channel brings the best customers: that needs spend and attribution (`marketing-analytics`).
+- LTV: it needs a retention curve and a margin assumption, both decisions.
+- A forecast: it needs a stated method and assumptions, not an extrapolated line.
diff --git a/resources/startup-data-kit/revenue-analytics/metric-decisions.md b/resources/startup-data-kit/revenue-analytics/metric-decisions.md
deleted file mode 100644
index 90a0a03..0000000
--- a/resources/startup-data-kit/revenue-analytics/metric-decisions.md
+++ /dev/null
@@ -1,162 +0,0 @@
-# Revenue metric decisions
-
-> **Upstream documentation wins.** This file describes choices, not vendor
-> behaviour. For how a specific field actually behaves, your billing provider's
-> documentation is the source of truth, and their own reporting is what you
-> reconcile against. For what a Bruin template chose, its README is. Where this
-> file disagrees with any of them, they are right. Template defaults below are
-> from the Bruin CLI `v0.11.765` template READMEs, checked 2026-09-30.
-
-Ten choices that change the MRR number. None of them have a single correct
-answer. Templates ship defaults for several: read the metric policy in the
-template's README (`bruin_get_doc_content('getting-started/templates-docs/<name>-README')`)
-and confirm each default with the user. A default nobody confirmed is still a
-silent pick, and a model that picks silently is teaching the user a hard
-question is already settled.
-
-Read this when building or reviewing a revenue model. For a single question,
-surface only the decisions that actually bear on it.
-
-## 1. Annual and multi-year plans
-
-**What it changes:** the largest single source of overstated MRR.
-
-Divide the committed amount across the term. A `$12,000` annual plan is `$1,000`
-of MRR for twelve months, not `$12,000` in the month it was billed. Booking the
-full amount on the invoice date makes one enterprise deal look like a step change
-in recurring revenue.
-
-**Ask:** does the model normalise every billing interval to a monthly amount?
-Check what it does with quarterly and two-year terms too.
-
-## 2. Multiple currencies
-
-**What it changes:** the number moves when exchange rates move, even if nothing
-about the business changed.
-
-Three defensible options: convert at a fixed rate set once, convert at the rate
-on the day, or report per currency and never add them up. All are fine. Mixing
-them, or not saying which is in use, is not.
-
-**Ask:** which one, and is the rate and its date recorded next to the number?
-
-**On a template:** the Stripe and Chargebee templates report per currency and
-apply no FX. Summing their output across currencies is the user's choice to
-make, not the template's.
-
-## 3. Usage and metered billing
-
-**What it changes:** whether "recurring" means anything.
-
-Usage revenue is not recurring in the same sense as a subscription. A customer
-who spent `$4,000` last month may spend `$200` this month. Folding it into MRR
-makes the metric volatile and undermines the reason to track MRR at all.
-
-**Ask:** report it as a separate line, or define an explicit smoothing window
-such as a trailing three-month average, and label it as smoothed.
-
-**On a template:** check what its README chose. `stripe-bigquery` leaves metered
-prices out of MRR entirely.
-
-## 4. Trials
-
-**What it changes:** the customer count, and sometimes the churn rate.
-
-A trialling customer usually has a subscription object and no revenue. Counting
-them as a customer inflates the count and depresses ARPA. Excluding them hides
-the top of the funnel. Counting them as churn when the trial lapses inflates
-churn badly.
-
-**Ask:** are they customers, and does a lapsed trial count as churn?
-
-**On a template:** check what its README chose. `chargebee-bigquery` leaves
-trials out unless `in_trial` is added to `mrr_active_statuses`.
-
-## 5. Paused and past-due subscriptions
-
-**What it changes:** the gap between MRR and cash, and when churn is recognised.
-
-Stripe keeps these in `past_due`, `unpaid` or `paused`. They are still active
-subscriptions carrying MRR while collecting nothing. Counting them indefinitely
-means MRR drifts above reality; dropping them immediately means a failed card
-looks like churn.
-
-**Ask:** after how many days or failed attempts does a non-paying subscription
-stop counting? Pick a number and write it down.
-
-**On a template:** check what its README chose. `stripe-bigquery` counts active
-and past-due subscriptions. `chargebee-bigquery` counts the statuses in
-`mrr_active_statuses`, by default `active` and `non_renewing`.
-
-## 6. Discounts and coupons
-
-**What it changes:** usually a few percent, permanently.
-
-This file recommends MRR net of discount. A customer on a `$199` plan with a 20%
-coupon is `$159.20` of MRR. Reporting list price overstates revenue and makes
-the model disagree with cash for a reason nobody can find later.
-
-**Ask:** which side of the discount is this number on, and what happens when the
-coupon expires?
-
-**On a template:** check what its README chose. `stripe-bigquery` reports gross
-list-price MRR with discounts not applied, the opposite of the recommendation
-above. Say so next to any number from it.
-
-## 7. Taxes
-
-**What it changes:** a small, persistent, maddening gap between MRR and invoices.
-
-MRR should exclude tax. Invoice totals include it. When someone says "MRR does
-not match what Stripe shows me", this is often why.
-
-**Ask:** is the model reading a pre-tax subtotal or an invoice total?
-
-## 8. Proration
-
-**What it changes:** the relationship between invoices and MRR, mid-cycle.
-
-A plan change mid-cycle generates a prorated invoice matching no monthly amount.
-It is real cash and it is not a change in recurring revenue.
-
-**Ask:** does proration affect MRR, or only the cash view? Most models should say
-cash only, and should say so out loud.
-
-## 9. Refunds and disputes
-
-**What it changes:** which month takes the hit.
-
-A refund issued in March for a January invoice can reduce March or January. Both
-are defensible; restating a closed month is not always welcome.
-
-**Ask:** issue month or original month, and are disputes and chargebacks handled
-the same way?
-
-## 10. MRR timing
-
-**What it changes:** every number in the report, subtly.
-
-Three conventions:
-
-| Convention | Behaviour |
-|---|---|
-| **Observed at month start** | A subscription counts if it was live on the 1st. Stops a mid-month plan change counting the old and new plan in the same month. A mid-month signup first appears the following month. |
-| **Observed at month end** | Mirror image. Flatters new business in its first month. |
-| **Daily average** | Most accurate, hardest to reconcile against anything, and harder to explain. |
-
-All three are defensible. Only one should appear in the reports.
-
-**Ask:** which one, and is it stated next to the number?
-
-**On a template:** check what its README chose. The Stripe and Chargebee
-templates both report MRR observed at month end.
-
-## Using this list
-
-When reviewing an existing model, go through all ten and record the answer next
-to each metric definition. The recording matters as much as the choice: the cost
-of an undocumented convention is not that it is wrong, it is that six months
-later nobody can say what the number means.
-
-When answering a single question, surface only the decisions that bear on it. A
-question about churn count does not need the currency policy.
diff --git a/resources/startup-data-kit/revenue-analytics/workflow.md b/resources/startup-data-kit/revenue-analytics/workflow.md
index 591061d..a3300e7 100644
--- a/resources/startup-data-kit/revenue-analytics/workflow.md
+++ b/resources/startup-data-kit/revenue-analytics/workflow.md
@@ -3,158 +3,73 @@
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
 > docs](https://getbruin.com/docs/bruin/overview.html) or `bruin <command>
 > --help`, upstream is right and this file is stale. Written against Bruin CLI
-> `v0.11.765`, checked 2026-10-01.
+> `v0.11.766`, checked 2026-10-01.
 
-Every skill in the startup data kit carries an identical copy of this file.
-The skill's own `SKILL.md` says which templates fit its domain and what tends to
-matter there; this file is the process. Work through it in order.
+Identical in every startup-data-kit skill. Work in order.
 
 ## Working with the user
 
-This is a conversation, not a script. The point of a maintained template is
-that the modelling is done; the point of this process is that it ends up
-modelling *this* startup, not a generic one.
-
-- **Check before acting.** Most users have done some of this already, and
-  redoing a step is how a working setup gets broken. Say what you checked and
-  what you found.
-- **Ask before every write.** Installing, initialising, editing configuration,
-  changing a model, running a pipeline: say exactly what will change and wait
-  for a yes. Show diffs.
-- **Ask a few questions at a time, each with the default.** For every choice,
-  say what the template does today, what the alternative would change, and why
-  it matters. "Keep the default" should be an easy answer.
-- **Explain the term, not just the question.** Many founders are not data
-  people. "MRR counted at month end" means nothing until you say what it does
-  to a mid-month signup.
-- **Do not guess an answer.** If the user does not know, propose the default
-  and record it as unconfirmed. A choice the user did not make should not read
-  as though they did.
-- **When only the user can do a step**, give them the exact steps and wait
-  until they say it is done.
-- **Write the answers down** as you go, in a `decisions.md` beside the
-  pipeline's `pipeline.yml`: each choice, what was picked, whether the user
-  confirmed it or it is still the template's default, and the date. The next
-  agent, and the user in six months, will need it.
+- **Check before acting;** say what you found. Never redo working steps.
+- **Ask before every write** (install, init, config, model, run); show the diff, wait for a yes.
+- **Ask a few questions at a time,** each with its default and the term in plain words.
+- **Do not guess.** If the user does not know, record the default as unconfirmed.
+- **When only the user can do a step,** give exact steps and wait.
+- **Record answers in `decisions.md` beside `pipeline.yml`:** choice, pick, confirmed or default, date.
 
-## 1. Bruin is installed
-
-```bash
-bruin version
-```
+## Look it up live
 
-- **Installed and current:** move on.
-- **Installed, but `Latest` is newer than `Current`:** offer `bruin upgrade`.
-  Do not run it unasked.
-- **Not installed:** ask, then run
-  `curl -LsSf https://getbruin.com/install/cli | sh` and check `bruin version`
-  again. On Windows, or if the install fails, read
-  `getting-started/introduction/installation` rather than guessing.
+- Commands and flags: `bruin <command> --help`.
+- Docs: Bruin MCP `bruin_get_doc_content` for `getting-started/templates-docs/<name>-README`, `ingestion/<source>`, `platforms/<warehouse>`; or `https://getbruin.com/docs/bruin/<path>.html`.
+- The user's pipelines, runs and connections: Bruin Cloud MCP (`cloud/mcp-setup`), if they run Bruin Cloud.
 
-## 2. The Bruin MCP server is connected
+## 1. Bruin is installed
 
-Check whether you already have the `bruin_get_docs_tree` and
-`bruin_get_doc_content` tools. If you do, move on.
+`bruin version`. If `Latest` is newer than `Current`, offer `bruin upgrade`. If missing, ask, then `curl -LsSf https://getbruin.com/install/cli | sh`; on Windows or failure, read `getting-started/introduction/installation`.
 
-If not, register it, because the rest of this skill reads Bruin's docs through
-it. Until then, read the same pages at
-`https://getbruin.com/docs/bruin/<path>.html`; the setup page is
-`getting-started/bruin-mcp`.
+## 2. The Bruin MCP server is connected
 
-- **If your host lets you change its MCP configuration**, show the exact
-  command or snippet from that page, say which file it changes and whether that
-  affects only this project or every project, and run it only after the user
-  approves. For Claude Code the page gives `claude mcp add bruin -- bruin mcp`.
-- **If you cannot**, walk the user through it: the snippet for their host, where
-  it goes, and that the host usually needs a restart or reload before the tools
-  appear.
+If you lack the `bruin_get_doc_content` tool, read `getting-started/bruin-mcp`.
 
-The local server serves Bruin's documentation only. Bruin Cloud MCP is separate
-(`cloud/mcp-setup`) and only worth setting up if the user runs Bruin Cloud.
+- If you can edit the host's MCP config, show the exact command (Claude Code: `claude mcp add bruin -- bruin mcp`) and its project or global scope; run it only after approval.
+- Otherwise give the user the snippet; the host usually needs a restart.
 
 ## 3. You are inside the user's own git repository
 
-```bash
-git rev-parse --show-toplevel
-```
-
-- **Not a repository:** ask which folder the project should live in, then
-  `git init` there. Without a repository, `bruin init` creates a `bruin/`
-  wrapper folder and initialises git inside that instead.
-- **A repository:** confirm it is the user's project. Never scaffold inside a
-  clone of a public catalogue such as this one, or inside another Bruin
-  project. A `.bruin.yml` higher up the tree gets picked up by mistake.
-- **A Bruin project already exists here** (a `.bruin.yml`, a `pipeline.yml`):
-  ask whether to add to it or start fresh. Adding a template to an existing
-  pipeline uses `bruin init <template> <pipeline-folder> --merge`; read
-  `commands/init` first, because it leaves `pipeline.yml` alone.
+`git rev-parse --show-toplevel`.
+
+- **Not a repository:** ask which folder, then `git init`; otherwise `bruin init` creates a `bruin/` wrapper with its own git.
+- **A repository:** confirm it is the user's, not a public catalogue or another Bruin project (a parent `.bruin.yml` gets picked up).
+- **Bruin project exists:** ask whether to add (`--merge`; read `commands/init`) or start fresh.
 
 ## 4. Confirm the warehouse
 
-Ask which database or warehouse the data should land in. Do not pick for them.
-The destination decides which templates exist at all, so ask before choosing a
-template.
+Ask where the data lands; do not pick. It decides which templates exist.
 
-- **They already have one:** use it. Keep the boundary they already run.
-- **They have none:** say which destinations the templates for this domain
-  support (`bruin init --help` lists every template; the destination is usually
-  in the name), and what each costs them in setup. Some templates run on local
-  DuckDB with nothing to provision.
-- **No template supports their warehouse:** say so plainly. Offer the closest
-  template on another destination, or ingestion alone with the modelling left to
-  build. Do not improvise a template.
+- **None yet:** list destinations this domain's templates support (`bruin init --help`) and their setup cost; some run on local DuckDB.
+- **No template supports it:** say so; offer the closest template elsewhere, or ingestion alone. Never improvise one.
 
 ## 5. Choose the template
 
-Use the domain's `SKILL.md` for which templates to consider and their caveats.
-Then confirm against the live list, because templates are added and renamed:
+1. `bruin init --help` for current names; keep those matching source and warehouse.
+2. Read each candidate's README; if none, say so and read the scaffolded `README.md`.
+3. Tell the user what each builds, needs and omits. Let them choose.
+4. After a yes, `bruin init <template>`. If it opens an interactive wizard, give the user the command.
+5. Read the scaffolded files, run `bruin validate <pipeline-folder>`, and tell the user anywhere they disagree with the README or fail.
 
-1. `bruin init --help` for the current names. Keep the ones that match the
-   user's source and the warehouse confirmed in step 4.
-2. Read each candidate's README before recommending it:
-   `getting-started/templates-docs/<name>-README`. Some templates have none; say
-   so and read the `README.md` it scaffolds instead.
-3. Tell the user what each candidate builds, what it needs, and what it does
-   not cover. Let them choose.
-
-Then `bruin init <template>`, after they agree. Some templates, such as
-`ecommerce`, open an interactive wizard and fail without a terminal; give the
-user the command to run themselves, and read what it wrote afterwards. If nothing fits, say so. Ingesting a source with no template means
-building the modelling yourself, which is a project; agree that with the user
-before starting it. Some questions need no pipeline at all; if so, say that
-too, rather than building one.
+If nothing fits, say so; agree before building modelling yourself. If no pipeline is needed, say so.
 
 ## 6. Credentials into `.bruin.yml`
 
-`bruin init` writes a `.bruin.yml` with placeholder connections. The template's README and that file say which connections it needs.
-
-**Never ask for a credential in chat or pass one as a command argument.** If the
-user pastes one, tell them not to send it and to rotate it, because it now sits
-in the transcript.
+The README and assets name the connections. A sample's inline key is a shape, not a value.
 
-For each connection:
+**Never ask for a credential in chat or pass one as a command argument.** If the user pastes one, tell them to rotate it.
 
-1. **Read what it needs.** `ingestion/<source>` for a source and
-   `platforms/<warehouse>` for a destination list the required fields and link
-   to the provider's own instructions.
-2. **Walk the user through getting it.** Where to click at the provider, and the
-   smallest scope that works: a read-only or restricted key, a service account
-   with read access, never an admin or live secret key when a narrower one
-   exists. A read-only credential is a control; a promise in a file is not.
-3. **Keep the value out of the file.** The user stores the secret in an
-   environment variable (a gitignored `.env` or `.envrc`, or their secret
-   manager) and you write `${VAR_NAME}` into `.bruin.yml` (`secrets/bruinyml`).
-   Or the user runs `bruin connections add` with no flags and answers its
-   prompts; its flag mode puts the secret on the command line.
-4. **Test it.** `bruin connections test --name <connection>`. Report the result,
-   never the value.
+1. Read `ingestion/<source>` or `platforms/<warehouse>` for the fields.
+2. Walk the user to the narrowest credential: read-only or restricted, never admin when narrower exists.
+3. The user sets an env var (gitignored `.env` or secret manager); you write `${VAR_NAME}` (`secrets/bruinyml`). Or the user runs `bruin connections add` with no flags.
+4. `bruin connections test --name <connection>`. Report the result, never the value.
 
-Then confirm `.bruin.yml` is ignored: `git check-ignore .bruin.yml`. If it is
-not, stop and fix that before anything else is committed.
-
-If the user runs Bruin Cloud, the same rule holds: `bruin cloud login`, or an
-exported `BRUIN_CLOUD_API_KEY`, never `--api-key` on the command line.
-`bruin auth status` shows which one is active without printing it.
+`git check-ignore .bruin.yml`; if not ignored, stop and fix first. Bruin Cloud: `bruin cloud login` or exported `BRUIN_CLOUD_API_KEY`, never `--api-key`.
 
 ## 7. Work out what to ask
 
@@ -164,69 +79,30 @@ exported `BRUIN_CLOUD_API_KEY`, never `--api-key` on the command line.
 > files. Read the template as it is today, list every choice it makes on the
 > user's behalf, and decide which ones this user needs to confirm.
 
-Where templates make choices:
-
-- **The README:** configuration sections, metric policy, first-run and
-  backfill steps, stated limitations.
-- **`pipeline.yml`:** variables and their defaults, schedule, start date.
-- **The assets:** descriptions, filters and `WHERE` clauses (statuses,
-  currencies, test accounts), materialisation, column checks.
-- **The report assets:** what each metric includes and excludes.
-
-Then filter. Use what you know about the business, and ask what you do not: a
-question about annual plans only matters if they sell annual plans. The domain's
-`SKILL.md` lists the areas that usually matter there. Treat it as a lens for
-spotting choices, not as the questions to ask.
-
-Group what is left by topic, lead with the ones that change the headline
-numbers, and ask. Add any business context the template needs but cannot infer,
-such as test or internal accounts to exclude, or how much history matters.
+- Read the README, `pipeline.yml` variables, asset filters, checks, and report metric definitions.
+- Drop choices that do not apply; `SKILL.md` is a lens, not a script.
+- Add what the template cannot infer (test accounts, history needed); lead with what moves headline numbers.
 
 ## 8. Customise
 
-Change the template to match the answers, one topic at a time.
-
-- **Prefer configuration to code.** A variable in `pipeline.yml` survives a
-  template update; an edited `WHERE` clause has to be carried forward by hand.
-- **When SQL has to change,** keep the edit small, and update the asset's
-  description to state the convention it now follows.
-- **After each change,** run `bruin validate <pipeline-folder>`, show the diff,
-  and record the decision in `decisions.md`.
+- Prefer a `pipeline.yml` variable to SQL edits; keep SQL edits small and update the asset description.
+- After each change: `bruin validate <pipeline-folder>`, show the diff, record it.
 
 ## 9. First run, bounded
 
-Before running, agree three things with the user and state them back:
-
-- **The environment.** `bruin environments list`. Most templates create only
-  `default`; creating or cloning another (`commands/environments`) is a change
-  that needs approval.
-- **The window.** `--start-date` and `--end-date`; a local run defaults to
-  yesterday only. Say the expected scan.
-- **The template's own first-load steps** from its README. If one is
-  `--full-refresh`, name what it replaces before asking.
+Agree and state back, then `bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>`:
 
-```bash
-bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>
-```
+- **Environment:** `bruin environments list`; creating one needs approval.
+- **Window:** a local run defaults to yesterday only. Say the expected scan.
+- **README first-load steps:** if one is `--full-refresh`, name what it replaces before asking.
 
-## 10. Check it against the source, together
+## 10. Reconcile with the user
 
-A pipeline that ran and a pipeline that loaded the right data are different
-claims. Pick one number the user can see in the source's own dashboard (last
-month's revenue, active subscriptions, sessions) and reconcile it with them.
+Compare one number from the source's own dashboard.
 
-- **The numbers match, or differ only because of a recorded decision:** say so,
-  and note the explanation in `decisions.md`.
-- **They differ and you cannot say why:** stop. Investigate before anyone uses
-  the reports.
+- **Differs only by a recorded decision:** note it in `decisions.md`.
+- **Differs unexplained:** stop; investigate before anyone uses the reports.
 
 ## 11. Hand off
 
-Tell the user, briefly:
-
-- the template, warehouse, environment and window that ran;
-- each decision, and which ones are still unconfirmed defaults;
-- what is scheduled (nothing, unless they asked for it);
-- what to connect next, if a question they care about needs a second domain.
-
-From here, questions about the data follow the domain's `analysis.md`.
+Report template, warehouse, environment, window, unconfirmed decisions, what is scheduled (nothing unless asked), and what to connect next. Then follow `analysis.md`.
diff --git a/resources/startup-data-kit/sheets-and-notion/SKILL.md b/resources/startup-data-kit/sheets-and-notion/SKILL.md
new file mode 100644
index 0000000..ada9f32
--- /dev/null
+++ b/resources/startup-data-kit/sheets-and-notion/SKILL.md
@@ -0,0 +1,69 @@
+---
+name: sheets-and-notion
+description: Use when a startup wants hand-kept data from Google Sheets or Notion set up or answered. Sets up the gsheet-bigquery, gsheet-duckdb or notion template and answers questions joining plans, targets, mappings and OKRs to other domains, such as targets against MRR.
+---
+
+# Sheets and Notion
+
+**Status:** experimental · **Risk:** approval-required
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
+> Google Sheets or Notion documentation, those are right and this file is
+> stale. Written against Bruin CLI `v0.11.766`, checked 2026-10-01.
+
+Loads hand-kept sheets and Notion databases and answers questions joining them
+to other domains. It exists to prevent quiet breakage when people edit the
+file, and a typed value being read as a measurement.
+
+## Set up
+
+Follow [workflow.md](workflow.md).
+
+> **Important: do not ask a fixed list of questions.** Read the template as it
+> is today and work out which of its choices this user needs to confirm.
+> Templates change, so the questions change with them.
+
+**Templates:** `gsheet-bigquery`, `gsheet-duckdb`, `notion` (to BigQuery);
+confirm with `bruin init --help`. Other warehouses have no template: copy the
+asset and change its destination. Airtable, Smartsheet and SharePoint: read
+`ingestion/<source>`; the modelling is theirs to build.
+
+**Watch for:**
+
+- One raw copy per tab or database; cleaning, typing and unpivoting are models to build.
+- Every load replaces the table: current state only, no history. A re-forecast overwrites the original target; deleted rows disappear.
+- Google sharing is per file, not per tab: a Viewer reads every tab.
+- Notion relations are IDs into other databases (load those too); people properties carry names and emails.
+
+**Usually needs the user's input:**
+
+- Scope: which files, tabs and databases, and which are sensitive, before opening any.
+- Source of truth: system of record, or a hand copy of another system's data? Prefer the system.
+- Shape and types: header row, title or totals rows, merged cells, months as columns, text dates, "TBD" in number columns.
+- Drift: fail the run on a renamed column (`schema_contract: freeze`), or let it quietly go NULL (default).
+- Join keys: must match the other domain's ID exactly; names are not IDs.
+- Grain, calendar, currency and metric convention of whatever the targets are compared to.
+- History: to keep old plans, agree an append or snapshot before the first run; `--full-refresh` then discards it.
+
+**Reconcile against:** the file itself: data-row count and one numeric
+column's total against the loaded table; for Notion, the database row count
+with every view filter removed.
+
+## Answer questions
+
+Read [analysis.md](analysis.md).
+
+## Never
+
+- Ask for or print a credential; write, run, backfill, `--full-refresh` or
+  touch production without a yes; put personal data in output.
+- Write to the sheet or Notion: no Editor access, no Sheets destination, no fixing source values.
+- Open or load a tab or database that is not in scope.
+- Present a typed value as a measurement; say whose it is and as of when.
+
+## Unverified
+
+- How a sheet is parsed (blank rows, formulas, dates, mixed types); load a scratch tab and inspect it.
+- The loaded shape of Notion properties on BigQuery; query the table's schema before modelling.
+- Whether a renamed header leaves a NULL column or drops it; rename one on a scratch tab and rerun.
diff --git a/resources/startup-data-kit/sheets-and-notion/analysis.md b/resources/startup-data-kit/sheets-and-notion/analysis.md
new file mode 100644
index 0000000..65824eb
--- /dev/null
+++ b/resources/startup-data-kit/sheets-and-notion/analysis.md
@@ -0,0 +1,31 @@
+# Answering sheets and Notion questions
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
+> Google Sheets or Notion documentation, those are right and this file is
+> stale. Written against Bruin CLI `v0.11.766`, checked 2026-10-01.
+
+Read `decisions.md` beside the pipeline's `pipeline.yml` first. The Never rules
+in [SKILL.md](SKILL.md) apply.
+
+## Before answering
+
+- Read the staging models before writing SQL and prefer them; raw is the file as typed, totals rows included.
+- Check freshness: the last runs (Bruin Cloud MCP or `bruin cloud runs list`); the warehouse holds the file as of the last run, so "I just updated the sheet" is stale until the next.
+- Check the raw columns still match what staging expects; a renamed header is the commonest overnight change.
+- State the file, tab or database, and the run date, with every number.
+
+## Traps
+
+- A target is a plan: say whose and which version; without history it may be today's re-forecast, hiding the miss against the original.
+- A mapping is someone's judgement; say when it was last reviewed, if anyone knows.
+- A key duplicated on the sheet side multiplies totals; compare totals before and after the join.
+- Report the match rate both ways and keep unmatched rows as `unmapped`; a join on names is approximate.
+- Targets and actuals must share grain, calendar, currency and definition; the current month is partial, not a miss.
+- On Notion, the user sees a filtered view while the load is the whole database, and "Done" is a convention, not an event.
+
+## What this data cannot tell you
+
+- Who changed a value, when or why; edit history is not loaded.
+- Whether a plan was ever agreed; a number in a sheet may be a draft.
+- Anything the file never held; a missing row and a zero look the same after a join.
diff --git a/resources/startup-data-kit/sheets-and-notion/workflow.md b/resources/startup-data-kit/sheets-and-notion/workflow.md
new file mode 100644
index 0000000..a3300e7
--- /dev/null
+++ b/resources/startup-data-kit/sheets-and-notion/workflow.md
@@ -0,0 +1,108 @@
+# Setting up a template with the user
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html) or `bruin <command>
+> --help`, upstream is right and this file is stale. Written against Bruin CLI
+> `v0.11.766`, checked 2026-10-01.
+
+Identical in every startup-data-kit skill. Work in order.
+
+## Working with the user
+
+- **Check before acting;** say what you found. Never redo working steps.
+- **Ask before every write** (install, init, config, model, run); show the diff, wait for a yes.
+- **Ask a few questions at a time,** each with its default and the term in plain words.
+- **Do not guess.** If the user does not know, record the default as unconfirmed.
+- **When only the user can do a step,** give exact steps and wait.
+- **Record answers in `decisions.md` beside `pipeline.yml`:** choice, pick, confirmed or default, date.
+
+## Look it up live
+
+- Commands and flags: `bruin <command> --help`.
+- Docs: Bruin MCP `bruin_get_doc_content` for `getting-started/templates-docs/<name>-README`, `ingestion/<source>`, `platforms/<warehouse>`; or `https://getbruin.com/docs/bruin/<path>.html`.
+- The user's pipelines, runs and connections: Bruin Cloud MCP (`cloud/mcp-setup`), if they run Bruin Cloud.
+
+## 1. Bruin is installed
+
+`bruin version`. If `Latest` is newer than `Current`, offer `bruin upgrade`. If missing, ask, then `curl -LsSf https://getbruin.com/install/cli | sh`; on Windows or failure, read `getting-started/introduction/installation`.
+
+## 2. The Bruin MCP server is connected
+
+If you lack the `bruin_get_doc_content` tool, read `getting-started/bruin-mcp`.
+
+- If you can edit the host's MCP config, show the exact command (Claude Code: `claude mcp add bruin -- bruin mcp`) and its project or global scope; run it only after approval.
+- Otherwise give the user the snippet; the host usually needs a restart.
+
+## 3. You are inside the user's own git repository
+
+`git rev-parse --show-toplevel`.
+
+- **Not a repository:** ask which folder, then `git init`; otherwise `bruin init` creates a `bruin/` wrapper with its own git.
+- **A repository:** confirm it is the user's, not a public catalogue or another Bruin project (a parent `.bruin.yml` gets picked up).
+- **Bruin project exists:** ask whether to add (`--merge`; read `commands/init`) or start fresh.
+
+## 4. Confirm the warehouse
+
+Ask where the data lands; do not pick. It decides which templates exist.
+
+- **None yet:** list destinations this domain's templates support (`bruin init --help`) and their setup cost; some run on local DuckDB.
+- **No template supports it:** say so; offer the closest template elsewhere, or ingestion alone. Never improvise one.
+
+## 5. Choose the template
+
+1. `bruin init --help` for current names; keep those matching source and warehouse.
+2. Read each candidate's README; if none, say so and read the scaffolded `README.md`.
+3. Tell the user what each builds, needs and omits. Let them choose.
+4. After a yes, `bruin init <template>`. If it opens an interactive wizard, give the user the command.
+5. Read the scaffolded files, run `bruin validate <pipeline-folder>`, and tell the user anywhere they disagree with the README or fail.
+
+If nothing fits, say so; agree before building modelling yourself. If no pipeline is needed, say so.
+
+## 6. Credentials into `.bruin.yml`
+
+The README and assets name the connections. A sample's inline key is a shape, not a value.
+
+**Never ask for a credential in chat or pass one as a command argument.** If the user pastes one, tell them to rotate it.
+
+1. Read `ingestion/<source>` or `platforms/<warehouse>` for the fields.
+2. Walk the user to the narrowest credential: read-only or restricted, never admin when narrower exists.
+3. The user sets an env var (gitignored `.env` or secret manager); you write `${VAR_NAME}` (`secrets/bruinyml`). Or the user runs `bruin connections add` with no flags.
+4. `bruin connections test --name <connection>`. Report the result, never the value.
+
+`git check-ignore .bruin.yml`; if not ignored, stop and fix first. Bruin Cloud: `bruin cloud login` or exported `BRUIN_CLOUD_API_KEY`, never `--api-key`.
+
+## 7. Work out what to ask
+
+> **The questions come from the template, not from a list.** Templates change:
+> variables are added, defaults move, reports appear and disappear. Do not work
+> from a remembered or hard-coded set of questions, including any in these
+> files. Read the template as it is today, list every choice it makes on the
+> user's behalf, and decide which ones this user needs to confirm.
+
+- Read the README, `pipeline.yml` variables, asset filters, checks, and report metric definitions.
+- Drop choices that do not apply; `SKILL.md` is a lens, not a script.
+- Add what the template cannot infer (test accounts, history needed); lead with what moves headline numbers.
+
+## 8. Customise
+
+- Prefer a `pipeline.yml` variable to SQL edits; keep SQL edits small and update the asset description.
+- After each change: `bruin validate <pipeline-folder>`, show the diff, record it.
+
+## 9. First run, bounded
+
+Agree and state back, then `bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>`:
+
+- **Environment:** `bruin environments list`; creating one needs approval.
+- **Window:** a local run defaults to yesterday only. Say the expected scan.
+- **README first-load steps:** if one is `--full-refresh`, name what it replaces before asking.
+
+## 10. Reconcile with the user
+
+Compare one number from the source's own dashboard.
+
+- **Differs only by a recorded decision:** note it in `decisions.md`.
+- **Differs unexplained:** stop; investigate before anyone uses the reports.
+
+## 11. Hand off
+
+Report template, warehouse, environment, window, unconfirmed decisions, what is scheduled (nothing unless asked), and what to connect next. Then follow `analysis.md`.
diff --git a/resources/startup-data-kit/support-analytics/SKILL.md b/resources/startup-data-kit/support-analytics/SKILL.md
new file mode 100644
index 0000000..36e0584
--- /dev/null
+++ b/resources/startup-data-kit/support-analytics/SKILL.md
@@ -0,0 +1,70 @@
+---
+name: support-analytics
+description: Use when a startup wants customer support analytics set up or answered. Sets up the gorgias template or Zendesk, Intercom, Freshdesk or HubSpot ingestion and answers ticket volume, response and resolution time, CSAT, backlog and contact reason questions.
+---
+
+# Support analytics
+
+**Status:** experimental · **Risk:** approval-required
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
+> Gorgias, Zendesk, Intercom, Freshdesk or HubSpot documentation, those are
+> right and this file is stale. Written against Bruin CLI `v0.11.766`, checked
+> 2026-10-01.
+
+Sets up a helpdesk pipeline and answers support questions from it. It exists to
+prevent a response time measured from a different clock than the support
+lead's, or a ticket volume that includes spam and auto-replies.
+
+## Set up
+
+Follow [workflow.md](workflow.md).
+
+> **Important: do not ask a fixed list of questions.** Read the template as it
+> is today and work out which of its choices this user needs to confirm.
+> Templates change, so the questions change with them.
+
+**Templates:** `gorgias`; confirm with `bruin init --help`. Zendesk, Intercom,
+Freshdesk and HubSpot have connectors but no template: read
+`ingestion/<source>`; the modelling is theirs to build. CSAT in a survey tool:
+`ingestion/satismeter`, `surveymonkey` or `typeform`.
+
+**Watch for:**
+
+- Raw copy only: no models, reports or checks; every metric definition is the user's.
+- BigQuery only as shipped; another warehouse means changing each asset's destination.
+- Current state only: an updated ticket overwrites its row, so past backlog and reopen counts need a snapshot asset.
+- History loads slowly; estimate ticket and message volume before the first run.
+
+**Usually needs the user's input:**
+
+- Which tickets count: spam, trashed, merged, outbound, auto-closed, internal or test customers.
+- First response: first public agent reply excluding auto-replies; clock start; business hours and timezone; per channel or not.
+- Resolution: how reopened and snoozed tickets count.
+- Contact reasons: tags, intents or custom fields, whichever the team maintains; check fill rate.
+- CSAT: the scale, unanswered surveys, every closed ticket or a sample.
+- The key joining a helpdesk customer to a paying customer, and its match rate.
+- Whether message bodies may sit in the warehouse at all, and who can read them.
+
+**Reconcile against:** the helpdesk's own statistics for tickets created and
+average satisfaction over a settled recent week; compare response times only
+once definitions match.
+
+## Answer questions
+
+Read [analysis.md](analysis.md).
+
+## Never
+
+- Ask for or print a credential; write, run, backfill, `--full-refresh` or
+  touch production without a yes; put personal data in output.
+- Write to the helpdesk: no replies, tags, merges, closes, deletes, macros or rules.
+- Pull message bodies or survey comments into context; aggregate in SQL, and ask before sampling for themes.
+- Rank or name individual agents unless the user asks for agent-level results.
+
+## Unverified
+
+- Daily runs may skip late CSAT scores; after a few runs, compare scored surveys per week with Gorgias.
+- Gorgias's own metric definitions; read its statistics documentation before reconciling.
+- Whether `mask` and `sql_exclude_columns` apply to Gorgias; load once into dev and inspect the columns.
diff --git a/resources/startup-data-kit/support-analytics/analysis.md b/resources/startup-data-kit/support-analytics/analysis.md
new file mode 100644
index 0000000..e24cb68
--- /dev/null
+++ b/resources/startup-data-kit/support-analytics/analysis.md
@@ -0,0 +1,33 @@
+# Answering support analytics questions
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
+> Gorgias, Zendesk, Intercom, Freshdesk or HubSpot documentation, those are
+> right and this file is stale. Written against Bruin CLI `v0.11.766`, checked
+> 2026-10-01.
+
+Read `decisions.md` beside the pipeline's `pipeline.yml` first. The Never rules
+in [SKILL.md](SKILL.md) apply.
+
+## Before answering
+
+- Read any models the user built before writing SQL; the template ships raw tables only. Do not infer meaning from timestamp column names.
+- Check freshness: the last runs (Bruin Cloud MCP or `bruin cloud runs list`), then the latest update time per raw table; a missing load reads as a quiet week.
+- State source, window and definition (clock start and stop, business hours or wall clock) with every number.
+- Apply the agreed ticket population and state the exclusions; if none were agreed, say the number is unfiltered.
+
+## Traps
+
+- A first response of seconds is a rule, not an agent; use the median and a high percentile, split by channel.
+- Open tickets have no resolution time and tickets with no agent reply are not zero; report both counts, or recent weeks look faster.
+- Only the latest close is kept, so a reopened ticket looks like one long resolution.
+- Tickets carry several tags, so shares sum past 100% unless you pick a primary reason; a new tag reads as a new problem.
+- Report CSAT with its response rate and count; respondents skew to extremes and the latest week is incomplete.
+- On a revenue join, report the match rate and normalise per customer or order; larger customers raise more tickets.
+
+## What this data cannot tell you
+
+- Backlog on a past date, unless snapshots exist.
+- Why customers did not write in; silence is not satisfaction.
+- Whether a fix worked, from volume alone; volume moves with traffic, orders, releases and seasons.
+- Agent quality from speed, or cause from tickets rising before churn; report the relationship and sample size.
diff --git a/resources/startup-data-kit/support-analytics/workflow.md b/resources/startup-data-kit/support-analytics/workflow.md
new file mode 100644
index 0000000..a3300e7
--- /dev/null
+++ b/resources/startup-data-kit/support-analytics/workflow.md
@@ -0,0 +1,108 @@
+# Setting up a template with the user
+
+> **Upstream documentation wins.** Where this file disagrees with the [Bruin
+> docs](https://getbruin.com/docs/bruin/overview.html) or `bruin <command>
+> --help`, upstream is right and this file is stale. Written against Bruin CLI
+> `v0.11.766`, checked 2026-10-01.
+
+Identical in every startup-data-kit skill. Work in order.
+
+## Working with the user
+
+- **Check before acting;** say what you found. Never redo working steps.
+- **Ask before every write** (install, init, config, model, run); show the diff, wait for a yes.
+- **Ask a few questions at a time,** each with its default and the term in plain words.
+- **Do not guess.** If the user does not know, record the default as unconfirmed.
+- **When only the user can do a step,** give exact steps and wait.
+- **Record answers in `decisions.md` beside `pipeline.yml`:** choice, pick, confirmed or default, date.
+
+## Look it up live
+
+- Commands and flags: `bruin <command> --help`.
+- Docs: Bruin MCP `bruin_get_doc_content` for `getting-started/templates-docs/<name>-README`, `ingestion/<source>`, `platforms/<warehouse>`; or `https://getbruin.com/docs/bruin/<path>.html`.
+- The user's pipelines, runs and connections: Bruin Cloud MCP (`cloud/mcp-setup`), if they run Bruin Cloud.
+
+## 1. Bruin is installed
+
+`bruin version`. If `Latest` is newer than `Current`, offer `bruin upgrade`. If missing, ask, then `curl -LsSf https://getbruin.com/install/cli | sh`; on Windows or failure, read `getting-started/introduction/installation`.
+
+## 2. The Bruin MCP server is connected
+
+If you lack the `bruin_get_doc_content` tool, read `getting-started/bruin-mcp`.
+
+- If you can edit the host's MCP config, show the exact command (Claude Code: `claude mcp add bruin -- bruin mcp`) and its project or global scope; run it only after approval.
+- Otherwise give the user the snippet; the host usually needs a restart.
+
+## 3. You are inside the user's own git repository
+
+`git rev-parse --show-toplevel`.
+
+- **Not a repository:** ask which folder, then `git init`; otherwise `bruin init` creates a `bruin/` wrapper with its own git.
+- **A repository:** confirm it is the user's, not a public catalogue or another Bruin project (a parent `.bruin.yml` gets picked up).
+- **Bruin project exists:** ask whether to add (`--merge`; read `commands/init`) or start fresh.
+
+## 4. Confirm the warehouse
+
+Ask where the data lands; do not pick. It decides which templates exist.
+
+- **None yet:** list destinations this domain's templates support (`bruin init --help`) and their setup cost; some run on local DuckDB.
+- **No template supports it:** say so; offer the closest template elsewhere, or ingestion alone. Never improvise one.
+
+## 5. Choose the template
+
+1. `bruin init --help` for current names; keep those matching source and warehouse.
+2. Read each candidate's README; if none, say so and read the scaffolded `README.md`.
+3. Tell the user what each builds, needs and omits. Let them choose.
+4. After a yes, `bruin init <template>`. If it opens an interactive wizard, give the user the command.
+5. Read the scaffolded files, run `bruin validate <pipeline-folder>`, and tell the user anywhere they disagree with the README or fail.
+
+If nothing fits, say so; agree before building modelling yourself. If no pipeline is needed, say so.
+
+## 6. Credentials into `.bruin.yml`
+
+The README and assets name the connections. A sample's inline key is a shape, not a value.
+
+**Never ask for a credential in chat or pass one as a command argument.** If the user pastes one, tell them to rotate it.
+
+1. Read `ingestion/<source>` or `platforms/<warehouse>` for the fields.
+2. Walk the user to the narrowest credential: read-only or restricted, never admin when narrower exists.
+3. The user sets an env var (gitignored `.env` or secret manager); you write `${VAR_NAME}` (`secrets/bruinyml`). Or the user runs `bruin connections add` with no flags.
+4. `bruin connections test --name <connection>`. Report the result, never the value.
+
+`git check-ignore .bruin.yml`; if not ignored, stop and fix first. Bruin Cloud: `bruin cloud login` or exported `BRUIN_CLOUD_API_KEY`, never `--api-key`.
+
+## 7. Work out what to ask
+
+> **The questions come from the template, not from a list.** Templates change:
+> variables are added, defaults move, reports appear and disappear. Do not work
+> from a remembered or hard-coded set of questions, including any in these
+> files. Read the template as it is today, list every choice it makes on the
+> user's behalf, and decide which ones this user needs to confirm.
+
+- Read the README, `pipeline.yml` variables, asset filters, checks, and report metric definitions.
+- Drop choices that do not apply; `SKILL.md` is a lens, not a script.
+- Add what the template cannot infer (test accounts, history needed); lead with what moves headline numbers.
+
+## 8. Customise
+
+- Prefer a `pipeline.yml` variable to SQL edits; keep SQL edits small and update the asset description.
+- After each change: `bruin validate <pipeline-folder>`, show the diff, record it.
+
+## 9. First run, bounded
+
+Agree and state back, then `bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>`:
+
+- **Environment:** `bruin environments list`; creating one needs approval.
+- **Window:** a local run defaults to yesterday only. Say the expected scan.
+- **README first-load steps:** if one is `--full-refresh`, name what it replaces before asking.
+
+## 10. Reconcile with the user
+
+Compare one number from the source's own dashboard.
+
+- **Differs only by a recorded decision:** note it in `decisions.md`.
+- **Differs unexplained:** stop; investigate before anyone uses the reports.
+
+## 11. Hand off
+
+Report template, warehouse, environment, window, unconfirmed decisions, what is scheduled (nothing unless asked), and what to connect next. Then follow `analysis.md`.
diff --git a/resources/startup-data-kit/web-analytics/SKILL.md b/resources/startup-data-kit/web-analytics/SKILL.md
index cf4700d..00a62c9 100644
--- a/resources/startup-data-kit/web-analytics/SKILL.md
+++ b/resources/startup-data-kit/web-analytics/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: web-analytics
-description: Use when a startup wants web analytics set up or answered. Walks the user through installing Bruin, turning on the GA4 and Search Console exports to BigQuery, and choosing and customising the google-web-analytics template or GA4 and Search Console ingestion to their site, then answers traffic, landing page, channel, conversion and funnel questions from it, including joins to signups and revenue.
+description: Use when a startup wants web analytics set up or answered. Sets up GA4 and Search Console data through the google-web-analytics template or ingestion and answers traffic, landing page, channel, conversion and funnel questions, including joins to signups and revenue.
 ---
 
 # Web analytics
@@ -8,164 +8,62 @@ description: Use when a startup wants web analytics set up or answered. Walks th
 **Status:** experimental · **Risk:** approval-required
 
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
-> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
-> Google's GA4 and Search Console documentation, those are right and this file
-> is stale. GA4 definitions in particular are configurable per property, so the
-> property's own settings beat any general description here. Written against
-> Bruin CLI `v0.11.765`, checked 2026-10-01.
-
-Two jobs. **Set up:** work with the user to install a maintained Bruin web
-analytics template and customise it to their site and property. **Answer:**
-questions from what it built, in [analysis.md](analysis.md).
-
-GA4 is the source people most often quote and least often reconcile. Most of the
-damage is done during setup: a key event that is never sent, a subdomain left
-out, a property timezone nobody checked. Each one fails silently, as an empty
-column or a quietly wrong total.
-
-## Look it up live
-
-This file says what to reach for and what to be careful about. For the facts
-themselves, ask the tool, and tell the user if it disagrees with this file:
-
-- **Flags:** `bruin <command> --help`. The docs lag the CLI.
-- **Docs:** the local Bruin MCP server, `bruin_get_doc_content('<path>')`, or
-  `https://getbruin.com/docs/bruin/<path>.html` without it. For this skill:
-  `getting-started/templates-docs/google-web-analytics-README` for what the
-  template needs, builds and cannot do, `ingestion/google_analytics` for the GA4
-  API connector, `ingestion/gsc` for the Search Console connector, its tables
-  and metrics, and `platforms/bigquery` for the warehouse connection.
-- **The user's environment:** Bruin Cloud MCP, or
-  `bruin cloud ... --output json`.
-
-## Setting it up
-
-Follow [workflow.md](workflow.md) from the top: install, MCP, repository,
-warehouse, template, credentials, then the questions. It is the same process
-for every skill in this kit. What is specific to web analytics is below.
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`,
+> Google's GA4 and Search Console documentation, or the GA4 property's own
+> settings, those are right and this file is stale. Written against Bruin CLI
+> `v0.11.766`, checked 2026-10-01.
+
+Sets up GA4 and Search Console data for this site and answers traffic,
+channel, conversion and funnel questions from it. It exists to prevent setup
+mistakes that fail silently: a key event never sent, a subdomain left out, a
+property timezone nobody checked.
+
+## Set up
+
+Follow [workflow.md](workflow.md).
 
 > **Important: do not ask a fixed list of questions.** Read the template as it
 > is today and work out which of its choices this user needs to confirm.
-> Templates change, so the questions change with them. Workflow step 7 says how.
-
-### Templates to consider
-
-Ask which sites they track, whether they use GA4 and Search Console, and
-whether either already exports to BigQuery. Then check `bruin init --help`; at
-the time of writing the one candidate was `google-web-analytics`.
-
-Caveats to raise before recommending it:
-
-- **It ingests nothing.** It reads the GA4 BigQuery export and the Search
-  Console bulk data export where they already land, so it needs BigQuery and
-  both exports running.
-- **It reads only `events_intraday_*`.** That needs the GA4 export with
-  streaming on. Without streaming every GA4 model is empty, with no error. The
-  README has a query that checks which tables the property produces. Run it
-  before the first run.
-- **Neither export backfills.** History starts the day each was switched on.
-- **Its first run is a `--full-refresh`,** per the README, and changing its
-  brand or path patterns later means rebuilding staging the same way. Name
-  that when you ask.
-- **Not on BigQuery, or no exports:** there is no template. Ingest through
-  `ingestion/google_analytics` and `ingestion/gsc` into their warehouse, and
-  agree with the user that the modelling is theirs to build.
-
-Cloudflare Radar (`ingestion/cloudflare-radar`) is Internet-wide aggregate data,
-not this site's traffic. Do not use it as a traffic or bot source.
-
-**Prefer the BigQuery export over the API where it exists.** The GA4 export
-gives event-level data with no sampling and no quota. The Reporting API applies
-sampling on large properties, enforces quotas, and applies thresholding that
-silently drops rows. If someone has the export, use it and say why.
-
-### Steps only the user can do
-
-These happen in Google's consoles, not in Bruin. Give the exact steps, using
-the Google instructions the README and `ingestion/<source>` pages link to, then
-wait until the user says each is done.
-
-- **Turn on the exports:** the GA4 BigQuery link with streaming, and the Search
-  Console bulk data export.
-- **Grant access:** the BigQuery connection's credentials need read on both
-  export datasets and write on the datasets the pipeline creates. If an export
-  lives in another project, grant read there too.
-- **On the API route:** add the service account as a user on the Search Console
-  property, and enable the Search Console API in its Google Cloud project.
-
-If the exports were only just switched on, say that there is nothing to report
-on yet. Check that the export tables exist and hold rows before the first run.
-
-### What usually matters here
-
-A lens for reading the template, not a script. For each, find what the template
-does, then ask only where this site makes it matter. The definitions table in
-[analysis.md](analysis.md) explains the GA4 terms.
-
-- **Property and data streams:** which GA4 property, and which of its streams
-  are this site.
-- **Sites and hostnames:** which domains and subdomains count, and whether a
-  docs or blog subdomain is a separate page from the marketing site. Whether
-  any URL query parameters carry meaning.
-- **Search Console properties:** Domain or URL-prefix, and how many.
-- **Timezone and currency:** the property's own, against the warehouse and the
-  billing system. Search Console dates are Pacific Time.
-- **Key events:** which events count as conversions, whether the property
-  actually sends them, and what each is worth if revenue lands elsewhere.
-- **Sessions and channels:** the property's session and engagement settings,
-  and default or custom channel grouping.
-- **Internal and bot traffic:** internal traffic filters, staff and test
-  traffic, and known bots.
-- **Brand and page roles:** which queries are branded, and which paths are
-  existing customers (docs, help) rather than prospects.
-- **History:** how far back it matters, and when each export started.
-
-### Reconcile against
-
-The GA4 interface for sessions and users, and the Search Console interface for
-clicks and impressions, over the same settled window. Use a full week or month
-that ended at least three days ago: GA4 takes 24 to 48 hours to settle and
-Search Console lags two to three days. Compare Search Console against a
-property-level table, not one summed across pages.
-
-Expect documented differences, not zero. The README's "Scope and limitations"
-says which figures it matched and where the gaps are. GSC clicks will not equal
-GA4 organic sessions. Record each gap in `decisions.md`.
-
-## Answering questions afterwards
-
-Read [analysis.md](analysis.md): what to check before answering, why GA4
-numbers will not match each other, how Search Console differs, and what this
-data cannot tell you. If the user is on a template, read its report assets and
-"Scope and limitations" before writing any SQL. Rebuilding that logic inline is
-how two answers to the same question start to differ.
+> Templates change, so the questions change with them.
+
+**Templates:** `google-web-analytics`; confirm with `bruin init --help`. Not on
+BigQuery, or no exports: read `ingestion/google_analytics` and `ingestion/gsc`;
+the modelling is theirs to build. Prefer the GA4 BigQuery export over the GA4
+API where it exists. Cloudflare Radar is Internet-wide data, not this site's
+traffic.
+
+**Watch for:**
+
+- It ingests nothing: it reads the GA4 BigQuery export and the Search Console bulk export, which the user must switch on first.
+- It reads only `events_intraday_*`; without GA4 streaming export every GA4 model is empty, with no error.
+- Neither export backfills; history starts the day each was switched on.
+- Changing brand or path patterns later means rebuilding staging with `--full-refresh`.
+
+**Usually needs the user's input:**
+
+- Which GA4 property, and which of its data streams are this site.
+- Which domains and subdomains count, and whether any query parameters carry meaning.
+- Search Console properties: Domain or URL-prefix, and how many.
+- Timezone and currency: the property's, against the warehouse and billing; Search Console dates are Pacific Time.
+- Key events: which count as conversions, whether the property actually sends them, and their value.
+- Session, engagement and channel grouping settings; internal, staff, test and bot traffic to exclude.
+- Branded queries, and which paths (docs, help) are existing customers rather than prospects.
+
+**Reconcile against:** GA4's interface for sessions and users and Search
+Console's property-level clicks and impressions, over a full week or month that
+ended at least three days ago.
+
+## Answer questions
+
+Read [analysis.md](analysis.md).
 
 ## Never
 
-- **Ask for a credential** in chat or as a command argument. A Google service
-  account key is a private key. If offered one, say not to send it and to
-  rotate it if already sent. Workflow step 6 has the safe path.
-- **Print a credential**, including in errors, summaries and generated files.
-- **Run against production** unless asked by name. Say which environment you used.
-- **Pull URL-level data without checking for tokens.** Query strings contain
-  session tokens, password reset links and personal data. Strip parameters
-  before anything reaches a summary.
-- **Treat IP or user-agent data as anonymous.** It is personal data in most
-  jurisdictions.
-- **Pull raw event or user records into context** when an aggregate answers the
-  question.
-- **Write without asking.** Installing, initialising, editing configuration or
-  models, and running a pipeline all wait for the user's yes.
-
-Stop and ask before any write to a source system, outbound message,
-publication, credential change, production access, `--full-refresh` or backfill.
-On this template, `--full-refresh` rebuilds staging from whatever the export
-datasets still hold, and rescans them. Name that consequence and the expected
-scan.
+- Ask for or print a credential; write, run, backfill, `--full-refresh` or
+  touch production without a yes; put personal data in output.
+- Put a URL in output without stripping its query string; it carries session tokens and reset links.
+- Treat IP or user-agent data as anonymous.
 
 ## Unverified
 
-- **GA4 API access.** `ingestion/google_analytics` does not say what access the
-  service account needs on the GA4 property. Google's Data API documentation
-  is expected to require adding it as a user on the property. Read that page
-  and the connector's error output before telling the user it is done.
+- What access a service account needs on a GA4 property for `ingestion/google_analytics`; read Google's Data API documentation and the connector's error output.
diff --git a/resources/startup-data-kit/web-analytics/analysis.md b/resources/startup-data-kit/web-analytics/analysis.md
index c5c1f05..ffd877a 100644
--- a/resources/startup-data-kit/web-analytics/analysis.md
+++ b/resources/startup-data-kit/web-analytics/analysis.md
@@ -1,118 +1,33 @@
 # Answering web analytics questions
 
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
-> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`, or
-> Google's GA4 and Search Console documentation, those are right and this file
-> is stale. GA4 definitions in particular are configurable per property, so the
-> property's own settings beat any general description here. Written against
-> Bruin CLI `v0.11.765`, checked 2026-10-01.
+> docs](https://getbruin.com/docs/bruin/overview.html), `bruin --help`,
+> Google's GA4 and Search Console documentation, or the GA4 property's own
+> settings, those are right and this file is stale. Written against Bruin CLI
+> `v0.11.766`, checked 2026-10-01.
 
-Read this once a web analytics pipeline exists and the user is asking questions
-of it. If `decisions.md` sits beside the pipeline's `pipeline.yml`, read it
-first: it records which property, sites, key events and definitions this model
-follows. The `Never` rules in `SKILL.md` apply here too.
+Read `decisions.md` beside the pipeline's `pipeline.yml` first. The Never rules
+in [SKILL.md](SKILL.md) apply.
 
-GA4 is the source people most often quote and least often reconcile. Sessions,
-users and conversions all mean something specific and none of them mean what the
-plain English word suggests.
+## Before answering
 
-## Before answering any web question
-
-1. **Read the model before querying it.** Asset descriptions state the grain and
-   what is excluded. Do not infer meaning from column names.
-2. **Prefer report and staging tables over the raw exports.** On the
-   `google-web-analytics` template, staging is the interface to build on.
-3. **Check freshness first.** Read the last runs from Bruin Cloud MCP or
-   `bruin cloud runs list --output json`, then the maximum date in the staging
-   tables. On the template, `gsc_export_log` shows what Google actually
-   published.
-4. **State which surface a number came from, every time.** On the
-   `google-web-analytics` template, also read "Scope and limitations" in its
-   README before quoting a number; it lists the template's own gaps.
-
-## GA4 numbers will not match, and that is normal
-
-Do not treat a mismatch as a bug to fix. Explain it.
-
-- **The API and the BigQuery export disagree.** Different processing, different
-  attribution, different session definitions. Both are "GA4".
-- **GA4 sessions differ from Universal Analytics sessions.** Any year-over-year
-  comparison crossing the migration is comparing two different metrics.
-- **Consent mode and ad blockers** mean GA4 undercounts, by a share that varies
-  by audience. A technical B2B audience blocks far more than a consumer one.
-- **Thresholding** suppresses rows with small counts when Google Signals is on.
-  Totals will not equal the sum of a breakdown.
-- **Sampling** applies to large API queries. Check whether a response was
-  sampled before quoting it.
-- **Timezone** is the property's, which may differ from the warehouse and the
-  billing system.
-
-## Definitions to pin down before reporting
-
-Several of these are setup decisions too. If `decisions.md` records the answer,
-use it. If not, ask before quoting.
-
-| Term | The question to ask |
-|---|---|
-| Users | Active users, total users or new users? GA4 reports several and defaults vary by report. |
-| Sessions | 30 minute inactivity timeout by default, and also ends at midnight and on a campaign change. Configurable. |
-| Engaged session | Over 10 seconds, or a conversion, or 2+ pageviews. The threshold is configurable. |
-| Bounce rate | In GA4 this is the inverse of engagement rate, not the UA definition. |
-| Conversion | Whatever was configured as a key event. Check what is actually counted. |
-| Channel grouping | Default or custom? Rules differ and both are called "channel". |
-
-## Search Console is a different dataset, not a subset
-
-- **No sessions, no conversions.** `ingestion/gsc` lists what it does carry.
-- **GSC clicks will not equal GA4 organic sessions.** Different measurement
-  points, different filtering, different bot handling. Expect a gap and do not
-  reconcile them to zero.
-- **Position is an average**, weighted oddly, and an average of averages across
-  queries is not meaningful.
-- **Anonymised queries** are excluded from the query dimension but included in
-  totals, so query-level rows will not sum to the total.
-- **Limited history.** Search Console keeps roughly 16 months. Load it into
-  the warehouse if longer matters.
-- **Recent days are missing, and past days change.** Search Console lags two to
-  three days and revises history in place. Reload a trailing window rather than
-  only appending, and leave the last three days out of any comparison.
-
-## The join that makes it useful
-
-Web analytics alone reports traffic. Joined to billing, it reports acquisition:
-
-| Question | Needs |
-|---|---|
-| Which landing pages produce paying customers | Landing page to signup to revenue |
-| Which channels bring customers who stay | Channel joined through to retention |
-| Where the funnel actually leaks | Session to signup to activation to payment |
-| Whether an SEO investment paid back | GSC clicks to signups over a stated window |
-
-The join key is the hard part. It usually means a signup form capturing the
-landing page and channel, stored on the account. If that does not exist, say
-that the join is the work, and that GA4-only answers stop at traffic.
+- Read the report and staging assets, and the README's "Scope and limitations", before writing SQL; build on staging, not the raw exports.
+- Check freshness: the last runs (Bruin Cloud MCP or `bruin cloud runs list`), then the maximum date in staging.
+- State the surface (GA4 export, GA4 API or Search Console), the window and the definition with every number.
+- Pin users, sessions, engaged sessions, key events and channel grouping from `decisions.md`, or ask; GA4 bounce rate is the inverse of engagement rate.
 
 ## Traps
 
-- **Averaging rates.** The average of daily conversion rates is not the
-  conversion rate. Sum numerators and denominators.
-- **Recent days are incomplete.** GA4 data can take 24 to 48 hours to settle.
-  Never compare an incomplete window to a complete one without labelling it.
-- **Bot traffic.** GA4 filters known bots, not all of them. A traffic spike with
-  no downstream effect is usually not people.
-- **Site changes look like behaviour changes.** A redesign, a URL change or a
-  new consent banner shifts every metric at once. Check the deploy log before
-  inventing a story.
-- **Seasonality.** Compare like periods, and say which.
+- The GA4 API and the BigQuery export disagree, and GA4 sessions are not Universal Analytics sessions; explain the gap, do not fix it.
+- Thresholding and sampling mean API breakdowns may not sum to totals; check whether a response was sampled.
+- Consent mode and ad blockers undercount, far more for a technical B2B audience.
+- Search Console clicks will not equal GA4 organic sessions; anonymised queries count in totals but not query rows; never average average position.
+- GA4 takes 24 to 48 hours to settle, and Search Console lags two to three days and revises past days; leave recent days out of comparisons.
+- The average of daily rates is not the rate; sum numerators and denominators.
 
 ## What this data cannot tell you
 
-| Asked | Actually needed |
-|---|---|
-| "Why did traffic drop?" | Check for a tracking change, a deploy or a consent banner first. Those explain most drops. |
-| "Did this campaign work?" | An experiment or holdout. Traffic correlating with a launch is a hypothesis. |
-| "What is our real conversion rate?" | A decision about the denominator: all sessions, new sessions, or qualified traffic. Ask. |
-| "Which keyword drives revenue?" | Keyword-level revenue attribution, which GSC cannot provide. See [`ai-search-visibility`](../ai-search-visibility/SKILL.md). |
-
-Say what is missing and offer the concrete next step. Do not produce an
-approximation without labelling it as one.
+- Why traffic dropped, until a tracking change, deploy, consent banner or bot spike is ruled out.
+- Whether a campaign worked; that needs an experiment or holdout.
+- Revenue by landing page, channel or keyword, without a signup form storing landing page and channel on the account; otherwise answers stop at traffic.
+- Search history beyond Search Console's roughly 16 months, unless it was loaded earlier.
diff --git a/resources/startup-data-kit/web-analytics/workflow.md b/resources/startup-data-kit/web-analytics/workflow.md
index 591061d..a3300e7 100644
--- a/resources/startup-data-kit/web-analytics/workflow.md
+++ b/resources/startup-data-kit/web-analytics/workflow.md
@@ -3,158 +3,73 @@
 > **Upstream documentation wins.** Where this file disagrees with the [Bruin
 > docs](https://getbruin.com/docs/bruin/overview.html) or `bruin <command>
 > --help`, upstream is right and this file is stale. Written against Bruin CLI
-> `v0.11.765`, checked 2026-10-01.
+> `v0.11.766`, checked 2026-10-01.
 
-Every skill in the startup data kit carries an identical copy of this file.
-The skill's own `SKILL.md` says which templates fit its domain and what tends to
-matter there; this file is the process. Work through it in order.
+Identical in every startup-data-kit skill. Work in order.
 
 ## Working with the user
 
-This is a conversation, not a script. The point of a maintained template is
-that the modelling is done; the point of this process is that it ends up
-modelling *this* startup, not a generic one.
-
-- **Check before acting.** Most users have done some of this already, and
-  redoing a step is how a working setup gets broken. Say what you checked and
-  what you found.
-- **Ask before every write.** Installing, initialising, editing configuration,
-  changing a model, running a pipeline: say exactly what will change and wait
-  for a yes. Show diffs.
-- **Ask a few questions at a time, each with the default.** For every choice,
-  say what the template does today, what the alternative would change, and why
-  it matters. "Keep the default" should be an easy answer.
-- **Explain the term, not just the question.** Many founders are not data
-  people. "MRR counted at month end" means nothing until you say what it does
-  to a mid-month signup.
-- **Do not guess an answer.** If the user does not know, propose the default
-  and record it as unconfirmed. A choice the user did not make should not read
-  as though they did.
-- **When only the user can do a step**, give them the exact steps and wait
-  until they say it is done.
-- **Write the answers down** as you go, in a `decisions.md` beside the
-  pipeline's `pipeline.yml`: each choice, what was picked, whether the user
-  confirmed it or it is still the template's default, and the date. The next
-  agent, and the user in six months, will need it.
+- **Check before acting;** say what you found. Never redo working steps.
+- **Ask before every write** (install, init, config, model, run); show the diff, wait for a yes.
+- **Ask a few questions at a time,** each with its default and the term in plain words.
+- **Do not guess.** If the user does not know, record the default as unconfirmed.
+- **When only the user can do a step,** give exact steps and wait.
+- **Record answers in `decisions.md` beside `pipeline.yml`:** choice, pick, confirmed or default, date.
 
-## 1. Bruin is installed
-
-```bash
-bruin version
-```
+## Look it up live
 
-- **Installed and current:** move on.
-- **Installed, but `Latest` is newer than `Current`:** offer `bruin upgrade`.
-  Do not run it unasked.
-- **Not installed:** ask, then run
-  `curl -LsSf https://getbruin.com/install/cli | sh` and check `bruin version`
-  again. On Windows, or if the install fails, read
-  `getting-started/introduction/installation` rather than guessing.
+- Commands and flags: `bruin <command> --help`.
+- Docs: Bruin MCP `bruin_get_doc_content` for `getting-started/templates-docs/<name>-README`, `ingestion/<source>`, `platforms/<warehouse>`; or `https://getbruin.com/docs/bruin/<path>.html`.
+- The user's pipelines, runs and connections: Bruin Cloud MCP (`cloud/mcp-setup`), if they run Bruin Cloud.
 
-## 2. The Bruin MCP server is connected
+## 1. Bruin is installed
 
-Check whether you already have the `bruin_get_docs_tree` and
-`bruin_get_doc_content` tools. If you do, move on.
+`bruin version`. If `Latest` is newer than `Current`, offer `bruin upgrade`. If missing, ask, then `curl -LsSf https://getbruin.com/install/cli | sh`; on Windows or failure, read `getting-started/introduction/installation`.
 
-If not, register it, because the rest of this skill reads Bruin's docs through
-it. Until then, read the same pages at
-`https://getbruin.com/docs/bruin/<path>.html`; the setup page is
-`getting-started/bruin-mcp`.
+## 2. The Bruin MCP server is connected
 
-- **If your host lets you change its MCP configuration**, show the exact
-  command or snippet from that page, say which file it changes and whether that
-  affects only this project or every project, and run it only after the user
-  approves. For Claude Code the page gives `claude mcp add bruin -- bruin mcp`.
-- **If you cannot**, walk the user through it: the snippet for their host, where
-  it goes, and that the host usually needs a restart or reload before the tools
-  appear.
+If you lack the `bruin_get_doc_content` tool, read `getting-started/bruin-mcp`.
 
-The local server serves Bruin's documentation only. Bruin Cloud MCP is separate
-(`cloud/mcp-setup`) and only worth setting up if the user runs Bruin Cloud.
+- If you can edit the host's MCP config, show the exact command (Claude Code: `claude mcp add bruin -- bruin mcp`) and its project or global scope; run it only after approval.
+- Otherwise give the user the snippet; the host usually needs a restart.
 
 ## 3. You are inside the user's own git repository
 
-```bash
-git rev-parse --show-toplevel
-```
-
-- **Not a repository:** ask which folder the project should live in, then
-  `git init` there. Without a repository, `bruin init` creates a `bruin/`
-  wrapper folder and initialises git inside that instead.
-- **A repository:** confirm it is the user's project. Never scaffold inside a
-  clone of a public catalogue such as this one, or inside another Bruin
-  project. A `.bruin.yml` higher up the tree gets picked up by mistake.
-- **A Bruin project already exists here** (a `.bruin.yml`, a `pipeline.yml`):
-  ask whether to add to it or start fresh. Adding a template to an existing
-  pipeline uses `bruin init <template> <pipeline-folder> --merge`; read
-  `commands/init` first, because it leaves `pipeline.yml` alone.
+`git rev-parse --show-toplevel`.
+
+- **Not a repository:** ask which folder, then `git init`; otherwise `bruin init` creates a `bruin/` wrapper with its own git.
+- **A repository:** confirm it is the user's, not a public catalogue or another Bruin project (a parent `.bruin.yml` gets picked up).
+- **Bruin project exists:** ask whether to add (`--merge`; read `commands/init`) or start fresh.
 
 ## 4. Confirm the warehouse
 
-Ask which database or warehouse the data should land in. Do not pick for them.
-The destination decides which templates exist at all, so ask before choosing a
-template.
+Ask where the data lands; do not pick. It decides which templates exist.
 
-- **They already have one:** use it. Keep the boundary they already run.
-- **They have none:** say which destinations the templates for this domain
-  support (`bruin init --help` lists every template; the destination is usually
-  in the name), and what each costs them in setup. Some templates run on local
-  DuckDB with nothing to provision.
-- **No template supports their warehouse:** say so plainly. Offer the closest
-  template on another destination, or ingestion alone with the modelling left to
-  build. Do not improvise a template.
+- **None yet:** list destinations this domain's templates support (`bruin init --help`) and their setup cost; some run on local DuckDB.
+- **No template supports it:** say so; offer the closest template elsewhere, or ingestion alone. Never improvise one.
 
 ## 5. Choose the template
 
-Use the domain's `SKILL.md` for which templates to consider and their caveats.
-Then confirm against the live list, because templates are added and renamed:
+1. `bruin init --help` for current names; keep those matching source and warehouse.
+2. Read each candidate's README; if none, say so and read the scaffolded `README.md`.
+3. Tell the user what each builds, needs and omits. Let them choose.
+4. After a yes, `bruin init <template>`. If it opens an interactive wizard, give the user the command.
+5. Read the scaffolded files, run `bruin validate <pipeline-folder>`, and tell the user anywhere they disagree with the README or fail.
 
-1. `bruin init --help` for the current names. Keep the ones that match the
-   user's source and the warehouse confirmed in step 4.
-2. Read each candidate's README before recommending it:
-   `getting-started/templates-docs/<name>-README`. Some templates have none; say
-   so and read the `README.md` it scaffolds instead.
-3. Tell the user what each candidate builds, what it needs, and what it does
-   not cover. Let them choose.
-
-Then `bruin init <template>`, after they agree. Some templates, such as
-`ecommerce`, open an interactive wizard and fail without a terminal; give the
-user the command to run themselves, and read what it wrote afterwards. If nothing fits, say so. Ingesting a source with no template means
-building the modelling yourself, which is a project; agree that with the user
-before starting it. Some questions need no pipeline at all; if so, say that
-too, rather than building one.
+If nothing fits, say so; agree before building modelling yourself. If no pipeline is needed, say so.
 
 ## 6. Credentials into `.bruin.yml`
 
-`bruin init` writes a `.bruin.yml` with placeholder connections. The template's README and that file say which connections it needs.
-
-**Never ask for a credential in chat or pass one as a command argument.** If the
-user pastes one, tell them not to send it and to rotate it, because it now sits
-in the transcript.
+The README and assets name the connections. A sample's inline key is a shape, not a value.
 
-For each connection:
+**Never ask for a credential in chat or pass one as a command argument.** If the user pastes one, tell them to rotate it.
 
-1. **Read what it needs.** `ingestion/<source>` for a source and
-   `platforms/<warehouse>` for a destination list the required fields and link
-   to the provider's own instructions.
-2. **Walk the user through getting it.** Where to click at the provider, and the
-   smallest scope that works: a read-only or restricted key, a service account
-   with read access, never an admin or live secret key when a narrower one
-   exists. A read-only credential is a control; a promise in a file is not.
-3. **Keep the value out of the file.** The user stores the secret in an
-   environment variable (a gitignored `.env` or `.envrc`, or their secret
-   manager) and you write `${VAR_NAME}` into `.bruin.yml` (`secrets/bruinyml`).
-   Or the user runs `bruin connections add` with no flags and answers its
-   prompts; its flag mode puts the secret on the command line.
-4. **Test it.** `bruin connections test --name <connection>`. Report the result,
-   never the value.
+1. Read `ingestion/<source>` or `platforms/<warehouse>` for the fields.
+2. Walk the user to the narrowest credential: read-only or restricted, never admin when narrower exists.
+3. The user sets an env var (gitignored `.env` or secret manager); you write `${VAR_NAME}` (`secrets/bruinyml`). Or the user runs `bruin connections add` with no flags.
+4. `bruin connections test --name <connection>`. Report the result, never the value.
 
-Then confirm `.bruin.yml` is ignored: `git check-ignore .bruin.yml`. If it is
-not, stop and fix that before anything else is committed.
-
-If the user runs Bruin Cloud, the same rule holds: `bruin cloud login`, or an
-exported `BRUIN_CLOUD_API_KEY`, never `--api-key` on the command line.
-`bruin auth status` shows which one is active without printing it.
+`git check-ignore .bruin.yml`; if not ignored, stop and fix first. Bruin Cloud: `bruin cloud login` or exported `BRUIN_CLOUD_API_KEY`, never `--api-key`.
 
 ## 7. Work out what to ask
 
@@ -164,69 +79,30 @@ exported `BRUIN_CLOUD_API_KEY`, never `--api-key` on the command line.
 > files. Read the template as it is today, list every choice it makes on the
 > user's behalf, and decide which ones this user needs to confirm.
 
-Where templates make choices:
-
-- **The README:** configuration sections, metric policy, first-run and
-  backfill steps, stated limitations.
-- **`pipeline.yml`:** variables and their defaults, schedule, start date.
-- **The assets:** descriptions, filters and `WHERE` clauses (statuses,
-  currencies, test accounts), materialisation, column checks.
-- **The report assets:** what each metric includes and excludes.
-
-Then filter. Use what you know about the business, and ask what you do not: a
-question about annual plans only matters if they sell annual plans. The domain's
-`SKILL.md` lists the areas that usually matter there. Treat it as a lens for
-spotting choices, not as the questions to ask.
-
-Group what is left by topic, lead with the ones that change the headline
-numbers, and ask. Add any business context the template needs but cannot infer,
-such as test or internal accounts to exclude, or how much history matters.
+- Read the README, `pipeline.yml` variables, asset filters, checks, and report metric definitions.
+- Drop choices that do not apply; `SKILL.md` is a lens, not a script.
+- Add what the template cannot infer (test accounts, history needed); lead with what moves headline numbers.
 
 ## 8. Customise
 
-Change the template to match the answers, one topic at a time.
-
-- **Prefer configuration to code.** A variable in `pipeline.yml` survives a
-  template update; an edited `WHERE` clause has to be carried forward by hand.
-- **When SQL has to change,** keep the edit small, and update the asset's
-  description to state the convention it now follows.
-- **After each change,** run `bruin validate <pipeline-folder>`, show the diff,
-  and record the decision in `decisions.md`.
+- Prefer a `pipeline.yml` variable to SQL edits; keep SQL edits small and update the asset description.
+- After each change: `bruin validate <pipeline-folder>`, show the diff, record it.
 
 ## 9. First run, bounded
 
-Before running, agree three things with the user and state them back:
-
-- **The environment.** `bruin environments list`. Most templates create only
-  `default`; creating or cloning another (`commands/environments`) is a change
-  that needs approval.
-- **The window.** `--start-date` and `--end-date`; a local run defaults to
-  yesterday only. Say the expected scan.
-- **The template's own first-load steps** from its README. If one is
-  `--full-refresh`, name what it replaces before asking.
+Agree and state back, then `bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>`:
 
-```bash
-bruin run --environment <env> --start-date <from> --end-date <to> <pipeline-folder>
-```
+- **Environment:** `bruin environments list`; creating one needs approval.
+- **Window:** a local run defaults to yesterday only. Say the expected scan.
+- **README first-load steps:** if one is `--full-refresh`, name what it replaces before asking.
 
-## 10. Check it against the source, together
+## 10. Reconcile with the user
 
-A pipeline that ran and a pipeline that loaded the right data are different
-claims. Pick one number the user can see in the source's own dashboard (last
-month's revenue, active subscriptions, sessions) and reconcile it with them.
+Compare one number from the source's own dashboard.
 
-- **The numbers match, or differ only because of a recorded decision:** say so,
-  and note the explanation in `decisions.md`.
-- **They differ and you cannot say why:** stop. Investigate before anyone uses
-  the reports.
+- **Differs only by a recorded decision:** note it in `decisions.md`.
+- **Differs unexplained:** stop; investigate before anyone uses the reports.
 
 ## 11. Hand off
 
-Tell the user, briefly:
-
-- the template, warehouse, environment and window that ran;
-- each decision, and which ones are still unconfirmed defaults;
-- what is scheduled (nothing, unless they asked for it);
-- what to connect next, if a question they care about needs a second domain.
-
-From here, questions about the data follow the domain's `analysis.md`.
+Report template, warehouse, environment, window, unconfirmed decisions, what is scheduled (nothing unless asked), and what to connect next. Then follow `analysis.md`.