diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json
index 2848573..7f0d66d 100644
--- a/.claude-plugin/marketplace.json
+++ b/.claude-plugin/marketplace.json
@@ -12,7 +12,7 @@
       "displayName": "PostHog",
       "source": "./",
       "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from your AI coding tool. Optionally capture Claude Code sessions to PostHog LLM Analytics.",
-      "version": "1.1.62",
+      "version": "1.1.63",
       "author": {
         "name": "PostHog",
         "email": "hey@posthog.com",
diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json
index 5325958..9fcd8e8 100644
--- a/.claude-plugin/plugin.json
+++ b/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "posthog",
   "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from your AI coding tool. Optionally capture Claude Code sessions to PostHog LLM Analytics.",
-  "version": "1.1.62",
+  "version": "1.1.63",
   "author": {
     "name": "PostHog",
     "email": "hey@posthog.com",
diff --git a/.codex-plugin/plugin.json b/.codex-plugin/plugin.json
index 6638b86..31d5083 100644
--- a/.codex-plugin/plugin.json
+++ b/.codex-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "posthog",
-  "version": "1.0.60",
+  "version": "1.0.61",
   "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Codex",
   "author": {
     "name": "PostHog",
diff --git a/.cursor-plugin/plugin.json b/.cursor-plugin/plugin.json
index a7c8457..40137c8 100644
--- a/.cursor-plugin/plugin.json
+++ b/.cursor-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "posthog",
   "displayName": "PostHog",
-  "version": "1.1.56",
+  "version": "1.1.57",
   "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Cursor",
   "author": {
     "name": "PostHog",
diff --git a/gemini-extension.json b/gemini-extension.json
index cd26fe2..bd00d13 100644
--- a/gemini-extension.json
+++ b/gemini-extension.json
@@ -1,6 +1,6 @@
 {
   "name": "posthog",
-  "version": "1.0.58",
+  "version": "1.0.59",
   "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Gemini CLI",
   "mcpServers": {
     "posthog": {
diff --git a/skills/authoring-scouts/SKILL.md b/skills/authoring-scouts/SKILL.md
index 72a09ad..50d659e 100644
--- a/skills/authoring-scouts/SKILL.md
+++ b/skills/authoring-scouts/SKILL.md
@@ -127,6 +127,13 @@ For an **existing scout**, tune with `posthog:scout-config-update` (find the `id
   A scout whose reports nobody engages with (no open, rating, or action — the cloud web inbox records reads; other clients don't yet) is warned and then paused automatically (`pause_reason=ignored`) — every run costs a sandbox agent, so a scout producing output no human consumes shouldn't keep running forever. A scout that is merely quiet is only flagged (`pause_reason=no_output`, a warning that never advances to a pause), since a watch scout's silence can be its job.
   `-config-list` shows the warning as `status=pending_pause` and the pause as `status=paused_by_system`; setting `enabled=true` again resumes the scout with a fresh grace window before the sweep may judge it again.
   Set `auto_pause_exempt=true` up front for a watchdog scout whose whole job is to stay quiet, so it never even picks up the quiet flag.
+- `write_scopes` — defaults to `[]`: the scout reads the project and writes only what every scout writes (its findings, its memory, and notebooks).
+  Grant `dashboard:write`, `insight:write`, `annotation:write`, or `alert:write` to a scout whose job is to **maintain** one of those things rather than only describe what it would change.
+  Each scope is project-wide and covers update and delete of every object of its kind, not only the ones the scout made, so grant only what the scout's body actually tends, and say in the body what it may change and when.
+  Only the person the scout's runs act as (whoever authored it) or a project admin can set the field, and grants are activity-logged. A scoped API key must itself carry each scope it grants.
+  A granted scout is told in its run prompt which objects it may change, and is asked to name every change in its close-out. The grant is an upper bound: the acting user's own permissions still apply to each object, and the scout reports a refused write rather than retrying it.
+  A dry run (`emit: false`) never holds the grant, so a scout can be previewed without it changing anything.
+  Applies from the scout's next run.
 - `tags` — free-form labels grouping the fleet, e.g. `["revenue", "on-call"]`. Up to 10 per scout, normalized to lowercase kebab-case (`On Call` → `on-call`) and deduped.
   Set them at create time: a scout that lands already grouped saves a follow-up edit, and the desktop app's scout list filters on them.
   Prefer a tag that already exists on the fleet (`-config-list` shows every scout's tags) over minting a near-duplicate — `revenue` and `revenue-analytics` fragment the same group.
diff --git a/skills/authoring-scouts/references/dedupe-and-memory.md b/skills/authoring-scouts/references/dedupe-and-memory.md
index ff2ae9f..7cf0595 100644
--- a/skills/authoring-scouts/references/dedupe-and-memory.md
+++ b/skills/authoring-scouts/references/dedupe-and-memory.md
@@ -10,7 +10,7 @@ Every scout classifies each candidate finding against prior runs, the inbox, and
 Bake this classifier into the scout's Decide section:
 
 1. **Net new** — no prior run mentions the topic, no inbox report and no scratchpad entry covers it. → Author a report via `emit_report` if it clears the report bar (see [`report-contract.md`](report-contract.md)).
-2. **Material update on an existing live report** — a live report already covers the topic (one this scout authored last run, or a pipeline report), but there's new evidence (a different corroborating source, a fresh deploy correlation, contradicting data, a meaningful escalation in scope). → **`edit_report` it** — `append_note` with the fresh evidence, or rewrite `title`/`summary` on a report the scout authored.
+2. **Material update on an existing live report** — a live report already covers the topic (one this scout authored last run, or a pipeline report), but there's new evidence (a different corroborating source, a fresh deploy correlation, contradicting data, a meaningful escalation in scope). → **`edit_report` it** — use `append_evidence` for the new observation, `append_note` for a reading of it, or rewrite `title`/`summary` on a report the scout authored.
    Don't mint a near-duplicate.
    **Live reports only:** `edit_report` never changes a report's status, so if the prior report is suppressed or resolved and the issue is genuinely back, author a **fresh** report (citing the prior `report_id` in the summary) rather than editing a closed one nobody will see.
 3. **Same fact already covered** — an existing report already captures the same evidence shape, nothing has changed. → Skip.
diff --git a/skills/authoring-scouts/references/report-contract.md b/skills/authoring-scouts/references/report-contract.md
index 5b945f5..6d60b59 100644
--- a/skills/authoring-scouts/references/report-contract.md
+++ b/skills/authoring-scouts/references/report-contract.md
@@ -231,15 +231,21 @@ The fleet's reviewer map should compound over time.
 
 ## `edit_report` — update an existing report
 
-Rewrite `title`/`summary`, append a note, set `suggested_reviewers`, and/or replace `charts` / `suggested_prompts` on a report that already exists.
-Pass `run_id` (the current run) and `report_id`, plus at least one of `title`, `summary`, `append_note`, `suggested_reviewers`, `charts`, `suggested_prompts`.
-An edit that supplies content (`title`, `summary`, `charts`, `suggested_prompts`, `append_note`, or a reviewer `reason`) passes the same safety judge as `emit_report`; an unsafe edit is rejected whole and the report keeps what it had.
+Rewrite `title`/`summary`, append evidence or a note, set `suggested_reviewers`, and/or replace `charts` / `suggested_prompts` on a report that already exists.
+Pass `run_id` (the current run) and `report_id`, plus at least one of `title`, `summary`, `append_note`, `append_evidence`, `suggested_reviewers`, `charts`, `suggested_prompts`.
+An edit that supplies content (`title`, `summary`, `charts`, `suggested_prompts`, `append_note`, `append_evidence`, or a reviewer `reason`) passes the same safety judge as `emit_report`; an unsafe edit is rejected whole and the report keeps what it had.
 
 `edit_report` can target **any** of the team's inbox reports — not just ones a scout authored.
 That makes it the right tool when a later run learns something about a report the pipeline (or another scout) created.
 Rules of good behavior:
 
-- **Prefer `append_note` over rewriting** `title`/`summary` on a report you didn't author.
+- Use **`append_evidence`** for a new observation that a reader can check.
+  It takes the same `{description, source_id}` items as `emit_report`, and each one lands in the report's evidence rail as a bound signal, so the report's `signal_count` and `total_weight` grow with it.
+- Use **`append_note`** for commentary — a reading of the report that adds nothing to check, such as the owning team already knowing, or a deploy having fixed it.
+  Send both in one call when an observation needs a reading alongside it.
+- **A recovery is a note, not evidence.** `signal_count` and `total_weight` only grow, and both feed the inbox ranking, so evidence that an issue is over would rank the report as stronger.
+- **At the cap, the note is the channel that still lands.** Emit plus every append share the report's **50** evidence rows, and the grouping pipeline can raise the count too, so a long-lived report can fill up. An append past the cap is rejected and the report keeps what it had.
+- Prefer these additive fields over rewriting `title`/`summary` on a report you didn't author.
   A note is additive and audit-friendly (it carries your scout as the author); a rewrite silently overwrites a human- or pipeline-authored headline.
 - **Don't fight an in-flight pipeline.** A report the summary/research workflow is mid-run on can have its fields overwritten under you.
   If a report is actively being worked, append a note rather than rewriting.
diff --git a/skills/authoring-scouts/references/scout-patterns.md b/skills/authoring-scouts/references/scout-patterns.md
index 003827a..4307179 100644
--- a/skills/authoring-scouts/references/scout-patterns.md
+++ b/skills/authoring-scouts/references/scout-patterns.md
@@ -390,8 +390,8 @@ So the trigger for this pattern is any of: **a judgment with more than one axis*
 - **Bound what you write for non-candidates.** "Record which axis failed" is right for items that are close, and ruinous as a blanket rule on a busy queue — one `remember` call per rejected item can spend the run before the real candidates get read.
   Persist a **state transition** (an item that changed axis since last run) or a capped set of near-misses, and roll the rest into one aggregate backlog entry.
 - **Close the loop on what you filed — and know what closing it can and cannot do.** A "ready to pick up" report is wrong the moment someone picks it up, and it costs a person duplicating work already underway.
-  Re-check each `report:` entry every run and `edit_report` once the item is assigned, PR-linked, or closed — but note that `edit_report` mutates `title`, `summary`, `append_note`, `suggested_reviewers`, `charts`, and `suggested_prompts` **only**.
-  It cannot change status or actionability, so an appended note does not retire the report.
+  Re-check each `report:` entry every run and `edit_report` once the item is assigned, PR-linked, or closed — but note that `edit_report` mutates `title`, `summary`, `append_note`, `append_evidence`, `suggested_reviewers`, `charts`, and `suggested_prompts` **only**.
+  It cannot change status or actionability, so an appended note or evidence row does not retire the report.
   Rewrite the **title and summary** so the stale framing is gone from the surface a human scans, and leave the status change to a person.
 - **Routing the outcome is part of the design.** On the report channel a queue scout can hand work straight to a draft PR: `actionability: immediately_actionable` + `repository` + a `priority` makes the report **eligible** to autostart one.
   Eligible is not automatic — the team's autostart toggle, its priority threshold, the org's self-driving quota, and resolving a runner identity each gate it independently, so a correctly-filed report can sit still for reasons that have nothing to do with the scout.
diff --git a/skills/building-html-canvases/SKILL.md b/skills/building-html-canvases/SKILL.md
index b6ff60d..0408ec2 100644
--- a/skills/building-html-canvases/SKILL.md
+++ b/skills/building-html-canvases/SKILL.md
@@ -47,6 +47,12 @@ build pipeline's dependency admission ships.
   Define your colors as CSS variables under `:root { … }` with overrides under `html.dark { … }`,
   or use theme token utilities (`bg-background`, `text-foreground`, `border-border`) — never a
   light-only hardcoded color.
+- Give your own CSS variables a prefix (`--doc-bg`, `--doc-muted`). Never reuse a platform token
+  name: the bundled Quill stylesheet sets `--background`, `--border`, `--card`, `--chrome`,
+  `--input`, `--muted`, `--primary`, and `--fill-*` on every element, so a `:root` or `html.dark`
+  value with one of those names never reaches any element. A page that colors its text with its own
+  `--muted` then renders unreadable (pale text on a pale page). Validation rejects such a
+  declaration with `platform_token_redeclared`.
 - For canvas/WebGL drawing colors, read the resolved token at runtime
   (`getComputedStyle(document.documentElement).getPropertyValue("--primary")`) or your own CSS
   variables, and re-read on theme change if the scene is long-lived.
diff --git a/skills/building-react-quill-canvases/SKILL.md b/skills/building-react-quill-canvases/SKILL.md
index b36c115..59809c9 100644
--- a/skills/building-react-quill-canvases/SKILL.md
+++ b/skills/building-react-quill-canvases/SKILL.md
@@ -71,6 +71,11 @@ text-card-foreground`; borders `border-border`. Never a hardcoded hex or light-o
   always use the `-foreground` utility; a filled pill pairs `bg-success text-success-foreground`.
   Prefer the Quill `Badge` (`variant="success"`/`"destructive"`) for deltas so you don't hand-pick.
 - `bg-secondary`, `text-secondary`, `bg-accent`, and `bg-popover` are not defined in the canvas — avoid them.
+- Never declare a CSS variable with a platform token name (`--background`, `--border`, `--card`,
+  `--chrome`, `--input`, `--muted`, `--primary`, `--fill-*`), in a stylesheet or a `<style>` block.
+  Quill sets those on every element, so your value never applies and text can turn unreadable.
+  Prefix your own variables (`--doc-muted`); validation rejects the collision with
+  `platform_token_redeclared`.
 - recharts strokes/fills use token CSS variables (`stroke="var(--primary)"`, grid/axes in
   `var(--border)`/`var(--muted-foreground)`).
 - Write Unicode glyphs (curly quotes, ellipsis, arrows, emoji) as literal characters in JSX —
diff --git a/skills/creating-online-evaluations/SKILL.md b/skills/creating-online-evaluations/SKILL.md
index 3ed7862..51fbd86 100644
--- a/skills/creating-online-evaluations/SKILL.md
+++ b/skills/creating-online-evaluations/SKILL.md
@@ -2,15 +2,15 @@
 name: creating-online-evaluations
 description: >
   Author continuously-running online evaluations in PostHog AI observability, grounded in real failure
-  modes you've identified. Use when the user wants evaluations that automatically score new generations
-  or whole traces going forward — "create an eval to catch X", "continuously check that responses do Y",
+  modes you've identified. Use when the user wants evaluations that automatically score new generations or
+  whole traces going forward — "create an eval to catch X", "continuously check that responses do Y",
   "turn these failures into evals". Covers letting the explored data decide how many evals to create,
-  proposing that set in plain language and asking the user which ones they want, choosing the target and
-  eval type (hog / llm_judge / sentiment), configuring a provider, model, and usable provider key for an
-  llm_judge eval, scoping which generations trigger it via conditions, creating disabled, verifying scope,
-  and enabling. Falls back to proposing a sentiment eval when no failure mode is worth catching.
-  Finding and ranking the failure modes worth evaluating is its own job — use exploring-ai-failures first.
-  To debug or manage evaluations that already exist, use exploring-llm-evaluations.
+  proposing that set for the user to pick, choosing the target and eval type (hog / llm_judge /
+  sentiment), configuring a provider and model for an llm_judge eval (a provider key gates enabling, not
+  creation), scoping which generations trigger it via conditions, creating disabled, verifying scope, and
+  enabling. Proposes a sentiment eval when no failure mode is worth catching. Finding and ranking the
+  failure modes worth evaluating is its own job — use exploring-ai-failures first. To debug or manage
+  evaluations that already exist, use exploring-llm-evaluations.
 ---
 
 # Creating online evaluations
@@ -129,11 +129,11 @@ set into production, which is noise and (for a judge) cost the user didn't agree
 
 ### 2.1 — Choose the eval type
 
-| Use…        | When the criterion is…                                                                                                                |
-| ----------- | ------------------------------------------------------------------------------------------------------------------------------------- |
-| `hog`       | Structural / rule-based (JSON parses, length, regex, tool-call shape). Cheap, deterministic, **no provider key needed.**              |
-| `llm_judge` | Subjective / fuzzy (tone, factuality, on-topic). Costs an LLM call per run; needs a provider, model, and usable provider key.         |
-| `sentiment` | You want sentiment labels on user messages, not a pass/fail (unless very specifically asked for, usually not relevant to this skill). |
+| Use…        | When the criterion is…                                                                                                                                                            |
+| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `hog`       | Structural / rule-based (JSON parses, length, regex, tool-call shape). Cheap, deterministic, **no provider key needed.**                                                          |
+| `llm_judge` | Subjective / fuzzy (tone, factuality, on-topic). Costs an LLM call per run; needs a provider and model. A usable provider key is only needed to enable it, not to create a draft. |
+| `sentiment` | You want sentiment labels on user messages, not a pass/fail (unless very specifically asked for, usually not relevant to this skill).                                             |
 
 Reach for `hog` first, escalate to `llm_judge` if there is no deterministic way to check for what we want to check.
 
@@ -210,12 +210,14 @@ when exact structure matters.
 
 ### 2.3 — Configure the LLM judge
 
-An `llm_judge` evaluation requires a valid `provider` and `model`. It also needs a usable provider key
-when it runs. `provider_key_id` controls whether the evaluation pins one specific key:
+An `llm_judge` evaluation requires only a valid `provider` and `model` to create as a draft. A usable
+provider key is needed to enable it, not to save it, so no `ok` key is a reason to keep the eval disabled,
+not a reason to stop. `provider_key_id` controls whether the evaluation pins one specific key:
 
 - Set `provider_key_id` to the UUID of an `ok`-state key for the same provider to pin it.
-- Set `provider_key_id` to `null` to use the team's active provider key. The active key must be in the
-  `ok` state and use the same provider as `model_configuration.provider`.
+- Set `provider_key_id` to `null` to use the team's active provider key. This is always a valid saved
+  value. To enable the eval, the active key must be in the `ok` state and use the same provider as
+  `model_configuration.provider`.
 
 Hog and sentiment evaluations skip this step.
 
@@ -229,10 +231,12 @@ Confirm the provider and model with `llma-evaluation-judge-models`.
 Call it with no arguments to see the whole catalog at once.
 Providers PostHog funds no models for come back empty unless you pass `key_id` for one of the team's keys; the response's `providers` list flags which ones those are.
 Prefer pinning the chosen key so a later team-wide active-key change does not change how the evaluation runs.
-Leave `provider_key_id` as `null` only after `llma-evaluation-config-get` confirms the active key is usable and its provider matches.
+Leave `provider_key_id` as `null` to run on the team's active key; before enabling, confirm with
+`llma-evaluation-config-get` that the active key is usable and its provider matches.
 
-If there is no usable key, you may still create a disabled draft for the user to review. Do not spot-run or
-enable it. Ask the user to add or validate a key in the UI before continuing.
+No usable key does not block creation. Create the disabled draft with a valid `provider` and `model` for
+the user to review. Do not spot-run or enable it, and ask the user to add or validate a key in the UI so it
+can be enabled later.
 
 ### 2.4 — Create it disabled
 
@@ -261,8 +265,9 @@ posthog:llma-evaluation-create
 ```
 
 For `llm_judge`, swap `evaluation_config` to `{ "prompt": "…" }` and add
-`"model_configuration": { "provider": "openai", "model": "gpt-5-mini", "provider_key_id": "<uuid of an ok-state key from llma-provider-key-list>" }`.
-Use `null` only when the active team key is `ok` and uses the same provider. Full field reference:
+`"model_configuration": { "provider": "openai", "model": "gpt-5-mini", "provider_key_id": null }`.
+Pin `provider_key_id` to the UUID of an `ok`-state key from `llma-provider-key-list` to run on one specific
+key; `null` runs on the team's active key. Either value saves a draft. Full field reference:
 [references/evaluation-payload.md](references/evaluation-payload.md).
 
 ### 2.5 — Verify the scope before enabling
@@ -283,7 +288,8 @@ For generation targets, `count()` is the run volume. For trace targets, count di
 `$ai_trace_id` values because matching generations from the same trace schedule only one run.
 
 If volume is high, set `rollout_percentage` below 100 to sample. Spot-check the evaluator with
-`llma-evaluation-test-hog` (hog) or `llma-evaluation-run` against one generation (llm_judge).
+`llma-evaluation-test-hog` (hog) or `llma-evaluation-run` against one generation (llm_judge; skip the
+spot-run for a judge with no usable key, per 2.3).
 Both tools currently use generation samples; for a trace target they can check shared source or prompt behavior,
 but they do not reproduce the complete settled trace. Review the first live trace results before increasing rollout.
 
@@ -354,8 +360,9 @@ creating so the user can review and toggle it in the UI.
   criterion genuinely can't be coded.
 - **Always create disabled, verify scope, then enable.** An eval firing on the wrong events is worse than
   none — noise, and (for llm_judge) cost.
-- **Configure llm_judge credentials before running.** A judge needs a valid provider and model plus a usable
-  provider key. `provider_key_id` may be `null` only when the matching active team key can be used.
+- **A judge draft needs only a provider and model.** A usable provider key is needed to enable it, not to
+  save it, so no `ok` key means keep it disabled — not stop. `provider_key_id` may be `null` to run on the
+  team's active key.
 - **`bytecode` is server-written** for hog evals — never pass it; send only `evaluation_config.source`.
 - For cluster-scoped evals, identify the cluster with `exploring-llm-clusters`, then translate its event
   filter into `conditions`.
diff --git a/skills/creating-online-evaluations/references/evaluation-payload.md b/skills/creating-online-evaluations/references/evaluation-payload.md
index 1580785..3793a96 100644
--- a/skills/creating-online-evaluations/references/evaluation-payload.md
+++ b/skills/creating-online-evaluations/references/evaluation-payload.md
@@ -12,7 +12,7 @@ schemas below are rendered from the backend Pydantic models at build time, so th
 | `evaluation_type`     | yes            | `"hog"`, `"llm_judge"`, or `"sentiment"`.                                            |
 | `evaluation_config`   | yes            | Shape depends on `evaluation_type` (below).                                           |
 | `output_type`         | yes            | `"boolean"` for `hog`/`llm_judge`; `"sentiment"` for `sentiment`.                    |
-| `output_config`       | no             | `{ "allows_na": bool }` for boolean; `{}` for sentiment.                             |
+| `output_config`       | no             | `{ "allows_na": bool, "true_is_failure": bool }` for boolean; `{}` for sentiment. |
 | `model_configuration` | llm_judge only | Provider + model; key ID optional. Rejected on `hog`/`sentiment`.                     |
 | `target`              | no             | `"generation"` (default), `"trace"`, or `"session"`. Sentiment supports only `"generation"`. |
 | `target_config`       | trace/session only | Settle config discriminated on `strategy` (below); defaults to a 30-minute fixed window for `trace`, and to a 1-hour inactivity window for `session`. |
@@ -133,6 +133,11 @@ Valid `(evaluation_type, output_type)` pairs: `(hog, boolean)`, `(llm_judge, boo
       "default": false,
       "title": "Allows Na",
       "type": "boolean"
+    },
+    "true_is_failure": {
+      "default": false,
+      "title": "True Is Failure",
+      "type": "boolean"
     }
   },
   "title": "BooleanOutputConfig",
@@ -141,6 +146,8 @@ Valid `(evaluation_type, output_type)` pairs: `(hog, boolean)`, `(llm_judge, boo
 ```
 
 `allows_na: true` lets the evaluator return N/A (skip) in addition to pass/fail.
+`true_is_failure: true` treats a raw `true` result as a failure and a raw `false` result as a pass.
+Leave it `false` for the default mapping.
 
 ### sentiment output
 
@@ -152,11 +159,12 @@ Empty object: `{}`.
 | ----------------- | -------- | ------------------------------------------------------------------------------ |
 | `provider`        | yes      | One of `openai`, `anthropic`, `gemini`, `openrouter`, `fireworks`, `azure_openai`, `together_ai`. |
 | `model`           | yes      | Model id, e.g. `gpt-5-mini`. Validate against `llma-evaluation-judge-models`.  |
-| `provider_key_id` | no       | UUID of an `ok`-state key for the same provider. `null` uses the matching active team key. |
+| `provider_key_id` | no       | UUID of an `ok`-state key for the same provider, or `null` to use the active team key. |
 
-`provider` and `model` are required. Pin `provider_key_id` to run on one specific key. Leave it `null` only
-when `llma-evaluation-config-get` shows an `ok`-state active key for the same provider. A disabled draft may
-be saved without a usable key, but it cannot be tested or enabled until a key can be resolved.
+`provider` and `model` are required. Pin `provider_key_id` to run on one specific key, or set it to `null`
+to run on the team's active key — both save a valid draft. To enable an unpinned eval, the active key must
+be `ok` and use the same provider (`llma-evaluation-config-get` shows it). A disabled draft may be saved
+without a usable key, but it cannot be tested or enabled until a key can be resolved.
 
 ## `conditions`
 
@@ -250,7 +258,7 @@ and `item.output` when exact structure matters.
   "evaluation_config": { "prompt": "Return true if the assistant's reply stays on the user's topic, false if it changes subject. Return N/A if the user did not ask a question." },
   "output_type": "boolean",
   "output_config": { "allows_na": true },
-  "model_configuration": { "provider": "openai", "model": "gpt-5-mini", "provider_key_id": "<ok-state key uuid from llma-provider-key-list>" },
+  "model_configuration": { "provider": "openai", "model": "gpt-5-mini", "provider_key_id": null },
   "target": "generation",
   "target_config": {},
   "conditions": [{ "id": "default", "rollout_percentage": 100, "properties": [] }],
@@ -258,5 +266,6 @@ and `item.output` when exact structure matters.
 }
 ```
 
-Set `provider_key_id` to `null` only when the team's active key is in the `ok` state and its provider is
-`openai`.
+`provider_key_id: null` runs on the team's active key and always saves a valid draft. Pin it to an
+`ok`-state key uuid from `llma-provider-key-list` to run on one specific key. To enable an unpinned eval,
+the team's active key must be `ok` and its provider `openai`.
diff --git a/skills/creating-replay-vision-scanners/SKILL.md b/skills/creating-replay-vision-scanners/SKILL.md
index 25f35ed..0d9ac89 100644
--- a/skills/creating-replay-vision-scanners/SKILL.md
+++ b/skills/creating-replay-vision-scanners/SKILL.md
@@ -49,7 +49,7 @@ Pick a `scanner_type` and write its `scanner_config`. Every type needs a `prompt
 | `monitor`    | Open-ended observation against a prompt (e.g. "flag rage clicks") | `{"prompt": "..."}`; optional `"allow_inconclusive": true` (off by default, so the model must answer yes or no)                                                             |
 | `classifier` | Assigns tags from a fixed label set                               | `{"prompt": "...", "tags": ["tag-a", "tag-b"]}` — `tags` needs ≥1 entry; optional `"multi_label": false` (defaults to true), `"allow_freeform_tags": true` (off by default) |
 | `scorer`     | Numeric score on a rubric                                         | `{"prompt": "...", "scale": {"min": 1, "max": 5, "label": "frustration"}}` — `min` < `max`; `label` optional                                                                |
-| `summarizer` | Free-text summary, plus facet embeddings for search               | `{"prompt": "..."}`; optional `"length": "short" \| "medium" \| "long"` (default `"medium"`). Embeddings are always on                                                      |
+| `summarizer` | Free-text summary                                                 | `{"prompt": "..."}`; optional `"length": "short" \| "medium" \| "long"` (default `"medium"`). Embeddings are always on                                                      |
 
 `scanner_type` is **locked after creation** — to change it you delete and recreate, so confirm the type is
 right up front, and get the `scanner_config` shape right (a wrong shape is a create error, not a silent
diff --git a/skills/diagnosing-ci-and-merge-bottlenecks/SKILL.md b/skills/diagnosing-ci-and-merge-bottlenecks/SKILL.md
index ec9d842..1ce1cd7 100644
--- a/skills/diagnosing-ci-and-merge-bottlenecks/SKILL.md
+++ b/skills/diagnosing-ci-and-merge-bottlenecks/SKILL.md
@@ -142,3 +142,5 @@ numbers as a saved insight, a dashboard tile, or a scheduled email/Slack deliver
 (`<prefix>github_pull_requests` / `<prefix>github_workflow_runs`, prefix from `engineering-analytics-sources`)
 are directly queryable with HogQL, and that skill carries the curated column semantics plus the
 insight-create / subscriptions-create workflow.
+
+DORA environment defaults include all persistent production-marked or production-named regions. Read `selected_environments` for the validated exact scope. DRF validates explicit filters against real names, including transient environments. It trims and deduplicates valid names and rejects blank or unknown names with a 400 response. Omit the filter to use the default. Each regional deployment counts separately; lead time counts each PR once at its first successful deployment in any selected environment.
diff --git a/skills/exploring-llm-evaluations/SKILL.md b/skills/exploring-llm-evaluations/SKILL.md
index eaef6f0..4d342a2 100644
--- a/skills/exploring-llm-evaluations/SKILL.md
+++ b/skills/exploring-llm-evaluations/SKILL.md
@@ -60,21 +60,23 @@ All `llma-evaluation-*` tools are defined in `products/ai_observability/mcp/tool
 
 Every run of an evaluation emits an `$ai_evaluation` event. Key properties:
 
-| Property                     | Meaning                                                         |
-| ---------------------------- | --------------------------------------------------------------- |
-| `$ai_evaluation_id`          | UUID of the evaluation config                                   |
-| `$ai_evaluation_name`        | Human-readable name                                             |
-| `$ai_target_event_id`        | UUID of the `$ai_generation` event being scored                 |
-| `$ai_trace_id`               | Parent trace ID (for jumping to the trace UI)                   |
-| `$ai_evaluation_result_type` | Result kind: `boolean` or `sentiment`                           |
-| `$ai_evaluation_result`      | For boolean evaluations: `true` = pass, `false` = fail          |
-| `$ai_evaluation_reasoning`   | Free-text explanation (set by the LLM judge or Hog code)        |
-| `$ai_evaluation_applicable`  | `false` when the evaluator decided the generation is N/A        |
-| `$ai_sentiment_label`        | For sentiment evaluations: `positive`, `neutral`, or `negative` |
-| `$ai_sentiment_score`        | Confidence score for the winning sentiment label                |
+| Property                     | Meaning                                                                          |
+| ---------------------------- | -------------------------------------------------------------------------------- |
+| `$ai_evaluation_id`          | UUID of the evaluation config                                                    |
+| `$ai_evaluation_name`        | Human-readable name                                                              |
+| `$ai_target_event_id`        | UUID of the `$ai_generation` event being scored                                  |
+| `$ai_trace_id`               | Parent trace ID (for jumping to the trace UI)                                    |
+| `$ai_evaluation_result_type` | Result kind: `boolean` or `sentiment`                                            |
+| `$ai_evaluation_result`      | Raw boolean result. Use the evaluation's output config to map it to pass or fail |
+| `$ai_evaluation_reasoning`   | Free-text explanation (set by the LLM judge or Hog code)                         |
+| `$ai_evaluation_applicable`  | `false` when the evaluator decided the generation is N/A                         |
+| `$ai_sentiment_label`        | For sentiment evaluations: `positive`, `neutral`, or `negative`                  |
+| `$ai_sentiment_score`        | Confidence score for the winning sentiment label                                 |
 
 When `$ai_evaluation_applicable = false`, the run counts as N/A regardless of `$ai_evaluation_result`.
 For evaluations that don't support N/A, this property may be `null` — treat null as "applicable".
+For boolean evaluations, `output_config.true_is_failure: false` maps `true` to pass and `false` to fail.
+Set it to `true` for detector-style evaluations where `true` means the evaluator found a problem.
 
 ## Workflow: investigate why an evaluation is failing
 
@@ -270,6 +272,7 @@ LLM judges require organisation AI data processing approval. Hog evaluators do n
 | Add an LLM-judge evaluator | `llma-evaluation-create` with `evaluation_type: "llm_judge"`, `evaluation_config.prompt`, and a `model_configuration` |
 | Tweak the source or prompt | `llma-evaluation-update` (edits `evaluation_config.source` for Hog, `evaluation_config.prompt` for LLM judge)         |
 | Toggle N/A handling        | `llma-evaluation-update` with `output_config.allows_na`                                                               |
+| Set failure polarity       | `llma-evaluation-update` with `output_config.true_is_failure`                                                         |
 | Disable temporarily        | `llma-evaluation-update` with `enabled: false`                                                                        |
 | Remove                     | `llma-evaluation-delete` (soft-delete via PATCH `{deleted: true}`)                                                    |
 
diff --git a/skills/exploring-replay-vision-observations/SKILL.md b/skills/exploring-replay-vision-observations/SKILL.md
index 742ab88..036d980 100644
--- a/skills/exploring-replay-vision-observations/SKILL.md
+++ b/skills/exploring-replay-vision-observations/SKILL.md
@@ -20,8 +20,7 @@ and doing something useful with it. For creating or sizing scanners, use [[creat
   - `classifier` → one or more `tags` from the scanner's label set, plus `tags_freeform` when the scanner
     allows freeform tags, and the `reasoning`.
   - `scorer` → a numeric `score` on the scanner's `scale`, and the `reasoning`.
-  - `summarizer` → a `title` and free-text `summary`, plus the facets that get embedded for search
-    (`intent`, `outcome`, `friction_points`, `keywords`).
+  - `summarizer` → a `title` and free-text `summary`.
 - **Only `succeeded` observations carry a finding.** Triage the rest by `status`/`error_reason` (see below).
 - **Observations are LLM judgments, not ground truth.** One observation is one model's read of one session —
   corroborate before you act on it.
diff --git a/skills/exploring-scouts/SKILL.md b/skills/exploring-scouts/SKILL.md
index ec4892b..5f96e2b 100644
--- a/skills/exploring-scouts/SKILL.md
+++ b/skills/exploring-scouts/SKILL.md
@@ -37,14 +37,14 @@ For "what kind of run was this?" questions — did it author a self-improvement
 
 There are six things you can observe about the fleet, each with its own tool:
 
-| What you want to know                        | Tool                            | What it tells you                                                                                               |
-| -------------------------------------------- | ------------------------------- | --------------------------------------------------------------------------------------------------------------- |
-| Which scouts run, how often, in what posture | `scout-config-list`             | One row per scout: schedule, `enabled`, `status` / `pause_reason`, `emit`, `last_run_at`, `description`, `tags` |
-| What the scouts actually did, run by run     | `scout-runs-list` / `-retrieve` | Per-run status, timing, end-of-run summary, `emitted_report_ids` / `edited_report_ids`, deep-link               |
-| What the fleet has learned across runs       | `scout-scratchpad-search`       | Durable per-team memory (baselines, noise, allowlists)                                                          |
-| What the team has told the fleet             | `scout-notes-list`              | Steering notes humans/agents left for scouts (per-scout or fleet-wide, newest first)                            |
-| Which reports a run wrote or edited          | the run row itself              | `emitted_report_ids` / `edited_report_ids` — resolve each id via `inbox-reports-retrieve`                       |
-| What the scouts surfaced to the user         | `inbox-reports-list`            | The scout-written reports, as the user sees them (filter `source_product: "signals_scout"`)                     |
+| What you want to know                        | Tool                            | What it tells you                                                                                                               |
+| -------------------------------------------- | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
+| Which scouts run, how often, in what posture | `scout-config-list`             | One row per scout: schedule, `enabled`, `status` / `pause_reason`, `emit`, `write_scopes`, `last_run_at`, `description`, `tags` |
+| What the scouts actually did, run by run     | `scout-runs-list` / `-retrieve` | Per-run status, timing, end-of-run summary, `emitted_report_ids` / `edited_report_ids`, deep-link                               |
+| What the fleet has learned across runs       | `scout-scratchpad-search`       | Durable per-team memory (baselines, noise, allowlists)                                                                          |
+| What the team has told the fleet             | `scout-notes-list`              | Steering notes humans/agents left for scouts (per-scout or fleet-wide, newest first)                                            |
+| Which reports a run wrote or edited          | the run row itself              | `emitted_report_ids` / `edited_report_ids` — resolve each id via `inbox-reports-retrieve`                                       |
+| What the scouts surfaced to the user         | `inbox-reports-list`            | The scout-written reports, as the user sees them (filter `source_product: "signals_scout"`)                                     |
 
 `scout-config-list` takes a `tags` parameter (comma-separated) to narrow the roster to the scouts carrying any of the given labels — useful on a large fleet when the question is scoped to one area, e.g. `tags=revenue`.
 
diff --git a/skills/inbox-exploration/SKILL.md b/skills/inbox-exploration/SKILL.md
index 2fbdd04..f728594 100644
--- a/skills/inbox-exploration/SKILL.md
+++ b/skills/inbox-exploration/SKILL.md
@@ -60,6 +60,7 @@ _underlying detail_ — pair them when the user wants to dig in.
 | ------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
 | `inbox-reports-list`                  | Paginated list of reports with filters (status, search, etc.)                                                 |
 | `inbox-reports-retrieve`              | Full detail for a single report                                                                               |
+| `inbox-reports-claim`                 | Claim or release a report, and optionally attach its implementation PR                                        |
 | `inbox-report-artefacts-list`         | A report's full work log — `signal_finding` evidence, status judgments, commits, task runs, notes (read-only) |
 | `inbox-report-artefacts-retrieve`     | Full detail for a single artefact (read-only)                                                                 |
 | `inbox-reports-set-state`             | Resolve (`resolved`), dismiss (`suppressed`), or snooze (`potential`) a single report                         |
@@ -71,12 +72,12 @@ _underlying detail_ — pair them when the user wants to dig in.
 
 The `inbox-reports-*-list` / `-retrieve`, `inbox-report-artefacts-list` / `-retrieve`, and
 `inbox-source-configs-*-list` / `-retrieve` tools are read-only. The exposed writes are `inbox-reports-set-state` (resolve / dismiss / snooze a single report),
-`inbox-reports-bulk-set-state` (the same transition for 1–100 reports in one call) — see
+`inbox-reports-bulk-set-state` (the same transition for 1–100 reports in one call),
+`inbox-reports-claim` (claim / release / attach a PR), see
 _Workflow: resolve, dismiss, or snooze a report_ — and `inbox-source-configs-partial-update`, which flips a
 source's `enabled` flag on or off (e.g. `{enabled: false}` to stop a source feeding the inbox);
-`-create` / `-update` exist too for standing a source up or replacing it wholesale. Other writes
-(pause processing, set `implementation_pr_url`) are not exposed via MCP today — the PR link is
-populated on the product surface when a PR is opened against a report.
+`-create` / `-update` exist too for standing a source up or replacing it wholesale. Pausing
+processing is not exposed via MCP.
 
 ## Terminology
 
@@ -198,6 +199,10 @@ inbox-reports-list
 If `count: 0` comes back, jump to the empty/unconfigured workflow above before saying "your
 inbox is empty" — the right reply depends on whether sources are configured.
 
+A claimed report keeps its pipeline status, so this queue also returns work someone else already
+owns. Add `"unclaimed": true` when the user is asking what is free to pick up, and
+`"assignee": "me"` to list what the caller already owns and may want to resume.
+
 ### Step 2 — Summarize by source and actionability
 
 For each report, the response includes:
@@ -211,6 +216,10 @@ For each report, the response includes:
   report (see "What 'suggested reviewer' means" above — it's based on GitHub commit
   authorship of the relevant code, mapped to PostHog users via linked GitHub identity)
 - `implementation_pr_url` — if a PR has been opened against this report
+- `work_state` — `unclaimed`, `working`, `in_review`, or `done`
+- `assignee` — who claimed the report (a user, an internal task, or an external agent), or `null`
+  when nobody has. Say so when you list a report someone else owns, so it doesn't read as free
+  work
 - `_posthogUrl` — clickable deep-link to the report; **always include this in your response**
 
 Group the results so the user can scan quickly. **Lead with reports where
@@ -285,7 +294,7 @@ implement.** Reports from `signals_scout` (and any LLM-research source) are espe
 double-checking; their `summary` often reads as a confident root-cause with file and function
 names, but it can be stale or wrong.
 
-### Step 1 — Retrieve and check it isn't already handled
+### Step 1 — Retrieve, check existing work, and claim it
 
 ```json
 inbox-reports-retrieve
@@ -297,9 +306,23 @@ Before doing any work, look at:
 - `already_addressed` — if `true`, the fix may already be in flight or merged; confirm with the
   user before duplicating it.
 - `implementation_pr_url` — if a PR is already linked, surface it instead of opening a second one.
+- `work_state` and `assignee` — show whether someone else has already picked it up. A takeover is
+  allowed, but make it deliberate rather than overlooking active work.
 - `status` — only `ready` reports carry a finished judgment. A `candidate` / `pending_input`
   report hasn't been researched yet; don't implement off a half-formed summary.
 
+Before starting research or implementation, claim the report:
+
+```json
+posthog:inbox-reports-claim
+{ "report_id": "<report_uuid>" }
+```
+
+The claim is attributed to the current internal task or external MCP client. Claims do not expire, so
+release the report whenever you walk away without landing a fix — including when you dismiss it instead.
+Release clears ownership only; an attached pull request stays on the report, and release works from any
+status, so a dismissed report can be released too.
+
 ### Step 2 — Verify the diagnosis against the code (do not skip)
 
 Start by reading the report's work log — its evidence and the judgments behind it:
@@ -317,7 +340,13 @@ way the report describes, and actually produces the described failure. As a deep
 the raw underlying signals via the `signals` skill (`metadata.report_id`) if you need the signal
 text behind the curated findings. If the diagnosis doesn't hold up, say so and stop — a wrong
 report is itself a useful finding (and a candidate for _dismiss_ below), not a license to write a
-speculative fix.
+speculative fix. Release the claim you took in Step 1 before you stop, so the report returns to the
+unclaimed view instead of reading as active work nobody is doing:
+
+```json
+posthog:inbox-reports-claim
+{ "report_id": "<report_uuid>", "release": true }
+```
 
 ### Step 3 — Scope the fix to the right layer
 
@@ -329,15 +358,25 @@ speculative fix.
   area-specific skills), make the change minimal, and add a regression test that would have caught
   the reported failure.
 
-### Step 4 — Open the PR and link it back
+### Step 4 — Open the PR and attach it
+
+Open the PR following the repo's PR conventions, then attach it to the report:
+
+```json
+posthog:inbox-reports-claim
+{
+  "report_id": "<report_uuid>",
+  "pr_url": "https://github.com/example/repository/pull/123"
+}
+```
 
-Open the PR following the repo's PR conventions. There is no MCP tool to set
-`implementation_pr_url` — that link is populated on the product surface when a PR is opened
-against the report. So reference the report in the PR description (its `_posthogUrl`) and tell the
-user which report the PR addresses, so the loop is traceable.
+The same PR may be attached to multiple reports. Connected repositories receive immediate state
+validation and webhook updates. PRs from unconnected repositories are accepted with unknown state,
+so resolve those reports manually after the work lands. Also reference the report's `_posthogUrl`
+in the PR description so the loop is traceable from either side.
 
-**Don't resolve a report because you opened a PR.** When the fix ships as a PR, the merge is what
-resolves the report — the tasks GitHub webhook does it automatically. Resolving by hand at PR-open
+**Don't resolve a report because you opened a PR.** When the fix ships as a connected PR, the merge
+resolves the report automatically. Resolving by hand at PR-open
 time asserts work that hasn't landed, and a reviewer looking at the inbox can't tell the difference.
 Manual resolve is for fixes a PR merge will never cover — a skill-body change, a config change, a
 `NO_REPO` report — see the workflow below.
@@ -488,12 +527,12 @@ inbox-source-configs-partial-update
 - `suppressed` reports are excluded by default; pass `status: "suppressed"` explicitly if the
   user wants to see hidden items
 - The inbox writes exposed via MCP are `inbox-reports-set-state` (resolve / dismiss / snooze one
-  report), `inbox-reports-bulk-set-state` (the same for 1–100 reports), and
+  report), `inbox-reports-bulk-set-state` (the same for 1–100 reports), `inbox-reports-claim`
+  (claim / release / attach a PR), and
   `inbox-source-configs-partial-update` (toggle a source's `enabled` flag). To _act_ on a report
-  (implement a fix), verify the diagnosis against the code first, then open a PR — see
+  (implement a fix), claim it, verify the diagnosis against the code, then open and attach a PR — see
   _Workflow: act on an actionable report_. A PR-backed fix is resolved automatically when the PR
-  merges, so don't resolve it by hand at PR-open time; setting `implementation_pr_url` happens on
-  the product surface, not via MCP. Always also surface the `_posthogUrl` deep-link
+  merges, so don't resolve it by hand at PR-open time. Always also surface the `_posthogUrl` deep-link
 - **Never implement a report's fix straight from its `summary`.** Reports — especially
   `signals_scout` ones — are LLM diagnoses; confirm the cited files / functions / behavior in the
   actual code before writing a fix. A report that doesn't hold up is a dismissal candidate, not a
diff --git a/skills/instrument-error-tracking/references/flutter.md b/skills/instrument-error-tracking/references/flutter.md
index 388ea1c..28c550f 100644
--- a/skills/instrument-error-tracking/references/flutter.md
+++ b/skills/instrument-error-tracking/references/flutter.md
@@ -108,7 +108,7 @@ Copy page
       <head>
         ...
         <script>
-          !function(t,e){var o,n,p,r;e.__SV||(window.posthog && window.posthog.__loaded)||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}p||((p=t.createElement("script")).type="text/javascript",p.crossOrigin="anonymous",p.async=!0,p.src=s.api_host.replace(".i.posthog.com","-assets.i.posthog.com")+"/static/array.js",p.onerror=function(){p=null},(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r));var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],u.toString=function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e},u.people.toString=function(){return u.toString(1)+".people (stub)"},o="init capture register register_once register_for_session unregister opt_out_capturing has_opted_out_capturing opt_in_capturing reset isFeatureEnabled getFeatureFlag getFeatureFlagPayload reloadFeatureFlags group identify setPersonProperties setPersonPropertiesForFlags resetPersonPropertiesForFlags setGroupPropertiesForFlags resetGroupPropertiesForFlags resetGroups onFeatureFlags addFeatureFlagsHandler onSessionId getSurveys getActiveMatchingSurveys renderSurvey canRenderSurvey getNextSurveyStep".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
+          !function(t,e){var o,n,p,r;e.__SV||(window.posthog && window.posthog.__loaded)||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}p||((p=t.createElement("script")).type="text/javascript",p.crossOrigin="anonymous",p.async=!0,p.src=s.api_host.replace(".i.posthog.com","-assets.i.posthog.com")+"/static/array.js",p.onerror=function(){p=null},(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r));var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],Object.defineProperty(u,"toString",{configurable:!0,enumerable:!0,writable:!0,value:function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e}}),Object.defineProperty(u.people,"toString",{configurable:!0,enumerable:!0,writable:!0,value:function(){return u.toString(1)+".people (stub)"}}),o="init capture register register_once register_for_session unregister opt_out_capturing has_opted_out_capturing opt_in_capturing reset isFeatureEnabled getFeatureFlag getFeatureFlagPayload reloadFeatureFlags group identify setPersonProperties setPersonPropertiesForFlags resetPersonPropertiesForFlags setGroupPropertiesForFlags resetGroupPropertiesForFlags resetGroups onFeatureFlags addFeatureFlagsHandler onSessionId getSurveys getActiveMatchingSurveys renderSurvey canRenderSurvey getNextSurveyStep".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
           posthog.init('<ph_project_token>', {
               api_host: 'https://us.i.posthog.com',
               defaults: '2026-05-30',
diff --git a/skills/instrument-error-tracking/references/web.md b/skills/instrument-error-tracking/references/web.md
index 7493f78..ba607c6 100644
--- a/skills/instrument-error-tracking/references/web.md
+++ b/skills/instrument-error-tracking/references/web.md
@@ -24,7 +24,7 @@ Copy page
 
     ```html
     <script>
-        !function(t,e){var o,n,p,r;e.__SV||(window.posthog && window.posthog.__loaded)||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}p||((p=t.createElement("script")).type="text/javascript",p.crossOrigin="anonymous",p.async=!0,p.src=s.api_host.replace(".i.posthog.com","-assets.i.posthog.com")+"/static/array.js",p.onerror=function(){p=null},(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r));var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],u.toString=function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e},u.people.toString=function(){return u.toString(1)+".people (stub)"},o="init capture register register_once register_for_session unregister unregister_for_session getFeatureFlag getFeatureFlagResult isFeatureEnabled reloadFeatureFlags updateEarlyAccessFeatureEnrollment getEarlyAccessFeatures on onFeatureFlags onSessionId getSurveys getActiveMatchingSurveys renderSurvey canRenderSurvey getNextSurveyStep identify setPersonProperties group resetGroups setPersonPropertiesForFlags resetPersonPropertiesForFlags setGroupPropertiesForFlags resetGroupPropertiesForFlags reset get_distinct_id getGroups get_session_id get_session_replay_url alias set_config startSessionRecording stopSessionRecording sessionRecordingStarted captureException loadToolbar get_property getSessionProperty createPersonProfile opt_in_capturing opt_out_capturing has_opted_in_capturing has_opted_out_capturing clear_opt_in_out_capturing debug".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
+        !function(t,e){var o,n,p,r;e.__SV||(window.posthog && window.posthog.__loaded)||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}p||((p=t.createElement("script")).type="text/javascript",p.crossOrigin="anonymous",p.async=!0,p.src=s.api_host.replace(".i.posthog.com","-assets.i.posthog.com")+"/static/array.js",p.onerror=function(){p=null},(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r));var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],Object.defineProperty(u,"toString",{configurable:!0,enumerable:!0,writable:!0,value:function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e}}),Object.defineProperty(u.people,"toString",{configurable:!0,enumerable:!0,writable:!0,value:function(){return u.toString(1)+".people (stub)"}}),o="init capture register register_once register_for_session unregister unregister_for_session getFeatureFlag getFeatureFlagResult isFeatureEnabled reloadFeatureFlags updateEarlyAccessFeatureEnrollment getEarlyAccessFeatures on onFeatureFlags onSessionId getSurveys getActiveMatchingSurveys renderSurvey canRenderSurvey getNextSurveyStep identify setPersonProperties group resetGroups setPersonPropertiesForFlags resetPersonPropertiesForFlags setGroupPropertiesForFlags resetGroupPropertiesForFlags reset get_distinct_id getGroups get_session_id get_session_replay_url alias set_config startSessionRecording stopSessionRecording sessionRecordingStarted captureException loadToolbar get_property getSessionProperty createPersonProfile opt_in_capturing opt_out_capturing has_opted_in_capturing has_opted_out_capturing clear_opt_in_out_capturing debug".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
         posthog.init('<ph_project_token>', {
             api_host: 'https://us.i.posthog.com',
             defaults: '2026-05-30',
diff --git a/skills/instrument-feature-flags/references/flutter.md b/skills/instrument-feature-flags/references/flutter.md
index e9db83b..db9e679 100644
--- a/skills/instrument-feature-flags/references/flutter.md
+++ b/skills/instrument-feature-flags/references/flutter.md
@@ -108,7 +108,7 @@ Copy page
       <head>
         ...
         <script>
-          !function(t,e){var o,n,p,r;e.__SV||(window.posthog && window.posthog.__loaded)||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}p||((p=t.createElement("script")).type="text/javascript",p.crossOrigin="anonymous",p.async=!0,p.src=s.api_host.replace(".i.posthog.com","-assets.i.posthog.com")+"/static/array.js",p.onerror=function(){p=null},(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r));var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],u.toString=function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e},u.people.toString=function(){return u.toString(1)+".people (stub)"},o="init capture register register_once register_for_session unregister opt_out_capturing has_opted_out_capturing opt_in_capturing reset isFeatureEnabled getFeatureFlag getFeatureFlagPayload reloadFeatureFlags group identify setPersonProperties setPersonPropertiesForFlags resetPersonPropertiesForFlags setGroupPropertiesForFlags resetGroupPropertiesForFlags resetGroups onFeatureFlags addFeatureFlagsHandler onSessionId getSurveys getActiveMatchingSurveys renderSurvey canRenderSurvey getNextSurveyStep".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
+          !function(t,e){var o,n,p,r;e.__SV||(window.posthog && window.posthog.__loaded)||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}p||((p=t.createElement("script")).type="text/javascript",p.crossOrigin="anonymous",p.async=!0,p.src=s.api_host.replace(".i.posthog.com","-assets.i.posthog.com")+"/static/array.js",p.onerror=function(){p=null},(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r));var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],Object.defineProperty(u,"toString",{configurable:!0,enumerable:!0,writable:!0,value:function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e}}),Object.defineProperty(u.people,"toString",{configurable:!0,enumerable:!0,writable:!0,value:function(){return u.toString(1)+".people (stub)"}}),o="init capture register register_once register_for_session unregister opt_out_capturing has_opted_out_capturing opt_in_capturing reset isFeatureEnabled getFeatureFlag getFeatureFlagPayload reloadFeatureFlags group identify setPersonProperties setPersonPropertiesForFlags resetPersonPropertiesForFlags setGroupPropertiesForFlags resetGroupPropertiesForFlags resetGroups onFeatureFlags addFeatureFlagsHandler onSessionId getSurveys getActiveMatchingSurveys renderSurvey canRenderSurvey getNextSurveyStep".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
           posthog.init('<ph_project_token>', {
               api_host: 'https://us.i.posthog.com',
               defaults: '2026-05-30',
diff --git a/skills/instrument-feature-flags/references/web.md b/skills/instrument-feature-flags/references/web.md
index c1eb3e9..f6452eb 100644
--- a/skills/instrument-feature-flags/references/web.md
+++ b/skills/instrument-feature-flags/references/web.md
@@ -24,7 +24,7 @@ Copy page
 
     ```html
     <script>
-        !function(t,e){var o,n,p,r;e.__SV||(window.posthog && window.posthog.__loaded)||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}p||((p=t.createElement("script")).type="text/javascript",p.crossOrigin="anonymous",p.async=!0,p.src=s.api_host.replace(".i.posthog.com","-assets.i.posthog.com")+"/static/array.js",p.onerror=function(){p=null},(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r));var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],u.toString=function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e},u.people.toString=function(){return u.toString(1)+".people (stub)"},o="init capture register register_once register_for_session unregister unregister_for_session getFeatureFlag getFeatureFlagResult isFeatureEnabled reloadFeatureFlags updateEarlyAccessFeatureEnrollment getEarlyAccessFeatures on onFeatureFlags onSessionId getSurveys getActiveMatchingSurveys renderSurvey canRenderSurvey getNextSurveyStep identify setPersonProperties group resetGroups setPersonPropertiesForFlags resetPersonPropertiesForFlags setGroupPropertiesForFlags resetGroupPropertiesForFlags reset get_distinct_id getGroups get_session_id get_session_replay_url alias set_config startSessionRecording stopSessionRecording sessionRecordingStarted captureException loadToolbar get_property getSessionProperty createPersonProfile opt_in_capturing opt_out_capturing has_opted_in_capturing has_opted_out_capturing clear_opt_in_out_capturing debug".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
+        !function(t,e){var o,n,p,r;e.__SV||(window.posthog && window.posthog.__loaded)||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}p||((p=t.createElement("script")).type="text/javascript",p.crossOrigin="anonymous",p.async=!0,p.src=s.api_host.replace(".i.posthog.com","-assets.i.posthog.com")+"/static/array.js",p.onerror=function(){p=null},(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r));var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],Object.defineProperty(u,"toString",{configurable:!0,enumerable:!0,writable:!0,value:function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e}}),Object.defineProperty(u.people,"toString",{configurable:!0,enumerable:!0,writable:!0,value:function(){return u.toString(1)+".people (stub)"}}),o="init capture register register_once register_for_session unregister unregister_for_session getFeatureFlag getFeatureFlagResult isFeatureEnabled reloadFeatureFlags updateEarlyAccessFeatureEnrollment getEarlyAccessFeatures on onFeatureFlags onSessionId getSurveys getActiveMatchingSurveys renderSurvey canRenderSurvey getNextSurveyStep identify setPersonProperties group resetGroups setPersonPropertiesForFlags resetPersonPropertiesForFlags setGroupPropertiesForFlags resetGroupPropertiesForFlags reset get_distinct_id getGroups get_session_id get_session_replay_url alias set_config startSessionRecording stopSessionRecording sessionRecordingStarted captureException loadToolbar get_property getSessionProperty createPersonProfile opt_in_capturing opt_out_capturing has_opted_in_capturing has_opted_out_capturing clear_opt_in_out_capturing debug".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
         posthog.init('<ph_project_token>', {
             api_host: 'https://us.i.posthog.com',
             defaults: '2026-05-30',
diff --git a/skills/instrument-integration/references/posthog-js.md b/skills/instrument-integration/references/posthog-js.md
index c6ac710..b827d51 100644
--- a/skills/instrument-integration/references/posthog-js.md
+++ b/skills/instrument-integration/references/posthog-js.md
@@ -171,7 +171,7 @@ Set HMAC-based identity verification.
 
 **Notes:**
 
-When set, products like conversations use server-verified identity (distinct_id + HMAC hash) instead of anonymous session identifiers. The hash should be computed server-side as HMAC-SHA256 of the distinct_id using the project's API secret.
+When set, products like conversations use server-verified identity (distinct_id + HMAC hash) instead of anonymous session identifiers. The hash should be computed server-side as HMAC-SHA256 of the distinct_id using the project's API secret. Any additional signed identity claims are cleared because they are bound to the previously configured distinct_id.
 
 ### Parameters
 
@@ -553,7 +553,7 @@ By default, PostHog assigns each user a randomly generated `distinct_id`. Use th
 
 ### Parameters
 
-- **`new_distinct_id?`** (`string`) - A string that uniquely identifies a user. If not provided, the distinct_id currently in the persistent store (cookie or localStorage) will be used.
+- **`new_distinct_id`** (`string`) - A non-empty string that uniquely identifies a user.
 - **`userPropertiesToSet?`** (`Properties`) - Optional: An associative array of properties to store about the user. Note: For feature flag evaluations, if the same key is present in the userPropertiesToSetOnce, it will be overwritten by the value in userPropertiesToSet.
 - **`userPropertiesToSetOnce?`** (`Properties`) - Optional: An associative array of properties to store about the user. If property is previously set, this does not override that value.
 
diff --git a/skills/instrument-llm-analytics/references/anthropic.md b/skills/instrument-llm-analytics/references/anthropic.md
index 03f3c85..32c6099 100644
--- a/skills/instrument-llm-analytics/references/anthropic.md
+++ b/skills/instrument-llm-analytics/references/anthropic.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node @anthropic-ai/sdk
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/azure-openai.md b/skills/instrument-llm-analytics/references/azure-openai.md
index 00a3d72..264dae5 100644
--- a/skills/instrument-llm-analytics/references/azure-openai.md
+++ b/skills/instrument-llm-analytics/references/azure-openai.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/cerebras.md b/skills/instrument-llm-analytics/references/cerebras.md
index c5b9574..349b628 100644
--- a/skills/instrument-llm-analytics/references/cerebras.md
+++ b/skills/instrument-llm-analytics/references/cerebras.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/cohere.md b/skills/instrument-llm-analytics/references/cohere.md
index 1afe2fb..f6dc9b6 100644
--- a/skills/instrument-llm-analytics/references/cohere.md
+++ b/skills/instrument-llm-analytics/references/cohere.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/deepseek.md b/skills/instrument-llm-analytics/references/deepseek.md
index f4c60a7..48ee129 100644
--- a/skills/instrument-llm-analytics/references/deepseek.md
+++ b/skills/instrument-llm-analytics/references/deepseek.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/fireworks-ai.md b/skills/instrument-llm-analytics/references/fireworks-ai.md
index 2750cbf..fe73558 100644
--- a/skills/instrument-llm-analytics/references/fireworks-ai.md
+++ b/skills/instrument-llm-analytics/references/fireworks-ai.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/google.md b/skills/instrument-llm-analytics/references/google.md
index 1a50338..5682f60 100644
--- a/skills/instrument-llm-analytics/references/google.md
+++ b/skills/instrument-llm-analytics/references/google.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node @google/genai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/groq.md b/skills/instrument-llm-analytics/references/groq.md
index 183b566..6166ad5 100644
--- a/skills/instrument-llm-analytics/references/groq.md
+++ b/skills/instrument-llm-analytics/references/groq.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/helicone.md b/skills/instrument-llm-analytics/references/helicone.md
index f9eac9e..fd4a48d 100644
--- a/skills/instrument-llm-analytics/references/helicone.md
+++ b/skills/instrument-llm-analytics/references/helicone.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/hugging-face.md b/skills/instrument-llm-analytics/references/hugging-face.md
index b4bb818..049d521 100644
--- a/skills/instrument-llm-analytics/references/hugging-face.md
+++ b/skills/instrument-llm-analytics/references/hugging-face.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/mistral.md b/skills/instrument-llm-analytics/references/mistral.md
index 3e83a27..66b8bfd 100644
--- a/skills/instrument-llm-analytics/references/mistral.md
+++ b/skills/instrument-llm-analytics/references/mistral.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/ollama.md b/skills/instrument-llm-analytics/references/ollama.md
index 2c5cb28..d57d7df 100644
--- a/skills/instrument-llm-analytics/references/ollama.md
+++ b/skills/instrument-llm-analytics/references/ollama.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/openai.md b/skills/instrument-llm-analytics/references/openai.md
index 20d8255..43ab433 100644
--- a/skills/instrument-llm-analytics/references/openai.md
+++ b/skills/instrument-llm-analytics/references/openai.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/openrouter.md b/skills/instrument-llm-analytics/references/openrouter.md
index a585e11..88dc3d6 100644
--- a/skills/instrument-llm-analytics/references/openrouter.md
+++ b/skills/instrument-llm-analytics/references/openrouter.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/perplexity.md b/skills/instrument-llm-analytics/references/perplexity.md
index 3bdd086..7e6bd00 100644
--- a/skills/instrument-llm-analytics/references/perplexity.md
+++ b/skills/instrument-llm-analytics/references/perplexity.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/together-ai.md b/skills/instrument-llm-analytics/references/together-ai.md
index 50d7e43..2a5da29 100644
--- a/skills/instrument-llm-analytics/references/together-ai.md
+++ b/skills/instrument-llm-analytics/references/together-ai.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-llm-analytics/references/xai.md b/skills/instrument-llm-analytics/references/xai.md
index f2ec01d..f52b4f0 100644
--- a/skills/instrument-llm-analytics/references/xai.md
+++ b/skills/instrument-llm-analytics/references/xai.md
@@ -48,6 +48,12 @@ Skip the manual setup — run this in your project and the wizard installs the S
     npm install @posthog/ai posthog-node openai
     ```
 
+    ### Go
+
+    ```prose
+    PostHog doesn't have a Go wrapper for this SDK yet. Use the [OpenTelemetry integration](https://posthog.com/docs/ai-observability/installation/opentelemetry) instead.
+    ```
+
 2.  2
 
     ## Configure PostHog
diff --git a/skills/instrument-logs/references/best-practices.md b/skills/instrument-logs/references/best-practices.md
index d34c167..e3d6242 100644
--- a/skills/instrument-logs/references/best-practices.md
+++ b/skills/instrument-logs/references/best-practices.md
@@ -334,6 +334,8 @@ Match rules by service name, severity, or any log attribute. Rules run top to bo
 
 Because drop rules apply before storage, they're the fastest way to cut volume without shipping a code change. Pair them with the client-side practices above: sample at the source where you can, and use drop rules to catch the noise you can't.
 
+If you still want the trend from the lines you drop, add a [log-based metric](/docs/logs/metrics.md) first. Metric rules are evaluated before drop rules, so the count survives even though the logs don't.
+
 ## Add trace and session context
 
 Isolated logs are hard to correlate. Adding trace IDs and session IDs connects individual log events to the broader request journey.
diff --git a/skills/instrument-metrics/references/architecture.md b/skills/instrument-metrics/references/architecture.md
index 11244ee..67c0812 100644
--- a/skills/instrument-metrics/references/architecture.md
+++ b/skills/instrument-metrics/references/architecture.md
@@ -16,6 +16,8 @@ Metrics arrive over the OpenTelemetry Protocol (OTLP) via HTTP at `/i/v1/metrics
 
 Each incoming data point carries a metric name, a metric type, a value (or histogram buckets), a timestamp, resource attributes describing the sender (service name, host), and data point attributes describing the measurement (route, status). Ingestion validates the payload, applies your project's quota, and writes data points to a columnar time series store.
 
+Not every metric arrives over OTLP. A [log-based metric](/docs/logs/metrics.md) is generated at ingestion from your logs: log lines matching a rule are tallied as they arrive and emitted as a metric into the same store, so it shows up in the metrics viewer like any instrumented metric.
+
 ## The series model
 
 A **series** is one stream of values identified by the combination of:
@@ -49,6 +51,13 @@ Filters match attribute values with equality, negation, or regular expressions,
 
 Through the query API you can also combine multiple metrics with a formula, for example an error ratio computed as `errors / requests`, evaluated server side on the shared grid.
 
+## Anomaly detection and samples
+
+Two more things sit between storage and the chart:
+
+-   **Anomaly detection.** When you chart a metric, PostHog compares the most recent slice of the window against a baseline and, if they differ statistically, finds the onset and ranks which label values drove the move. That powers the anomaly badge and biggest-movers panel in the [viewer](/docs/metrics/explore.md).
+-   **Raw samples.** Alongside the aggregated series, PostHog keeps the individual emissions. The Samples view in the viewer reads these to show the exact data points behind a chart, and to link each one to the trace it was recorded in when trace context is present.
+
 ## Storage and SQL access
 
 Metrics are stored in a columnar time series table and exposed to SQL as `posthog.metrics`, scoped to your project like every other PostHog table. The SQL tab in the metrics viewer is a full escape hatch: anything the chart controls can't express, you can write directly, and join against the rest of your PostHog data.
diff --git a/skills/instrument-metrics/references/basics.md b/skills/instrument-metrics/references/basics.md
index f637b7c..5bdff04 100644
--- a/skills/instrument-metrics/references/basics.md
+++ b/skills/instrument-metrics/references/basics.md
@@ -46,7 +46,7 @@ The same goes for error budgets and latency. A `rate` on an error counter divide
 
 Most teams keep metrics in a separate system from everything else, so answering "did that latency spike affect signups?" means tab switching and timestamp matching. In PostHog, metrics live alongside your [logs](/docs/logs.md), [traces](/docs/distributed-tracing.md), product analytics, and session replays, in the same project with the same query language.
 
-Everything is queryable as SQL through the `posthog.metrics` table, and the [PostHog MCP server](/docs/model-context-protocol.md) exposes metrics to AI agents, so your tools can chart, compare, and investigate metrics for you.
+Everything is queryable as SQL through the `posthog.metrics` table, and the [PostHog MCP server](/docs/model-context-protocol.md) exposes metrics to AI agents, so your tools can chart, compare, and investigate metrics for you. When you chart a metric that has moved against its baseline, an anomaly badge surfaces the change and the label values behind it, and the raw samples stay linked to the logs and traces that explain them.
 
 ## Next steps
 
diff --git a/skills/instrument-metrics/references/start-here.md b/skills/instrument-metrics/references/start-here.md
index 8056ac6..15f1162 100644
--- a/skills/instrument-metrics/references/start-here.md
+++ b/skills/instrument-metrics/references/start-here.md
@@ -71,7 +71,7 @@ If you need to know what happened for one specific user or request, that's a job
 
 ## Verify metrics are arriving
 
-Open **Metrics** in the PostHog sidebar. Pick your metric from the name picker and you should see data points within a minute of sending. The viewer recommends an aggregation based on the metric's type, so a counter defaults to `increase` and a gauge to `avg`.
+Open **Metrics** in the PostHog sidebar. The **Overview** tab shows your services, metric names, and active series over the last day, so you can confirm data is landing. In the **Viewer** tab, pick your metric from the name picker and you should see data points within a minute of sending. The viewer recommends an aggregation based on the metric's type, so a counter defaults to `increase` and a gauge to `avg`.
 
 If nothing shows up, check that the endpoint ends in `/i/v1/metrics`, that the token starts with `phc_`, and see the [troubleshooting section](/docs/metrics.md#troubleshooting).
 
@@ -81,15 +81,19 @@ Once data flows, build the views you'll actually watch:
 
 -   **Group by** an attribute to get one line per value, for example request rate per route or queue depth per worker.
 -   **Filter** with `key=value` chips to focus on one service, environment, or status.
--   Switch to **stat mode** for a single headline number with an automatic comparison against the baseline.
--   Turn on **live** to refresh the chart every few seconds while you watch a deploy or an incident.
+-   Watch for the **anomaly badge** — when the metric moves against its baseline, it shows the change and the label values that drove it.
+-   Turn on **auto-refresh** to update the chart every few seconds while you watch a deploy or an incident.
+
+When a chart is worth keeping, **save it as an insight** or add it to a dashboard — or use **New service dashboard** to build one insight per metric in a single step.
 
 ## Query with SQL or ask AI
 
-Every metric lands in the `posthog.metrics` table, so the SQL tab in the metrics viewer gives you full query access for anything the chart controls don't cover.
+Every metric lands in the `posthog.metrics` table, so the **SQL** tab in the metrics viewer gives you full query access for anything the chart controls don't cover.
 
 If you use the [PostHog MCP server](/docs/model-context-protocol.md), your AI tools can query metrics directly: ask your agent to chart a metric, compare error rates between services, or characterize an anomaly, all without leaving your editor.
 
+For the full tour of the viewer — anomaly detection, pivoting into logs and traces, and dashboards — see [Use your metrics](/docs/metrics/explore.md).
+
 1/6
 
 [**Send your first metrics** ***Required***](#quest-item-send-your-first-metrics)[**Pick the right metric type** ***Required***](#quest-item-pick-the-right-metric-type)[**Add attributes, carefully** ***Required***](#quest-item-add-attributes-carefully)[**Verify metrics are arriving** ***Required***](#quest-item-verify-metrics-are-arriving)[**Chart what matters** ***Recommended***](#quest-item-chart-what-matters)[**Query with SQL or ask AI** ***Optional***](#quest-item-query-with-sql-or-ask-ai)
diff --git a/skills/managing-experiment-lifecycle/SKILL.md b/skills/managing-experiment-lifecycle/SKILL.md
index 5b6dff5..d349e1d 100644
--- a/skills/managing-experiment-lifecycle/SKILL.md
+++ b/skills/managing-experiment-lifecycle/SKILL.md
@@ -142,6 +142,17 @@ Required: `variant_key` (e.g. "test"). Optional: `conclusion`, `conclusion_comme
 
 Returns 409 if an approval policy requires review before the flag change.
 
+### Flag cleanup PR (option on end and ship variant)
+
+Both `experiment-end` and `experiment-ship-variant` accept `open_cleanup_pr: true`.
+A background PostHog Code task then removes the experiment's feature flag code and opens a draft pull request in the team's connected GitHub repository.
+
+- Only set this when the user asks for it or confirms it.
+- The key must carry the `task:write` scope, or the whole request is rejected with a 403 and the experiment is not ended or shipped.
+- The cleanup runs only when the call actually ends the experiment and a `conclusion` is set — shipping an already-stopped experiment, or ending without a conclusion, skips it. It also requires the team to have the flag cleanup feature enabled; silently skipped when it isn't.
+- `repository` ("organization/repository") picks the target when several repositories are connected. Omit it to fall back to the experiment's saved repository, the team default, or the only connected repository. With several candidates and no default, the cleanup is skipped unless provided.
+- Track progress with `experiment-cleanup-task` — the PR URL appears there once opened; a cleanup typically takes several minutes.
+
 ### Archive (`experiment-archive`)
 
 Hides a stopped experiment from the default list view.
diff --git a/skills/querying-posthog-data/SKILL.md b/skills/querying-posthog-data/SKILL.md
index bba5253..146fa4a 100644
--- a/skills/querying-posthog-data/SKILL.md
+++ b/skills/querying-posthog-data/SKILL.md
@@ -43,7 +43,7 @@ When the user asks for a governed business or telemetry measure (MRR, activation
    Create it only after the user says yes, with `posthog:data-catalog-metric-create`; when the definition came from a saved insight, pass that insight's `source_insight_short_id` instead of copying its query.
    Never offer for a one-off exploration or debugging aggregate, and never after an unknown-table error: a project with no data catalog has no `posthog:data-catalog-metric-create` either.
 
-Curating the catalog — creating or approving metrics, certifying sources, reviewing the proposal queue — is a separate job covered by the `setting-up-data-catalog` skill. If you notice a clearly load-bearing or stale table while deriving, that skill covers proposing a trust mark on it. Everything an agent proposes lands unapproved for a human to promote, so never present a proposal as canonical.
+Curating the catalog — creating, approving, or retiring metrics, certifying sources, reviewing the proposal queue — is a separate job covered by the `setting-up-data-catalog` skill. If you notice a clearly load-bearing or stale table while deriving, that skill covers proposing a trust mark on it. Everything an agent proposes lands unapproved for a human to promote, so never present a proposal as canonical.
 
 ## Data Schema
 
diff --git a/skills/querying-posthog-data/references/example-error-tracking.md b/skills/querying-posthog-data/references/example-error-tracking.md
index 1d79a2b..9320d73 100644
--- a/skills/querying-posthog-data/references/example-error-tracking.md
+++ b/skills/querying-posthog-data/references/example-error-tracking.md
@@ -25,14 +25,14 @@ FROM
         argMaxState(properties.$exception_functions.-1, timestamp) AS function_state,
         argMaxState(properties.$exception_sources.-1, timestamp) AS source_state,
         argMaxState(properties.$lib, timestamp) AS library_state,
-        least(19, intDiv(dateDiff('seconds', toDateTime(toDateTime('2026-09-02 11:00:00.000000')), timestamp), greatest(1, intDiv(dateDiff('seconds', toDateTime(toDateTime('2026-09-02 11:00:00.000000')), toDateTime(toDateTime('2026-09-03 11:46:01.108567'))), 20)))) AS bin_idx,
+        least(19, intDiv(dateDiff('seconds', toDateTime(toDateTime('2026-09-05 09:00:00.000000')), timestamp), greatest(1, intDiv(dateDiff('seconds', toDateTime(toDateTime('2026-09-05 09:00:00.000000')), toDateTime(toDateTime('2026-09-06 09:19:14.282325'))), 20)))) AS bin_idx,
         count() AS occ,
         uniqState(nullIf(e.$session_id, '')) AS sessions_state,
         uniqState(coalesce(nullIf(toString(e.event_person_id), '00000000-0000-0000-0000-000000000000'), e.distinct_id)) AS users_state
     FROM
         events AS e
     WHERE
-        and(equals(e.event, '$exception'), isNotNull(e.properties.$exception_fingerprint), true, greaterOrEquals(e.timestamp, toDateTime(toDateTime('2026-09-02 11:00:00.000000'))), lessOrEquals(e.timestamp, toDateTime(toDateTime('2026-09-03 11:46:01.108567'))), or(greater(position(lower(e.properties.$exception_types), lower('constant')), 0), greater(position(lower(e.properties.$exception_values), lower('constant')), 0), greater(position(lower(e.properties.$exception_sources), lower('constant')), 0), greater(position(lower(e.properties.$exception_functions), lower('constant')), 0), greater(position(lower(e.properties.email), lower('constant')), 0), greater(position(lower(e.person.properties.email), lower('constant')), 0)), equals(properties.tag, 'max_ai'))
+        and(equals(e.event, '$exception'), isNotNull(e.properties.$exception_fingerprint), true, greaterOrEquals(e.timestamp, toDateTime(toDateTime('2026-09-05 09:00:00.000000'))), lessOrEquals(e.timestamp, toDateTime(toDateTime('2026-09-06 09:19:14.282325'))), or(greater(position(lower(e.properties.$exception_types), lower('constant')), 0), greater(position(lower(e.properties.$exception_values), lower('constant')), 0), greater(position(lower(e.properties.$exception_sources), lower('constant')), 0), greater(position(lower(e.properties.$exception_functions), lower('constant')), 0), greater(position(lower(e.properties.email), lower('constant')), 0), greater(position(lower(e.person.properties.email), lower('constant')), 0)), equals(properties.tag, 'max_ai'))
     GROUP BY
         fp_hash,
         bin_idx) AS ev
diff --git a/skills/querying-posthog-data/references/example-logs.md b/skills/querying-posthog-data/references/example-logs.md
index bd0e57c..bbac59f 100644
--- a/skills/querying-posthog-data/references/example-logs.md
+++ b/skills/querying-posthog-data/references/example-logs.md
@@ -31,7 +31,7 @@ SELECT
 FROM
     logs
 WHERE
-    and(and(greaterOrEquals(toStartOfDay(time_bucket), toStartOfDay(assumeNotNull(toDateTime('2025-12-09 00:00:00')))), lessOrEquals(toStartOfDay(time_bucket), toStartOfDay(assumeNotNull(toDateTime('2025-12-10 00:00:00'))))), 1, greaterOrEquals(timestamp, toDateTime('2026-09-02 11:46:01.788447')), indexHint(like(lower(body), '%timeout%')), ilike(toString(body), '%timeout%'), in(severity_text, tuple('warn', 'error', 'fatal')))
+    and(and(greaterOrEquals(toStartOfDay(time_bucket), toStartOfDay(assumeNotNull(toDateTime('2025-12-09 00:00:00')))), lessOrEquals(toStartOfDay(time_bucket), toStartOfDay(assumeNotNull(toDateTime('2025-12-10 00:00:00'))))), 1, greaterOrEquals(timestamp, toDateTime('2026-09-05 09:19:15.045917')), indexHint(like(lower(body), '%timeout%')), ilike(toString(body), '%timeout%'), in(severity_text, tuple('warn', 'error', 'fatal')))
 ORDER BY
     timestamp DESC,
     uuid DESC
diff --git a/skills/querying-posthog-data/references/example-session-replay.md b/skills/querying-posthog-data/references/example-session-replay.md
index 0e79ed4..b806cd4 100644
--- a/skills/querying-posthog-data/references/example-session-replay.md
+++ b/skills/querying-posthog-data/references/example-session-replay.md
@@ -19,18 +19,18 @@ SELECT
     sum(s.console_error_count) AS console_error_count,
     max(s.retention_period_days) AS retention_period_days,
     plus(dateTrunc('DAY', start_time), toIntervalDay(coalesce(retention_period_days, 30))) AS expiry_time,
-    date_diff('DAY', toDateTime('2026-09-03 11:46:01.975713'), expiry_time) AS recording_ttl,
-    greaterOrEquals(max(s._timestamp), toDateTime('2026-09-03 11:41:01.975313')) AS ongoing,
+    date_diff('DAY', toDateTime('2026-09-06 09:19:15.327807'), expiry_time) AS recording_ttl,
+    greaterOrEquals(max(s._timestamp), toDateTime('2026-09-06 09:14:15.327300')) AS ongoing,
     round(least(greatest(multiply(divide(plus(plus(plus(divide(sum(s.active_milliseconds), 1000), sum(s.click_count)), sum(s.keypress_count)), sum(s.console_error_count)), plus(plus(plus(plus(sum(s.mouse_activity_count), dateDiff('SECOND', start_time, end_time)), sum(s.console_error_count)), sum(s.console_log_count)), sum(s.console_warn_count))), 100), 0), 100), 2) AS activity_score,
     coalesce(max(s.surfacing_score), 0.36) AS surfacing_score
 FROM
     raw_session_replay_events AS s
 WHERE
-    and(greaterOrEquals(s.min_first_timestamp, toDateTime('2026-08-31 00:00:00.000000')), lessOrEquals(s.min_first_timestamp, toDateTime('2026-09-03 11:46:01.975461')))
+    and(greaterOrEquals(s.min_first_timestamp, toDateTime('2026-09-03 00:00:00.000000')), lessOrEquals(s.min_first_timestamp, toDateTime('2026-09-06 09:19:15.327479')))
 GROUP BY
     session_id
 HAVING
-    and(greaterOrEquals(expiry_time, toDateTime('2026-09-03 11:46:01.975601')), equals(max(s.is_deleted), 0), greater(active_seconds, 5.0))
+    and(greaterOrEquals(expiry_time, toDateTime('2026-09-06 09:19:15.327704')), equals(max(s.is_deleted), 0), greater(active_seconds, 5.0))
 ORDER BY
     start_time DESC,
     session_id DESC
diff --git a/skills/querying-posthog-data/references/example-sessions.md b/skills/querying-posthog-data/references/example-sessions.md
index 5a1f700..9605623 100644
--- a/skills/querying-posthog-data/references/example-sessions.md
+++ b/skills/querying-posthog-data/references/example-sessions.md
@@ -13,7 +13,7 @@ SELECT
 FROM
     sessions
 WHERE
-    and(less($start_timestamp, toDateTime('2026-09-03 11:46:07.477242')), greater($start_timestamp, toDateTime('2026-09-02 11:46:02.477503')))
+    and(less($start_timestamp, toDateTime('2026-09-06 09:19:21.250701')), greater($start_timestamp, toDateTime('2026-09-05 09:19:16.251095')))
 ORDER BY
     $start_timestamp DESC
 LIMIT 50000
diff --git a/skills/resolving-ingestion-warnings/SKILL.md b/skills/resolving-ingestion-warnings/SKILL.md
index 32152cc..7f6f3c0 100644
--- a/skills/resolving-ingestion-warnings/SKILL.md
+++ b/skills/resolving-ingestion-warnings/SKILL.md
@@ -48,11 +48,13 @@ Those decisions come only from this skill's guidance and your own reasoning.
 
 ### Person merges (`merge`)
 
-| Type                                    | What happened                                                                                            | Fix                                                                                                                                                                                                                                         |
-| --------------------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `cannot_merge_already_identified`       | Merge refused: both persons are already identified. The accounts silently stayed separate                | Read [references/fixing-cannot-merge-already-identified.md](references/fixing-cannot-merge-already-identified.md) — covers the identify/reset flow fixes; joining two identified users is a manual one-off decision, never application code |
-| `cannot_merge_with_illegal_distinct_id` | Merge refused: the distinct ID is a placeholder (`undefined`, `null`, `[object Object]`, `anonymous`, …) | Read [references/fixing-invalid-distinct-ids.md](references/fixing-invalid-distinct-ids.md) — a variable is unset at the identify/alias callsite                                                                                            |
-| `merge_race_condition`                  | Concurrent merges collided on the same persons; the operation was dropped                                | Read [references/fixing-merge-race-condition.md](references/fixing-merge-race-condition.md) — dedupe parallel identify calls, and check for a "mega person" merge magnet (thousands of distinct IDs on one person)                          |
+| Type                                    | What happened                                                                                               | Fix                                                                                                                                                                                                                                         |
+| --------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `cannot_merge_already_identified`       | Merge refused: both persons are already identified. The accounts silently stayed separate                   | Read [references/fixing-cannot-merge-already-identified.md](references/fixing-cannot-merge-already-identified.md) — covers the identify/reset flow fixes; joining two identified users is a manual one-off decision, never application code |
+| `cannot_merge_with_illegal_distinct_id` | Merge refused: the distinct ID is a placeholder (`undefined`, `null`, `[object Object]`, `anonymous`, …)    | Read [references/fixing-invalid-distinct-ids.md](references/fixing-invalid-distinct-ids.md) — a variable is unset at the identify/alias callsite                                                                                            |
+| `merge_race_condition`                  | Concurrent merges collided on the same persons; the operation was dropped                                   | Read [references/fixing-merge-race-condition.md](references/fixing-merge-race-condition.md) — dedupe parallel identify calls, and check for a "mega person" merge magnet (thousands of distinct IDs on one person)                          |
+| `merge_move_limit_exceeded`             | Merge dropped: the source person has more distinct IDs than one merge may move                              | A "mega person" merge magnet has accumulated thousands of distinct IDs. Same diagnosis as `merge_race_condition`: find the magnet and stop identifying against it                                                                           |
+| `merge_settled_failure`                 | The merge settled on a verdict that merged nothing, and the verdict is recorded so a retry cannot change it | Rare and not caller-fixable. Check whether the identity service is healthy; the accounts stay separate and a later identify under a fresh event uuid can still merge them                                                                   |
 
 ### Event validation (`event`)
 
diff --git a/skills/setting-up-data-catalog/SKILL.md b/skills/setting-up-data-catalog/SKILL.md
index df53975..eab9741 100644
--- a/skills/setting-up-data-catalog/SKILL.md
+++ b/skills/setting-up-data-catalog/SKILL.md
@@ -85,12 +85,18 @@ Work top-down, stopping at `proposed` for everything (a human promotes later):
 2. **Summarize each proposal with its evidence** (match rates, sample values, drift state) so a human
    can decide quickly.
 
-3. **On the human's instruction**, promote with the confirmed-action tools:
-   `posthog:data-catalog-metric-approve`, `posthog:data-catalog-certification-certify` / `-deprecate`,
-   `posthog:data-catalog-relationship-accept` / `-reject` (pass the `id` from the queue). A row proposed
-   with `proposed_status: 'deprecated'` is settled with `-deprecate`; the approver can reject that intent
-   by certifying instead, since `-deprecate` / `-certify` act on any non-deprecated row regardless of the
-   proposal's intent. A rejected relationship is suppressed forever, so only reject when the human is sure.
+3. **On the human's instruction**, promote with the confirmed-action tools. Each promotion is a two-step
+   tool: call the `-prepare` variant, surface the confirmation message it returns, wait for the user to
+   type the literal `confirm`, then call the matching `-execute` variant with the returned hash. The pairs
+   are `posthog:data-catalog-metric-approve-prepare` / `-execute`,
+   `posthog:data-catalog-certification-certify-prepare` / `-execute`,
+   `posthog:data-catalog-certification-deprecate-prepare` / `-execute`,
+   `posthog:data-catalog-relationship-accept-prepare` / `-execute`, and
+   `posthog:data-catalog-relationship-reject-prepare` / `-execute` (pass the `id` from the queue). A row
+   proposed with `proposed_status: 'deprecated'` is settled with the deprecate pair; the approver can
+   reject that intent by certifying instead, since deprecate and certify act on any non-deprecated row
+   regardless of the proposal's intent. A rejected relationship is suppressed forever, so only reject when
+   the human is sure.
 
 4. **Handle drift.** A metric with `is_drifted = true` has diverged from its source insight (or the
    insight is gone). It cannot be approved until the drift is cleared. Surface it for the human rather
@@ -102,6 +108,15 @@ Work top-down, stopping at `proposed` for everything (a human promotes later):
    The `refresh` parameter on `posthog:data-catalog-metric-run` is a query-cache mode, not a drift fix —
    it does not re-snapshot the linked insight.
 
+5. **Retire a metric that should not exist.** Delete with the signed confirmation flow:
+   `posthog:data-catalog-metric-delete-prepare`, then `posthog:data-catalog-metric-delete-execute`. Use it when the
+   metric duplicates another one, has been superseded, or measures something the team never wanted — not when it is
+   merely stale, wrongly defined, or badly named. For those, `posthog:data-catalog-metric-update` keeps the metric's
+   history and its `id`; `new_name` renames it in place. Surface the prepared message, wait for the human to reply with
+   the literal word `confirm`, then call execute with only the signed confirmation fields. Say what the delete costs:
+   an approved metric loses its human vouching, saved SQL and run URLs that name it stop resolving, and the freed name
+   may later be claimed by an unrelated metric, so a stored name is not a stable reference across a delete.
+
 ## Related
 
 Certifying a source says a human vouches for it. Proving it is _still_ correct is a separate job —
diff --git a/skills/signals-scout-ai-observability/SKILL.md b/skills/signals-scout-ai-observability/SKILL.md
index 31cfeb4..ce55e1f 100644
--- a/skills/signals-scout-ai-observability/SKILL.md
+++ b/skills/signals-scout-ai-observability/SKILL.md
@@ -84,7 +84,7 @@ Memory is a continuous activity, not an end-of-run wrap-up. Write a scratchpad e
 - key `pattern:llm_analytics:latency-bands` — _"Per-model p90: nano ~2s, sonnet ~19s, o3/preview structurally high ~40s+ — band per model, never aggregate."_
 - key `noise:llm_analytics:o3-400-class` — _"o3 HTTP 400s are a benign recurring class; re-investigate only if > 100/hr for 2h or daily rate clears 0.05%."_
 - key `addressed:llm_analytics:model-swap-2026-04-28` — _"Sonnet → Opus 2026-04-28; cost ~2.1x baseline expected."_
-- key `report:llm_analytics:<entity>` — the `report_id` of a report you authored for a regression on this slice (a model, `ai_product`, eval, or cluster), so the next run edits it (append_note with the fresh window) instead of duplicating.
+- key `report:llm_analytics:<entity>` — the `report_id` of a report you authored for a regression on this slice (a model, `ai_product`, eval, or cluster), so the next run edits it (`append_evidence` with the fresh window) instead of duplicating.
 - key `reviewer:llm_analytics:<area>` — a resolved owner (bare lowercase GitHub login) for a product / model / eval area, so reports route to a human faster.
 
 By run #5 you'll know the team's healthy baselines, which dimensions split usefully, which spikes recur, which evals deserve more or less weight, and who owns each surface.
@@ -93,7 +93,7 @@ By run #5 you'll know the team's healthy baselines, which dimensions split usefu
 
 Before you author, check whether this slice already has a report — the `report:llm_analytics:<entity>` scratchpad pointer is the reliable path: it holds the `report_id`, so `inbox-reports-retrieve` it directly. Only with no pointer fall back to an `inbox-reports-list` search (`ordering=-updated_at`), and search the slice's _specific_ terms (the model, the `ai_product`, the eval name, the cluster id) — a broad word like `latency` returns hundreds of unrelated reports on a busy project and buries yours. Then, for each candidate:
 
-- **Edit** the existing report via `scout-edit-report` when the inbox already covers the slice. A regression is rarely brand-new — a cost step that's still elevated, a latency band that hasn't recovered, an eval still failing more: `append_note` with the fresh window's numbers (or rewrite the title/summary on a report you authored). This is the default when a match exists **and it's still live in the inbox**; don't mint a near-duplicate. **A persistent regression is one report across runs:** when a new complete window confirms the issue is ongoing, that's a _re-escalation_ — `append_note` the fresh window onto the report your `report:llm_analytics:<entity>` pointer names and advance the `dedupe:` gate; do **not** author a fresh report per tick. **But check the matched report's status first:** `edit-report` can't change status, so appending to a `resolved` / `suppressed` / `failed` report (one that won't surface) buries a real relapse under a closed item. When the prior report is no longer live, **author a fresh report** for the relapse and repoint `report:llm_analytics:<entity>` at the new id.
+- **Edit** the existing report via `scout-edit-report` when the inbox already covers the slice. A regression is rarely brand-new — a cost step that's still elevated, a latency band that hasn't recovered, an eval still failing more: use `append_evidence` for the fresh window's numbers (or rewrite the title/summary on a report you authored). This is the default when a match exists **and it's still live in the inbox**; don't mint a near-duplicate. **A persistent regression is one report across runs:** when a new complete window confirms the issue is ongoing, that's a _re-escalation_ — add the fresh window to the report with `append_evidence`, and advance the `dedupe:` gate. Do **not** author a fresh report per tick. **But check the matched report's status first:** `edit-report` can't change status, so appending to a `resolved` / `suppressed` / `failed` report (one that won't surface) buries a real relapse under a closed item. When the prior report is no longer live, **author a fresh report** for the relapse and repoint `report:llm_analytics:<entity>` at the new id.
 - **Author** a fresh report via `scout-emit-report` only when nothing live in the inbox covers it. New evidence on a regression an existing report already tracks is an **edit**, not a new report — `emit-report` is for a genuinely uncovered slice (or a relapse whose prior report is no longer live, per the Edit bullet). A **strong finding** here: confidence ≥ 0.85, the move localized to a specific slice (not an aggregate artifact), with concrete trace / generation / evaluation / cluster IDs and query results in the `evidence`. A cost / latency / eval regression is chart-shaped — attach the slice's daily series via `charts` so the move against its own baseline is visible in the report. A cost / latency / eval regression is an investigation, not a one-line code fix, so set `actionability=requires_human_input` and **leave `priority` and `repository` unset** — they're PR-autostart fields, and supplying `priority` + `suggested_reviewers` with no `repository` signals PR intent that spins up a repo-selection sandbox only to no-op (autostart needs `immediately_actionable`). **Always set `suggested_reviewers`** regardless — resolve the owning person via `scout-members-list` and pass their resolved `github_login` (or a `{user_uuid}`) as an object, since `suggested_reviewers` is a **list of objects, not bare strings** (cache the login under a `reviewer:llm_analytics:<area>` key). It's how the report reaches a human; left empty, the report is assigned to nobody and is likely missed. After authoring, write a `report:llm_analytics:<entity>` scratchpad entry with the `report_id` so the next run edits it instead of duplicating.
 - **Remember** if it's below the bar but worth carrying forward, or to record what you ruled out and why.
 - **Skip** with a one-line note in your final summary if a scratchpad entry with a `noise:` / `addressed:` / `dedupe:` key prefix, or an existing inbox report, already covers it.
diff --git a/skills/signals-scout-anomaly-detection/SKILL.md b/skills/signals-scout-anomaly-detection/SKILL.md
index 37152c7..d5c9c7f 100644
--- a/skills/signals-scout-anomaly-detection/SKILL.md
+++ b/skills/signals-scout-anomaly-detection/SKILL.md
@@ -87,7 +87,7 @@ Memory is continuous, not a final step. Maintain the watchlist and baselines as
 For each candidate anomaly, classify against prior runs, the inbox, and the scratchpad (net-new / material-update / already-covered / addressed-or-noise — full classifier in [`references/watchlist-and-memory.md`](references/watchlist-and-memory.md)). You file findings on the **report channel**: a scored, attributed anomaly you'd stand behind is a finished, 1:1 inbox report, not a weak signal for the pipeline to cluster — so you author it directly. Then:
 
 - **Author** a fresh report via `scout-emit-report` when the move is net-new and clears the bar. **Before you author, write the anomaly up in a notebook** (`notebooks-create`) — the report `summary` is the inbox surface, but the notebook is the durable artifact a human opens to see the charts, the baseline math, and the attribution behind the call. Build it first, then link its URL from the report `summary` and cite it as an `evidence` entry. Attach the scored series to the report itself via `charts` too — reuse the widened-window node you embedded in the notebook — so the break and its baseline are visible in the inbox without opening the notebook. The report contract _and_ the notebook structure — the title/summary prose contract, evidence, actionability, suggested reviewers, the notebook layout + embedded-chart recipe, worked example — are in [`references/report-contract.md`](references/report-contract.md). For this scout a report-worthy anomaly is: robust z ≥ ~3.5 on the latest complete bucket, the move not explained by seasonality or a known data-pipeline gap, with the insight `short_id`, the bucket value, the baseline, the z-score, and the time window in the evidence. **Search the inbox first** (`inbox-reports-list`, plus your `report:` scratchpad pointer) — the channel is not idempotent, so never author a duplicate.
-- **Edit** the existing report via `scout-edit-report` when one already covers this insight's anomaly (found via the inbox search or a `report:anomaly_detection:insight:<short_id>` pointer) and you have a material update — it's still firing, escalated, or correlates with a fresh deploy. `append_note` with the new evidence (link a fresh notebook for the new window); rewrite `title`/`summary` only on a report you own. Don't author a second report for the same ongoing move.
+- **Edit** the existing report via `scout-edit-report` when one already covers this insight's anomaly (found via the inbox search or a `report:anomaly_detection:insight:<short_id>` pointer) and you have a material update — it's still firing, escalated, or correlates with a fresh deploy. Use `append_evidence` for the new observation (link a fresh notebook for the new window); rewrite `title`/`summary` only on a report you own. Don't author a second report for the same ongoing move.
 - **Remember** if it's suggestive but below the bar, or to refresh a baseline / record what you ruled out.
 - **Skip** if a `noise:` / `addressed:` / `report:` entry already covers it without new evidence.
 
diff --git a/skills/signals-scout-anomaly-detection/references/report-contract.md b/skills/signals-scout-anomaly-detection/references/report-contract.md
index 13cddbb..c884026 100644
--- a/skills/signals-scout-anomaly-detection/references/report-contract.md
+++ b/skills/signals-scout-anomaly-detection/references/report-contract.md
@@ -139,15 +139,19 @@ A recurrence or escalation of an insight's anomaly you already reported is an **
 report**. Find the live report (the `report:` pointer's `report_id` → `inbox-reports-retrieve`,
 or `inbox-reports-list` by the insight), then:
 
-- **`append_note`** with the new evidence — additive, audit-friendly, and the right move on any
-  report (even a pipeline-authored one). Build a **fresh notebook** for the new window and link
-  it in the note (one notebook per window — never append a new anomaly to a prior notebook).
+- **`append_evidence`** with the new window's numbers — additive, audit-friendly, and the right move on
+  any report (even a pipeline-authored one). Each item lands in the report's evidence rail as a bound
+  signal, so the report's signal count and weight grow with the recurrence. Build a **fresh notebook**
+  for the new window and link it in the description (one notebook per window — never append a new
+  anomaly to a prior notebook).
+- **`append_note`** for commentary the numbers don't carry — the owning team already knows, or a deploy
+  explains the move. Send it in the same call as the evidence when both apply.
 - **Rewrite `title`/`summary`** only on a report you authored, and only when the framing is
   genuinely stale.
 
 `edit_report` is preflight-gated like `emit_report`, but it **raises** when the scout is gated
 (dry-run `emit=false`, un-approved AI processing, or a disabled source) rather than returning a
-`skipped_reason` — the note is never appended. So if you built a fresh recurrence notebook and
+`skipped_reason` — nothing is appended. So if you built a fresh recurrence notebook and
 the `edit_report` call is blocked (or otherwise doesn't commit), **delete that notebook with
 `notebooks-destroy`** — same orphan-cleanup rule as a non-surfacing author. Equivalently, defer
 building the notebook until the edit is about to commit.
diff --git a/skills/signals-scout-anomaly-detection/references/watchlist-and-memory.md b/skills/signals-scout-anomaly-detection/references/watchlist-and-memory.md
index 26abf62..f2a42df 100644
--- a/skills/signals-scout-anomaly-detection/references/watchlist-and-memory.md
+++ b/skills/signals-scout-anomaly-detection/references/watchlist-and-memory.md
@@ -176,7 +176,7 @@ place.
    ruled out). Stash a `report:` pointer with the new `report_id`.
 2. **Material update** — you already reported this insight's anomaly, but there's new evidence
    (it's still firing, escalated, spread to related insights, or correlates with a fresh
-   deploy). → **Edit** the existing report (`edit_report`): `append_note` with the new evidence
+   deploy). → **Edit** the existing report (`edit_report`): use `append_evidence` for the new observation
    (link a fresh notebook for the new window). Don't author a second report for the same move.
 3. **Already covered** — the report exists and the move is unchanged, still within the window.
    → Skip; optionally refresh the `report:` pointer's note in place.
@@ -191,7 +191,7 @@ Good entries are future-run actionable — the next run reads them and changes b
 key:     report:anomaly_detection:insight:SRVNODib
 content: "report_id 0192f3a1-... — authored 2026-06-07 for the spike on 'LLM Costs By AI
          Product': daily sum 3.4x the 8-Saturday baseline (z=5.1), started 06-06. If still
-         elevated next run, edit_report (append_note) to escalate as sustained; if back within
+         elevated next run, use `edit_report(append_evidence=...)` to escalate as sustained; if back within
          baseline, leave the report and stop."
 ```
 
diff --git a/skills/signals-scout-apm/SKILL.md b/skills/signals-scout-apm/SKILL.md
index ce66d2d..805f99d 100644
--- a/skills/signals-scout-apm/SKILL.md
+++ b/skills/signals-scout-apm/SKILL.md
@@ -119,14 +119,14 @@ Write a scratchpad entry whenever you observe something a future run should know
 - key `pattern:apm:baseline-{service}-{operation}` — "checkout/POST /orders: p95 ~420ms, error rate ~0.3%, ~1.2k req/h at this hour-of-week (2026-06-21)"
 - key `dedupe:apm:{service}:{operation}` — "Surfaced p95 regression on payments/charge (320ms→1.4s, count steady ~800/h) starting 2026-06-21 14:00 UTC. If still elevated next run, edit the report; if back under ~400ms, treat as recovered."
 - key `noise:apm:{service}` — "frontend/GET /healthz: high-volume readiness probe, ignore; deploy-window p95 blips recover within one bucket, don't report unless sustained ≥2 buckets."
-- key `report:apm:{service}:{operation}` — the `report_id` of a report you filed for a regression on this operation (error rate, p95, traffic cliff), so the next run edits it (append_note with the fresh window) instead of duplicating.
+- key `report:apm:{service}:{operation}` — the `report_id` of a report you filed for a regression on this operation (error rate, p95, traffic cliff), so the next run edits it (`append_evidence` with the fresh window) instead of duplicating.
 - key `reviewer:apm:{service}` — a resolved owner (bare lowercase GitHub login) for a service, so reports route to a human faster.
 
 ### Decide
 
 The generic report mechanics — search the inbox first (via the `report:apm:{service}:{operation}` pointer, else an `inbox-reports-list` search on the specific service / operation, not a broad word like `latency`), edit-vs-author, the status rules, reviewer routing, non-idempotent dedup, and the `priority` / `repository` fields — live in the harness prompt and in `authoring-scouts` → `references/report-contract.md`. Do not re-derive them here. This section is only the APM judgment layered on top:
 
-- **Edit** when a still-live report already tracks the operation — an error rate still stepped up, a p95 still elevated, a service still dark. A persistent regression is one report across runs: a new complete bucket confirming it's ongoing is a re-escalation (`append_note` the fresh before/after numbers), not a fresh report per tick.
+- **Edit** when a still-live report already tracks the operation — an error rate still stepped up, a p95 still elevated, a service still dark. A persistent regression is one report across runs: a new complete bucket confirming it is ongoing is a re-escalation (`append_evidence` with the fresh before/after numbers), not a fresh report per tick.
 - **Author** when nothing live covers the regression. A report-worthy finding names the concrete `(service, operation)`, gives before/after numbers (rate or p95, with the steady denominator), dates the onset bucket, and explains the shape that rules out a volume explanation, with the query results in the `evidence`. Attach the regressing series via `charts` — the rate or p95 with the steady request volume alongside — so the rate-step-on-steady-denominator shape is visible. These are investigations, not code fixes → `actionability=requires_human_input`. Priority: an active error-rate regression hitting many requests is **P1**; a contained latency regression **P2**; a single-dependency or low-traffic operation **P3**.
 - **Bundle correlated operations into one report.** When a cluster of operations in one service / subsystem regressed together, file one report for the shared cause, not one per operation — an inbox full of six reports for the same slow deploy is noise.
 - **Remember** if real but below the bar, or worth carrying forward (a fresh baseline, a blip to watch), or to record what you ruled out and why.
diff --git a/skills/signals-scout-conversations/SKILL.md b/skills/signals-scout-conversations/SKILL.md
index 829db9a..276a79e 100644
--- a/skills/signals-scout-conversations/SKILL.md
+++ b/skills/signals-scout-conversations/SKILL.md
@@ -172,7 +172,7 @@ Write a scratchpad entry whenever you observe something a future run should know
 The generic report mechanics — search the inbox first (via the `report:conversations:<dimension>` pointer, else an `inbox-reports-list` search on the specific dimension), edit-vs-author, the status rules, reviewer routing, non-idempotent dedup, and the `priority` / `repository` / actionability fields — live in the harness prompt. Do not re-derive them. This section is only the Conversations judgment on top:
 
 - **Author** when nothing live covers the regression. A report-worthy finding names the **dimension** (SLA breach / first-response / backlog / channel), shows the **rate vs baseline with its volume guard**, dates the onset with a daily breakdown, and localizes it (which channel / role / priority) in the `evidence`. Attach the dimension's own metric via `charts` — breach share with ticket volume alongside, p90 first-response latency, or created/resolved/net backlog counts — so the chart draws the regression the report claims. Most findings are operational (staffing, process, routing) → `actionability=requires_human_input`, `repository=NO_REPO`. The exception: a config/instrumentation defect the data reveals — SLA never set on a channel that should have one, an assignment automation that silently stopped, a status never reaching `resolved` — can be `actionability=immediately_actionable` with a repo when the fix clearly lives in code. Priority: a broad SLA-breach spike or a compounding backlog is **P2** (**P1** if it's severe and still climbing); a single-channel or narrow-window regression is **P3**.
-- **Edit** when a live report already tracks the same dimension and it's still moving — `append_note` the fresh daily rate vs baseline. A persistent regression is one report across runs, not a new report per tick.
+- **Edit** when a live report already tracks the same dimension and it is still moving — add the fresh daily rate and baseline with `append_evidence`. A persistent regression is one report across runs, not a new report per tick.
 - **Remember** if it's below the bar but worth carrying forward (a rate drifting inside the noise band, a channel building history), or to record what you ruled out.
 - **Skip** with a one-line note if a `noise:` / `addressed:` / `dedupe:` entry, or an existing inbox report, already covers it.
 
diff --git a/skills/signals-scout-customer-analytics-billing-and-usage/SKILL.md b/skills/signals-scout-customer-analytics-billing-and-usage/SKILL.md
index 1a28190..cd2eda3 100644
--- a/skills/signals-scout-customer-analytics-billing-and-usage/SKILL.md
+++ b/skills/signals-scout-customer-analytics-billing-and-usage/SKILL.md
@@ -207,7 +207,7 @@ An unexplained one files with the sweep's negative result stated — "no note, s
 Generic mechanics (edit-vs-author, status, reviewer routing, dedupe discipline) come from the harness prompt.
 The product-mix judgment on top:
 
-- **Edit** when a live report already tracks this account+product shift — a fresh confirming week is an `append_note` re-escalation, not a new report.
+- **Edit** when a live report already tracks this account+product shift — add a fresh confirming week with `append_evidence`, not a new report.
 - **Author** when the move clears every gate: >30% vs the same-weekday 4-week baseline, account total flat (quantify both), staked account, share floor respected, seasonality checked, context sweep done.
   Evidence must carry: product name, direction, current vs baseline volume, the product's share of account MRR, and the total-MRR delta for contrast.
   Attach `charts`: the product's weekly series against the account's total series, window wide enough to show the mask.
diff --git a/skills/signals-scout-customer-analytics/SKILL.md b/skills/signals-scout-customer-analytics/SKILL.md
index 5da8c88..c18e434 100644
--- a/skills/signals-scout-customer-analytics/SKILL.md
+++ b/skills/signals-scout-customer-analytics/SKILL.md
@@ -158,7 +158,7 @@ Write a scratchpad entry whenever you observe something a future run should know
 - `baseline:customer_analytics:account:<external_id>` — _the learned normal: weekly event-volume / WAU band (median + MAD), so the next run scores cheaply instead of recomputing._
 - `dedupe:customer_analytics:account:<external_id>` — _a risk already surfaced, with the condition that should re-escalate it (a further drop, or recovery + relapse)._
 - `noise:customer_analytics:account:<external_id>` — _"this account is a known sandbox / migrating off / seasonal — its dips are expected."_
-- `report:customer_analytics:account:<external_id>` — _the `report_id` of a report you filed for a risk on this account, so the next run edits it (append_note with the fresh window) instead of duplicating._
+- `report:customer_analytics:account:<external_id>` — _the `report_id` of a report you filed for a risk on this account, so the next run edits it (`append_evidence` with the fresh window) instead of duplicating._
 - `reviewer:customer_analytics:<area>` — _a resolved owner (bare lowercase GitHub login) for an account segment / CSM-team surface, so reports route to a human faster._
 
 By run #5 the scratchpad knows the account grain, the join health, the fleet baseline, the handful of accounts worth watching, and who owns each — so a real cliff lands with the right context attached.
@@ -167,7 +167,7 @@ By run #5 the scratchpad knows the account grain, the join health, the fleet bas
 
 The generic report mechanics — search the inbox first (via the `report:customer_analytics:account:<external_id>` pointer, else an `inbox-reports-list` search on the account's _specific_ name / external_id, not a broad word like `churn`), edit-vs-author, the status rules, reviewer routing, non-idempotent dedup, and the `priority` / `repository` fields — live in the harness prompt and in `authoring-scouts` → `references/report-contract.md`. Do not re-derive them here. This section is only the customer-analytics judgment layered on top:
 
-- **Edit** when a still-live report already tracks the account — a cliff still deepening, a dormancy still unbroken, a champion still gone. A persistent risk is one report across runs: a new complete week confirming it's ongoing is a re-escalation (`append_note` the fresh volume/WAU numbers), not a fresh report per tick.
+- **Edit** when a still-live report already tracks the account — a cliff still deepening, a dormancy still unbroken, a champion still gone. A persistent risk is one report across runs: a new complete week confirming it is ongoing is a re-escalation (`append_evidence` with the fresh volume/WAU numbers), not a fresh report per tick.
 - **Author** when nothing live covers the account. A report-worthy finding shows the account's engagement dropped clearly below its own seasonality-matched baseline (sustained, not a single lumpy week), the **fleet held** over the same window (quantify both — "Acme weekly events 4.2k→1.1k while fleet steady at ~600 active accounts"), the account is **commercially staked** (assigned role or CRM link — name it), and the move isn't one departing user mistaken for an account-wide cliff. Put the account name, `external_id`, the latest-window numbers, the baseline band, WAU, the assigned owner, and the time window in the `evidence`. Attach the account's weekly engagement series via `charts` with the fleet's series alongside (window wide enough to show both baselines) so the cliff-on-steady-fleet shape is verifiable, not just asserted. These are CSM/AE investigations, not code fixes → `actionability=requires_human_input`. Priority: a confirmed sustained cliff or dormancy onset on a staked, high-value account is **P2**; a single-segment/suggestive move, an unstaked account, or an expansion signal is **P3**.
 - **Remember** if suggestive but below the bar, or to refresh a baseline, or to record what you ruled out and why.
 - **Skip** if a `noise:` / `addressed:` / `dedupe:` entry, or an existing inbox report, already covers it.
diff --git a/skills/signals-scout-data-pipelines/SKILL.md b/skills/signals-scout-data-pipelines/SKILL.md
index a097cbe..a92fb77 100644
--- a/skills/signals-scout-data-pipelines/SKILL.md
+++ b/skills/signals-scout-data-pipelines/SKILL.md
@@ -138,7 +138,7 @@ Write a scratchpad entry whenever you observe something a future run should know
 - key `noise:pipelines:example-fixtures` — _"Flow `ExampleRepoFailures` and functions named `*tester*` are deliberate test fixtures that fail by design — never findings."_
 - key `dedupe:pipelines:stripe-sync-failures` — _"Filed delivery-failure shift on destination `Stripe sync` 2026-06-09 (share 0.4% → 38%, http_401 since 06-08). Skip unless the error class changes or it recovers and breaks again."_ One stable key per issue — update it in place, don't mint a dated variant.
 - key `addressed:pipelines:webhook-404-flow` — _"Team replied: legacy endpoint, flow being retired this sprint. Don't re-file the 404 concentration."_
-- key `report:pipelines:stripe-sync` — _"Report `019f0a96-…` covers the `Stripe sync` delivery-failure shift. Edit it (append_note the fresh numbers) while it persists and the report is still live; if it was resolved and the destination later re-breaks, that's a fresh report."_
+- key `report:pipelines:stripe-sync` — _"Report `019f0a96-…` covers the `Stripe sync` delivery-failure shift. Edit it (`append_evidence` with the fresh numbers) while it persists and the report is still live; if it was resolved and the destination later re-breaks, that's a fresh report."_
 - key `reviewer:pipelines:stripe-sync` — _"`Stripe sync` owned by `alice` (GitHub login) — route its reports there."_
 
 By run #5 you should know the project's high-value pipelines and their failure baselines, which fixtures are noise, and what's already been surfaced — so a real delivery contradiction stands out immediately and cheaply.
@@ -148,7 +148,7 @@ By run #5 you should know the project's high-value pipelines and their failure b
 For a candidate that clears the bar, the call is **edit an existing report, author a new one, remember, or skip** — use judgment, these are the rails:
 
 - **Search the inbox first.** The `report:pipelines:<slug>` scratchpad pointer is the reliable path (it holds the `report_id` — `inbox-reports-retrieve` it directly); with no pointer, `inbox-reports-list` by the specific pipeline name (`ordering=-updated_at`), not a broad word like `pipeline`.
-- **Edit** (`scout-edit-report`) when a still-live report already covers the same pipeline issue — a destination still watcher-disabled, a failure share still elevated, an export still failing. `append_note` the fresh numbers, or rewrite the title/summary on a report you authored. This is the default when a match exists. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key.
+- **Edit** (`scout-edit-report`) when a still-live report already covers the same pipeline issue — a destination still watcher-disabled, a failure share still elevated, an export still failing. Add the fresh numbers with `append_evidence`, or rewrite the title/summary on a report you authored. This is the default when a match exists. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key.
 - **Author** (`scout-emit-report`) only when nothing live covers it. A good report names the pipeline and its id, quantifies the contradiction (failure share vs baseline, failed/stalled intervals, watcher state), names the error class from logs/invocations, and dates the onset — ideally tied to a config edit or deploy. Keep the failure-share evidence numeric rather than reaching for `charts` — the daily series lives only behind `cdp-functions-metrics-retrieve` (no `app_metrics` HogQL table), so there is no attachable query node that reproduces it. Set `priority` (P0–P4) + `priority_explanation` — a non-healthy ingestion-path transformation, a stalled/all-failing batch export, or a 100%-failing production flow is P1, a watcher-disabled destination / sustained failure-share shift / Failed export run is P2, debt and fixture cleanup bundles P3; it's the report's importance in the inbox, your call to make. Set `suggested_reviewers` via `scout-members-list` (objects — a `{github_login}` or `{user_uuid}`, not bare strings; cache under `reviewer:pipelines:<slug>`); left empty the report reaches no one. Then choose the actionability + repo together:
   - Most pipeline findings are an investigation a human confirms (a broken remote endpoint, an expired credential, a watcher intervention) → `actionability=requires_human_input` and `repository=NO_REPO` (NO_REPO is what stops `priority`+reviewers from spawning a pointless repo-selection sandbox).
   - When the fix is an obvious code change (a dead webhook URL or bad template in a team-owned function/flow) → `actionability=immediately_actionable` with `repository="owner/repo"` (or omit `repository` to let the selector pick) to open a draft PR.
diff --git a/skills/signals-scout-data-warehouse/SKILL.md b/skills/signals-scout-data-warehouse/SKILL.md
index 9c9b27e..8affe3a 100644
--- a/skills/signals-scout-data-warehouse/SKILL.md
+++ b/skills/signals-scout-data-warehouse/SKILL.md
@@ -199,7 +199,7 @@ Write a scratchpad entry whenever you observe something a future run should know
 - key `noise:data_warehouse:onboarding-mirror-sources` — _"Sources labelled `onboarding-*`, `posthog-<customer>`, `inc-*` are throwaway demo/incident mirrors that fail by design — never findings; confirm by label and skip."_
 - key `dedupe:data_warehouse:stripe-cdc-slot` — _"Filed CDC replication-slot invalidation on source `Stripe` 2026-06-30 (12 schemas dead, slot exceeded max reserved size). Skip unless the error class changes or it recovers then breaks again."_ One stable key per issue — update it in place, don't mint a dated variant.
 - key `addressed:data_warehouse:hubspot-billing-limit` — _"Team aware: Hubspot schemas capped at the row quota on purpose. Don't re-file BillingLimitReached."_
-- key `report:data_warehouse:stripe` — _"Report `019f0a96-…` covers the `Stripe` source-level Error cascade. Edit it (append_note the fresh numbers / blast radius) while it persists and the report is still live; if it was resolved and the source later re-breaks, that's a fresh report."_
+- key `report:data_warehouse:stripe` — _"Report `019f0a96-…` covers the `Stripe` source-level Error cascade. Edit it (`append_evidence` with the fresh numbers / blast radius) while it persists and the report is still live; if it was resolved and the source later re-breaks, that's a fresh report."_
 - key `reviewer:data_warehouse:stripe` — _"`Stripe` source owned by `alice` (GitHub login) — route its reports there."_
 - key `pattern:data_warehouse:opt-watchlist` — _"Hot tables by daily query_log burn: `prod_postgres_invoice_with_annual` (165 slow runs / 17 users / p50 11s / 11 TB read), `iwa_summary_customer_month` (73 / 5 / 18.6s / 98 TB read), … Recheck weekly, not every run."_
 - key `report:data_warehouse:opt-invoice-annual` — _"Report `019f…` suggests materializing the recurring `prod_postgres_invoice_with_annual` join (2026-07-15: 165 slow q/day, 17 users, 11 TB read). Edit with fresh numbers at most every few runs while live; on decline or fix, write `addressed:` and stop."_
@@ -212,7 +212,7 @@ By run #5 you should know the project's high-value imports and their freshness b
 For a candidate that clears the bar, the call is **edit an existing report, author a new one, remember, or skip** — use judgment, these are the rails:
 
 - **Search the inbox first.** The `report:data_warehouse:<slug>` scratchpad pointer is the reliable path (it holds the `report_id` — `inbox-reports-retrieve` it directly); with no pointer, `inbox-reports-list` by the specific source/schema name (`ordering=-updated_at`), not a broad word like `warehouse`. **Also cross-check `health-issues-list`:** the active warehouse failures (`external_data_failure`) may already be surfaced by the health-checks scout — your distinctive lane is the silent gaps the active-failure summary misses (staleness behind a green status, broken webhook channels, row cliffs).
-- **Edit** (`scout-edit-report`) when a still-live report already covers the same import issue — a source still in Error, a schema still stale, a webhook channel still dead. `append_note` the fresh numbers (widening gap, growing blast radius), or rewrite the title/summary on a report you authored. This is the default when a match exists. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key. When a health-checks `external_data_failure` report already covers the same source/schema, only author (or edit your own) with a material new angle — a quantified growing gap, a broader blast radius, an onset tied to a deploy.
+- **Edit** (`scout-edit-report`) when a still-live report already covers the same import issue — a source still in Error, a schema still stale, a webhook channel still dead. Add the fresh numbers with `append_evidence` (widening gap, growing blast radius), or rewrite the title/summary on a report you authored. This is the default when a match exists. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key. When a health-checks `external_data_failure` report already covers the same source/schema, only author (or edit your own) with a material new angle — a quantified growing gap, a broader blast radius, an onset tied to a deploy.
 - **Author** (`scout-emit-report`) only when nothing live covers it. A good report names the source/schema and its id, states the contradiction (status vs freshness vs cadence), quantifies the gap (intervals or hours missed, rows behind), names the error class from `latest_error`, and dates the onset — ideally tied to a config edit or deploy from the activity log. Set `priority` (P0–P4) + `priority_explanation` — a source-level Error / all armed schemas under a source failing / a stalled ingestion-critical table is P1, a single Failed schema / confirmed growing gap / broken webhook channel is P2, billing limits / unused materialized views / hygiene bundles P3; it's the report's importance in the inbox, your call to make. Set `suggested_reviewers` via `scout-members-list` (objects — a `{github_login}` or `{user_uuid}`, not bare strings; cache under `reviewer:data_warehouse:<slug>`); left empty the report reaches no one. A warehouse import gap is a config/credential/remote-side investigation a human confirms, not a one-line code change → `actionability=requires_human_input` and `repository=NO_REPO` (NO_REPO is what stops `priority`+reviewers from spawning a pointless repo-selection sandbox). After authoring, write the `report:data_warehouse:<slug>` pointer with the `report_id` so the next run edits instead of duplicating.
 - **Remember** if below the bar but worth carrying forward (freshness drifting inside the noise band, a single self-recovered Failed run, `records_failed` creeping); **skip** with a one-line note if a `noise:` / `addressed:` / `dedupe:` entry or an existing report already covers it.
 - **Optimization reports are P3, capped, and evergreen-deduped.** At most 1–2 new opportunity reports per run, and lane-2 reports never crowd out an integrity finding. A good one names the table or query shape, gives the window's numbers (runs, users, p50, minutes burned, **bytes read** — the resource cost is the persuasive half), and attaches one concrete suggestion (materialize this shape as a view, point the dashboard at the existing matview, simplify the expensive cohort, retire the unread matview) — `actionability=requires_human_input`, `repository=NO_REPO`. Opportunities are evergreen (the same slow query is slow every run), so the discipline is strict: file once under `report:data_warehouse:opt-<slug>`, edit with fresh numbers at most every few runs while live, and once `addressed:` exists never re-file unless the burn changes materially. Derive `<slug>` from a stable identifier — the table name for hot tables, the view name for matview findings, the prefix `qhash` for query shapes — never from prose, so the next run recomputes the same key and the dedupe holds.
diff --git a/skills/signals-scout-error-tracking/SKILL.md b/skills/signals-scout-error-tracking/SKILL.md
index 12afbb0..9a1fe4a 100644
--- a/skills/signals-scout-error-tracking/SKILL.md
+++ b/skills/signals-scout-error-tracking/SKILL.md
@@ -92,7 +92,7 @@ Memory is a continuous activity. Write a scratchpad entry whenever you observe s
 - key `dedupe:error_tracking:019de34e` — _"Issue 019de34e — surfaced 2026-05-01 11:31–13:22Z, then quiet. If quiet next run, treat as already-surfaced; if firing, escalate."_
 - key `noise:error_tracking:sandbox-timeoutexpired` — _"Sandbox `TimeoutExpired` Docker errors are recurring noise on this team — internal harness ops, not user-facing."_
 - key `pattern:error_tracking:fetch_signals_for_report_activity` — _"Server activity `fetch_signals_for_report_activity` was a regression source on 2026-05-01 — if it appears in a fresh stack trace, double-check it's not the same root cause."_
-- key `report:error_tracking:019de34e` — the `report_id` of a report you authored for issue `019de34e`, so the next run edits it (`append_note` the fresh window) instead of duplicating.
+- key `report:error_tracking:019de34e` — the `report_id` of a report you authored for issue `019de34e`, so the next run edits it (`append_evidence` with the fresh window) instead of duplicating.
 - key `reviewer:error_tracking:ingestion` — a resolved owner (bare lowercase GitHub login) for a service / module / activity area, so reports route to a human faster.
 
 By run #5 you'll have a local map of what's normal versus what warrants investigation, and burn less time on cold-start exploration.
@@ -101,7 +101,7 @@ By run #5 you'll have a local map of what's normal versus what warrants investig
 
 The generic report mechanics — search the inbox first (via the `report:error_tracking:<issue_id>` pointer, else an `inbox-reports-list` search on the issue's _specific_ terms — the issue id, the fingerprint, the failing activity name, not a broad word like `error`), edit-vs-author, the status rules, reviewer routing, non-idempotent dedup, and the `priority` / `repository` / actionability fields — live in the harness prompt and in `authoring-scouts` → `references/report-contract.md`. Do not re-derive them here. This section is only the error-tracking judgment layered on top:
 
-- **Edit** when a still-live report already tracks the same issue and it's still moving — a burst still elevated, a stuck loop still looping, a cluster still growing. A persistent issue is one report across runs: a fresh window confirming it's ongoing is a re-escalation (`append_note` the fresh hourly counts and distinct-user numbers), not a new report per tick. A **status regression** is the exception — an issue the team explicitly `resolved` that's firing again is a genuinely new event; if its prior report is already closed, author a fresh report (per the status rules) and repoint `report:error_tracking:<issue_id>` rather than appending to a resolved item.
+- **Edit** when a still-live report already tracks the same issue and it's still moving — a burst still elevated, a stuck loop still looping, a cluster still growing. A persistent issue is one report across runs: a fresh window confirming it's ongoing is a re-escalation (`append_evidence` with the fresh hourly counts and distinct-user numbers), not a new report per tick. A **status regression** is the exception — an issue the team explicitly `resolved` that's firing again is a genuinely new event; if its prior report is already closed, author a fresh report (per the status rules) and repoint `report:error_tracking:<issue_id>` rather than appending to a resolved item.
 - **Author** when nothing live covers the issue. A report-worthy finding names the issue (issue id + fingerprint), shows the count-vs-distinct_users shape that makes it signal, quantifies the burst against baseline with an hourly breakdown, dates the onset, and — when the stack trace names a server activity / view — cites it with an `advanced-activity-logs-list` deploy correlation, all in the `evidence`. Attach the burst as a report chart — the issue's hourly or daily series with the baseline window on screen — so the spike and its onset are visible next to the numbers. Most findings are investigations → `actionability=requires_human_input` + `repository=NO_REPO`. The exception this surface earns: a well-localized bug whose stack trace points at a specific named file / module in a known repo can be `actionability=immediately_actionable` + `repository=owner/repo` to open a draft fix PR. Priority: a fresh broad-reach regression (count and distinct_users both spiking, per-request server path) or a resolved-issue status regression is **P1**, **P2** when reach is moderate; a stuck loop or narrow-reach cluster is **P3**, **P2** when count is in the thousands and fresh.
 - **Remember** if it's below the bar but worth carrying forward (an issue drifting inside the noise band, a fingerprint building history), or to record what you ruled out and why.
 - **Skip** with a one-line note if a `noise:` / `addressed:` / `dedupe:` entry, or an existing inbox report, already covers it.
diff --git a/skills/signals-scout-experiments/SKILL.md b/skills/signals-scout-experiments/SKILL.md
index ad958e3..6ce3d81 100644
--- a/skills/signals-scout-experiments/SKILL.md
+++ b/skills/signals-scout-experiments/SKILL.md
@@ -189,7 +189,7 @@ Write a scratchpad entry whenever you observe something a future run should know
 - key `noise:experiments:pricing-v2-forced-ios` — _"Flag has a forced-variant release condition (iOS → test) — deliberate per config; per-variant ratio will never match the nominal split. Don't call SRM on the aggregate; compare within the random cohort only."_
 - key `dedupe:experiments:42-srm` — _"Filed SRM on `new-checkout` (id 42) 2026-06-09: 56/44 on 22k exposures, started at flag v7 edit 2026-06-05. If still skewed next run, skip; if team reset/relaunched, watch the fresh data instead."_ One stable key per issue — update it in place, don't mint a dated variant.
 - key `addressed:experiments:31-zombie` — _"Recommended ending `old-onboarding` (id 31, running 140 days) on 2026-05-15; team aware. Don't re-file unless it's still running in 30 days."_
-- key `report:experiments:new-checkout` — _"Report `019f0a96-…` covers the `new-checkout` (id 42) SRM. Edit it (append_note the fresh numbers) while the skew persists and the report is still live; if it was resolved and the experiment later re-skews, that's a fresh report."_
+- key `report:experiments:new-checkout` — _"Report `019f0a96-…` covers the `new-checkout` (id 42) SRM. Edit it (append_evidence with the fresh numbers) while the skew persists and the report is still live; if it was resolved and the experiment later re-skews, that's a fresh report."_
 - key `reviewer:experiments:new-checkout` — _"`new-checkout` owned by `alice` (GitHub login) — route its reports there."_
 
 By run #5 you should know every running experiment's expected split, exposure baseline, exposure-event type, and which quirks are deliberate — so a real contradiction stands out immediately and cheaply.
@@ -199,7 +199,7 @@ By run #5 you should know every running experiment's expected split, exposure ba
 For a candidate that clears the bar, the call is **edit an existing report, author a new one, remember, or skip** — use judgment, these are the rails:
 
 - **Search the inbox first.** The `report:experiments:<slug>` scratchpad pointer is the reliable path (it holds the `report_id` — `inbox-reports-retrieve` it directly); with no pointer, `inbox-reports-list` by the specific experiment name **and** flag key (`ordering=-updated_at`), not a broad word like `experiment` (which matches hundreds of unrelated UX reports).
-- **Edit** (`scout-edit-report`) when a still-live report already covers the same experiment issue — an SRM still skewed, a stall that hasn't recovered, a `$multiple` trend still climbing. `append_note` the fresh numbers, or rewrite the title/summary on a report you authored. This is the default when a match exists. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key.
+- **Edit** (`scout-edit-report`) when a still-live report already covers the same experiment issue — an SRM still skewed, a stall that hasn't recovered, a `$multiple` trend still climbing. Add the fresh numbers with `append_evidence`, or rewrite the title/summary on a report you authored. This is the default when a match exists. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key.
 - **Author** (`scout-emit-report`) only when nothing live covers it. A good report names the experiment id and flag key, quantifies the contradiction (observed vs expected split with exposure counts, `$multiple` percentage, days dormant), passes the sample-size gate, and dates the onset — ideally tied to a flag version or activity-log entry. When the threat lives in a series — per-variant exposures skewing, `$multiple` share climbing, a stall's flatline — attach it via `charts` so the contradiction is visible, not just quoted. Set `priority` (P0–P4) + `priority_explanation` — validity threats on a live decision (SRM, mid-run mutation, contamination) are P2, stalls P2–P3 by blast radius, lifecycle hygiene P3; it's the report's importance in the inbox, your call to make. Set `suggested_reviewers` via `scout-members-list` (objects — a `{github_login}` or `{user_uuid}`, not bare strings; cache under `reviewer:experiments:<slug>`); left empty the report reaches no one. A validity threat is an investigation a human confirms, not a one-line change → `actionability=requires_human_input` and `repository=NO_REPO` (NO_REPO is what stops `priority`+reviewers from spawning a pointless repo-selection sandbox). After authoring, write the `report:experiments:<slug>` pointer with the `report_id` so the next run edits instead of duplicating.
 - **Remember** if below the bar but worth carrying forward (a ratio drifting but inside the noise band, `$multiple` creeping at 0.3%, a plateau that needs one more week); **skip** with a one-line note if a `noise:` / `addressed:` / `dedupe:` entry or an existing report already covers it.
 
diff --git a/skills/signals-scout-feature-flags/SKILL.md b/skills/signals-scout-feature-flags/SKILL.md
index 9c95b07..42f8570 100644
--- a/skills/signals-scout-feature-flags/SKILL.md
+++ b/skills/signals-scout-feature-flags/SKILL.md
@@ -194,7 +194,7 @@ By run #5 you should know the project's high-volume flags, their baselines and r
 For a candidate that clears the bar, the call is **edit an existing report, author a new one, remember, or skip** — use judgment, these are the rails:
 
 - **Search the inbox first.** The `report:feature-flags:<key>` scratchpad pointer is the reliable path (it holds the `report_id` — `inbox-reports-retrieve` it directly); with no pointer, `inbox-reports-list` by the specific flag key (`ordering=-updated_at`), not a broad word like `flag`.
-- **Edit** (`scout-edit-report`) when a still-live report already covers the flag **and the situation materially changed** — the issue recovered, the flag was reconfigured or its rollout changed, the scope or severity shifted (a cliff deepened, a ghost's reach jumped, a distribution shift widened), intent was confirmed, or a defined refresh cadence (e.g. daily) has elapsed. `append_note` the fresh numbers, or rewrite the title/summary on a report you authored. **Don't edit just because the issue persists unchanged** — a cliff still down at the same level, a ghost still hot at the same volume, a debt bundle that only grew slightly is monitoring, not news. Re-appending the same measurement every three-hour run grows the audit trail without moving the decision forward; keep tracking it in `pattern:` memory and leave the report untouched, so its history records changes rather than ticks. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key.
+- **Edit** (`scout-edit-report`) when a still-live report already covers the flag **and the situation materially changed** — the issue recovered, the flag was reconfigured or its rollout changed, the scope or severity shifted (a cliff deepened, a ghost's reach jumped, a distribution shift widened), intent was confirmed, or a defined refresh cadence (e.g. daily) has elapsed. Add the fresh numbers with `append_evidence` when the problem deepened or widened. Add a recovery or a confirmed intent with `append_note`, because the evidence counters only grow and would rank a recovered report as stronger. Rewrite the title/summary on a report you authored. **Don't edit just because the issue persists unchanged** — a cliff still down at the same level, a ghost still hot at the same volume, a debt bundle that only grew slightly is monitoring, not news. Re-appending the same measurement every three-hour run grows the audit trail without moving the decision forward; keep tracking it in `pattern:` memory and leave the report untouched, so its history records changes rather than ticks. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key.
 - **Author** (`scout-emit-report`) only when nothing live covers it. A good report names the flag key and id, quantifies the contradiction (baseline vs current calls, response mix before/after, ghost volume and reach), passes the volume gates, and dates the onset. Attach the flag's `$feature_flag_called` series via `charts` — the cliff or response-mix shift, dated — so the contradiction with the configured state is visible; prefer a trends node (it zero-fills empty days), since a SQL series without a date spine ends at the cliff instead of drawing the drop to zero. Set `priority` (P0–P4) + `priority_explanation` — it's the report's importance in the inbox, your call to make. Set `suggested_reviewers` via `scout-members-list` (objects — a `{github_login}` or `{user_uuid}`, not bare strings; cache under `reviewer:feature-flags:<key>`); left empty the report reaches no one. Then choose the actionability + repo together:
   - Most flag findings are an investigation a human confirms, not a one-line change → `actionability=requires_human_input` and `repository=NO_REPO` (NO_REPO is what stops `priority`+reviewers from spawning a pointless repo-selection sandbox).
   - When the fix is an obvious code change (e.g. a ghost flag whose dead check just needs removing) → `actionability=immediately_actionable` with `repository="owner/repo"` (or omit `repository` to let the selector pick) to open a draft PR.
diff --git a/skills/signals-scout-general/references/conventions.md b/skills/signals-scout-general/references/conventions.md
index d502ce2..b586d8c 100644
--- a/skills/signals-scout-general/references/conventions.md
+++ b/skills/signals-scout-general/references/conventions.md
@@ -14,9 +14,9 @@ before you author a report (the harness prompt carries the report-channel contra
 2. **Material update on an existing report** — a report already covers the topic
    (one you authored last run, or a pipeline report), but you have new evidence: a
    different source corroborating, a fresh deploy correlation, contradicting data, a
-   meaningful escalation in scope. → **`edit-report` it** — `append_note` with the
-   fresh evidence, or rewrite `title`/`summary` on a report you authored. Don't mint
-   a near-duplicate.
+   meaningful escalation in scope. → **`edit-report` it** — `append_evidence` with the
+   fresh observation, `append_note` with a reading of it, or rewrite `title`/`summary`
+   on a report you authored. Don't mint a near-duplicate.
 
 3. **Same fact already covered** — an existing report already captures the same
    evidence shape, nothing has changed. → Skip. Optionally rewrite an existing
diff --git a/skills/signals-scout-health-checks/SKILL.md b/skills/signals-scout-health-checks/SKILL.md
index 769e777..163c222 100644
--- a/skills/signals-scout-health-checks/SKILL.md
+++ b/skills/signals-scout-health-checks/SKILL.md
@@ -111,14 +111,14 @@ Write scratchpad entries continuously, encoding the category in the key prefix:
 - `noise:health:<kind>:team{team_id}` — "team runs {kind} at a steady baseline / dev-env only; don't surface unless it escalates."
 - `addressed:health:<kind>:team{team_id}` — "team fixed {kind} (issues auto-resolved on {date}); stay quiet."
 - `pattern:health:shape-team{team_id}` — durable note on this team's normal setup shape (distinct from the `clean-team` close-out marker above, which only records the last all-clear).
-- `report:health:<kind>` (or `report:health:cluster:<kind>` / `report:health:cause:<cause_id>`) — the `report_id` of a report you filed for a kind / cluster / shared root cause, so the next run edits it (append_note with the fresh count) instead of duplicating.
+- `report:health:<kind>` (or `report:health:cluster:<kind>` / `report:health:cause:<cause_id>`) — the `report_id` of a report you filed for a kind / cluster / shared root cause, so the next run edits it (`append_evidence` with the fresh count) instead of duplicating.
 - `reviewer:health:<area>` — a resolved owner (bare lowercase GitHub login) for a setup / instrumentation / warehouse area, so reports route to a human faster.
 
 ### Decide
 
 The generic report mechanics — search the inbox first (via the `report:health:*` pointer, else an `inbox-reports-list` search on the specific kind / entity id, not a broad word like `failure`), edit-vs-author, the status rules, reviewer routing, non-idempotent dedup, and the `priority` / `repository` fields — live in the harness prompt and in `authoring-scouts` → `references/report-contract.md`. Do not re-derive them here. This section is only the health-checks judgment layered on top:
 
-- **Edit** when a still-live report already tracks the kind, cluster, or root cause — a critical still active, a cluster whose count grew, a cause still unfixed. A persistent issue is one report across runs: a new run confirming it's still active (or the cluster grew) is a re-escalation (`append_note` the fresh count / ids), not a fresh report per tick.
+- **Edit** when a still-live report already tracks the kind, cluster, or root cause — a critical still active, a cluster whose count grew, a cause still unfixed. A persistent issue is one report across runs: a new run confirming it is still active (or the cluster grew) is a re-escalation (`append_evidence` with the fresh count / ids), not a fresh report per tick.
 - **Author** when nothing live covers it. A report-worthy finding is **one root cause, one bundled kind-cluster, or one confirmed critical — never one report per issue in a cluster**. Put the relevant `remediation` guidance in the summary, cite the issue ids (and a few payload entity ids) in the `evidence`, and quantify the cluster (how many, which entities, downstream impact). Priority follows check severity, adjusted by real blast radius: `critical` → **P1** (P0 only for confirmed active data loss like `no_live_events` with zero recent capture); `warning` → **P2–P3**. Actionability follows agent-fixability: an issue the `remediation.agent` can resolve via the MCP or a code change → `immediately_actionable` (+ `repository=owner/repo` for a code fix, or omit `repository` to let the selector pick); a credential-gated issue (re-auth a warehouse source, rotate secrets) → `requires_human_input` + `repository=NO_REPO`, framed for a human. After authoring, write the `report:health:*` pointer so the next run edits instead of duplicating.
 - **Remember** below the bar but worth carrying forward (write the matching `dedupe:` / `noise:` entry), or to record what you ruled out and why.
 - **Skip** if a `dedupe:` / `noise:` / `addressed:` entry, or an existing inbox report, already covers it.
diff --git a/skills/signals-scout-inbox-validation/SKILL.md b/skills/signals-scout-inbox-validation/SKILL.md
index c7b3b42..3851218 100644
--- a/skills/signals-scout-inbox-validation/SKILL.md
+++ b/skills/signals-scout-inbox-validation/SKILL.md
@@ -125,7 +125,7 @@ Encode the category in the key prefix; rewrite a key to update in place:
 - key `pending:inbox_validation:report-019e1a2b` — _"Resolved 2026-06-09T14:02Z (PR github.com/acme/app/pull/412). Probe: error issue 0d4c... baseline 310 occ/day, 280 users/day over Jun 2–9; also log pattern 'payment webhook 500' ~40/hr. Validate after 2026-06-10T14:02Z. Pass 1 of 2."_
 - key `addressed:inbox_validation:report-019e1a2b` — _"Validated held 2026-06-11: issue 0d4c... at 2 occ/day post-merge (was 310), no fresh signals, no sibling report. Done — don't revisit."_
 - key `dedupe:inbox_validation:report-019e1a2b` — _"Authored failed-validation report 2026-06-11: issue still at 290 occ/day 48h post-merge. Don't re-file; if a new fix PR merges, re-enqueue fresh."_
-- key `report:inbox_validation:report-019e1a2b` — the `report_id` of the failed-validation report you authored, so a still-failing re-check edits it (`append_note` the fresh window) instead of duplicating.
+- key `report:inbox_validation:report-019e1a2b` — the `report_id` of the failed-validation report you authored, so a still-failing re-check edits it (`append_evidence` with the fresh window) instead of duplicating.
 - key `reviewer:inbox_validation:<area>` — a resolved owner (bare lowercase GitHub login) for a fix author / report reviewer, so a failed-validation report routes to a human faster.
 - key `noise:inbox_validation:report-019e77c1` — _"Unverifiable: report recommended a docs clarification; no measurable data stream. Closed without verdict."_
 
@@ -136,7 +136,7 @@ By steady state the queue should be small and self-describing: every pending ent
 The generic report mechanics — edit-vs-author, the status rules (crucial here: `edit_report` can't reopen a `resolved` report), reviewer routing, non-idempotent dedup, and the `priority` / `repository` / actionability fields — live in the harness prompt and in `authoring-scouts` → `references/report-contract.md`. Do not re-derive them here. This section is only the inbox-validation judgment layered on top:
 
 - **Author** a fresh report via `scout-emit-report` only for a **failed** validation (and the gated dismissed-escalation below). It cites the original resolved report (an `inbox` evidence entry with its id), names the report title, the PR URL and merge date, the before-vs-after numbers per re-probed entity, and a recommendation (reopen and follow up on the fix). A failed validation is a fresh report, not an edit of the resolved one — the resolved report can't be reopened via `edit_report`. Most failed validations are investigations (why didn't the fix hold?) → `actionability=requires_human_input` + `repository=NO_REPO`; when the recurrence is an unambiguous same-entity regression and the fix repo is known from `implementation_pr_url`, `actionability=immediately_actionable` + `repository=owner/repo` (that repo) opens a re-fix draft PR. Priority: **P2** when the recurring problem is user-impacting at material volume, **P3** otherwise (and for the dismissed-escalation). Route `suggested_reviewers` to the fix's author / the original report's reviewer via `scout-members-list`. After authoring, write `report:inbox_validation:report-<id8>` with the `report_id`.
-- **Edit** only when a failed-validation report _you_ authored earlier is still open and the same fix is still failing — `append_note` the fresh post-soak numbers rather than filing a near-duplicate. A new fix PR merging is a fresh validation cycle → a fresh report, not an edit.
+- **Edit** only when a failed-validation report _you_ authored earlier is still open and the same fix is still failing — add the fresh post-soak numbers with `append_evidence` rather than filing a near-duplicate. A new fix PR merging is a fresh validation cycle → a fresh report, not an edit.
 - **Remember** everything else — held, unverifiable, extended, partial.
 - **Skip** anything already covered by an `addressed:` / `dedupe:` / `report:` / `noise:` entry — unless the report's resolution is _newer_ than the verdict (a new fix PR merged since: compare the report's `updated_at` / PR URL against what the verdict entry records, and date your verdict entries so this comparison works). Then re-enqueue fresh.
 
diff --git a/skills/signals-scout-insight-alerts/SKILL.md b/skills/signals-scout-insight-alerts/SKILL.md
index 3950d82..013d3ef 100644
--- a/skills/signals-scout-insight-alerts/SKILL.md
+++ b/skills/signals-scout-insight-alerts/SKILL.md
@@ -76,14 +76,14 @@ Write a scratchpad entry whenever a future run should change behavior. Encode th
 - `dedupe:insight_alerts:{alert_id}` — "Surfaced firing of '{name}' (alert {alert_id}, insight {short_id}) on {date}, value {v} vs bound {b}, silent. If still Firing next run, edit the report; if resolved + notified, treat as covered."
 - `noise:insight_alerts:{alert_id}` — "flaps every few hours on a too-tight bound; the firing itself isn't signal. Only surface as a one-off tuning hygiene finding, never per-flap."
 - `addressed:insight_alerts:{alert_id}` / `allowlist:insight_alerts:{alert_id}` — team fixed / acked it, or owner deliberately keeps it low-priority — skip.
-- `report:insight_alerts:{alert_id}` — the `report_id` of a report you filed for a firing on this alert, so the next run edits it (append_note with the fresh firing) instead of duplicating.
+- `report:insight_alerts:{alert_id}` — the `report_id` of a report you filed for a firing on this alert, so the next run edits it (`append_evidence` with the fresh firing) instead of duplicating.
 - `reviewer:insight_alerts:{alert_id}` — a resolved owner (bare lowercase GitHub login) for an alert or its insight, so reports route to a human faster.
 
 ### Decide
 
 The generic report mechanics — search the inbox first (via the `report:insight_alerts:{alert_id}` pointer, else an `inbox-reports-list` search on the specific alert / insight name, not a broad word like `alert`), edit-vs-author, the status rules, reviewer routing, non-idempotent dedup, and the `priority` / `repository` fields — live in the harness prompt and in `authoring-scouts` → `references/report-contract.md`. Do not re-derive them here. Classify each candidate firing against prior runs and the scratchpad (net-new / material-update / already-covered / addressed-or-noise), then apply only the insight-alerts judgment:
 
-- **Edit** when a still-live report already tracks the alert — a firing you surfaced that's still open, or a recurrence on the same alert. A persistent breach is one report across runs: `append_note` the fresh firing (`calculated_value` vs bound, the new fired-at, current notification status), not a fresh report per day.
+- **Edit** when a still-live report already tracks the alert — a firing you surfaced that's still open, or a recurrence on the same alert. A persistent breach is one report across runs: add the fresh firing with `append_evidence` (`calculated_value` vs bound, the new fired-at, current notification status), not a fresh report per day.
 - **Author** when nothing live covers the firing. A report-worthy finding is an enabled, un-snoozed alert with a **material** firing (well past its bound or a high anomaly score) inside the window that was **under-notified** (silent / suppressed) or is **still open and unacted**, with the alert id, insight `short_id`, the firing `calculated_value` vs the threshold bound, the fired-at time, and the notification status in the `evidence`. This is a triage callout, not a code fix → `actionability=requires_human_input`. Priority: a material, silent firing on a clearly important metric is **P1**; a material firing that was notified but is still open/unacted is **P2**; Errored-alert blind spots and flapping-threshold hygiene are **P3**. Attach the firing insight as a report chart — a `SavedInsightNode` by its `short_id` only when its saved range is absolute and contains the firing (a relative range scrolls past it as days pass), else an ad-hoc node with pinned dates covering it — so the breach is visible next to the threshold numbers.
 - **Cap and rank.** File at most ~5 reports per run, worst-first by the discriminator. If more cleared the bar, say how many you dropped in the close-out — never silently truncate. One digest-style report that bundles several minor firings is fine when none individually warrants its own entry; bundle the flapping/Errored hygiene items this way rather than one report each.
 - **Remember** if it's suggestive but below the bar (a marginal breach, a single flap), or to refresh the baseline / record what you ruled out.
diff --git a/skills/signals-scout-logs/SKILL.md b/skills/signals-scout-logs/SKILL.md
index d1a63ad..8ac89da 100644
--- a/skills/signals-scout-logs/SKILL.md
+++ b/skills/signals-scout-logs/SKILL.md
@@ -120,7 +120,7 @@ Memory is a continuous activity. Write a scratchpad entry whenever you observe s
 - key `noise:logs:rabbitmq-deploy-window` — _"Log message `connection refused: rabbitmq:5672` is recurring noise during deploy windows (Mon/Wed 14:00 UTC) — auto-recovers within 5 min."_
 - key `pattern:logs:alert-47` — _"Logs alert `db-connection-pool-saturated` (id 47) auto-mutes 02:00–04:00 UTC for nightly batch — firing outside that window is real."_
 - key `addressed:logs:cdp-worker-2026-04-30` — _"Service `cdp-worker` migrated to a new runtime on 2026-04-30 — log volume baseline shifted from 8k/hour to 14k/hour, treat new baseline as normal."_
-- key `report:logs:temporal-worker` — _"Authored report `019f0a96-…` for the temporal-worker error-rate burst on 2026-06-30. Edit it (append_note) if the burst persists or worsens rather than filing a new one."_
+- key `report:logs:temporal-worker` — _"Authored report `019f0a96-…` for the temporal-worker error-rate burst on 2026-06-30. Edit it (`append_evidence`) if the burst persists or worsens rather than filing a new one."_
 - key `reviewer:logs:temporal-worker` — _"`temporal-worker` logs owned by `alice` (GitHub login) — route its reports there."_
 
 By run #5 you'll know per-service volume and severity baselines, which alerts are intentional outliers, which open report covers a service, who owns it, and only file fresh shifts.
@@ -129,7 +129,7 @@ By run #5 you'll know per-service volume and severity baselines, which alerts ar
 
 Search the inbox before you author — a report covering this service / message / shift may already exist (`inbox-reports-list` with `ordering=-updated_at`, then `inbox-reports-retrieve` the closest matches). Then, for each candidate finding:
 
-- **Edit** the existing report via `scout-edit-report` when the inbox already covers the service or pattern. A logs shift is rarely brand-new — a service that's still degrading, an alert that's flapping again, a burst that's worsening: `append_note` with the fresh numbers and time range (or rewrite the title/summary on a report you authored). This is the default when a match exists; don't mint a near-duplicate. The dedupe pull is real here — the same service moving twice in two days is one report, not two.
+- **Edit** the existing report via `scout-edit-report` when the inbox already covers the service or pattern. A logs shift is rarely brand-new — a service that's still degrading, an alert that's flapping again, a burst that's worsening: use `append_evidence` for the fresh numbers and time range (or rewrite the title/summary on a report you authored). This is the default when a match exists; don't mint a near-duplicate. The dedupe pull is real here — the same service moving twice in two days is one report, not two.
 - **Author** a fresh report via `scout-emit-report` when nothing in the inbox covers it (or a known issue has new evidence that changes the verdict). The natural fit is a single, localized, validated shift — one service's volume burst, one severity step, one silent service, one fresh message firing at scale — with concrete service / message / time-range evidence (the bar is confidence ≥ 0.85). A rate or severity shift is chart-shaped — attach the service's series via `charts` so the step and its onset are visible in the report. Most logs reports are an investigation, not a one-line code fix, so default to `requires_human_input`. **Always set `suggested_reviewers`** — resolve the owning person with `scout-members-list` (each member carries a resolved `github_login`; cache it under a `reviewer:logs:<service>` key). It's how the report reaches a human; left empty, the report is assigned to nobody and is likely missed. After authoring, write a `report:logs:<service>` scratchpad entry with the `report_id` so the next run edits it instead of duplicating. The harness prompt carries the full report-channel contract (field schema, safety × actionability status mapping, reviewer routing, the non-idempotency caveat, and the edit rules) — this section only adds the logs-specific framing.
 - **Remember** via `scout-scratchpad-remember` if it's below the bar but worth carrying forward, or to record what you ruled out and why.
 - **Skip** with a one-line note if a scratchpad entry with a `noise:` or `addressed:` key prefix, or an existing inbox report, already covers it.
diff --git a/skills/signals-scout-mcp-tool-calls/SKILL.md b/skills/signals-scout-mcp-tool-calls/SKILL.md
index 5dc05bb..92a42ce 100644
--- a/skills/signals-scout-mcp-tool-calls/SKILL.md
+++ b/skills/signals-scout-mcp-tool-calls/SKILL.md
@@ -117,7 +117,7 @@ Encode the scope in the key prefix so future runs find it with one `text=mcp` se
 - key `noise:mcp_analytics:<tool>` — _"<tool> ~15% validation chronically; agents recover on retry. Skip unless rate clears 30% or reach broadens past 20 users."_
 - key `dedupe:mcp_analytics:category:<category>` — _"Filed report on the data-warehouse category 2026-07-09 (4 tools: view-create 41%, view-update 39%, …). Skip unless the tool set or shapes change."_ One stable key per category — update it in place, don't mint a dated variant.
 - key `addressed:mcp_analytics:<tool>` — _"<tool> 5xx fixed 2026-06-30; back to baseline."_
-- key `report:mcp_analytics:category:<category>` — _"Report `019f0a96-…` covers the insights category's problem tools (query-run, list-insights). Edit it (append_note fresh numbers / newly-problematic tools) while the category still has problem tools and the report is live; if it was resolved and the category later regresses, that's a fresh report."_
+- key `report:mcp_analytics:category:<category>` — _"Report `019f0a96-…` covers the insights category's problem tools (query-run, list-insights). Edit it (`append_evidence` with fresh numbers / newly-problematic tools) while the category still has problem tools and the report is live; if it was resolved and the category later regresses, that's a fresh report."_
 - key `reviewer:mcp_analytics:<category>` — _"insights MCP tools routed to `alice` (owns the insights MCP surface per human correction on report `019f…`) — reuse while that evidence stands."_ Record the **evidence**, not just the login: a memory that says only "routed to alice" is indistinguishable from a guess, and blind reuse compounds a mis-route across every future run. Set the same evidence as the reviewer's `reason` when you author.
 
 ## Decide
@@ -125,7 +125,7 @@ Encode the scope in the key prefix so future runs find it with one `text=mcp` se
 For a category with candidates clearing the bar, the call is **edit an existing report, author a new one, remember, or skip** — use judgment, these are the rails:
 
 - **Search the inbox first.** The `report:mcp_analytics:category:<category>` scratchpad pointer is the reliable path (it holds the `report_id` — `inbox-reports-retrieve` it directly); with no pointer, `inbox-reports-list` by the category name _and_ by each problem tool's name (`ordering=-updated_at`) — the tool-name search is what catches legacy per-tool reports. A category with a live report and no material change is a **skip**.
-- **Edit** (`scout-edit-report`) when a still-live report already covers the category and it still has problem tools — the same ones, or new ones joining. `append_note` the fresh numbers (per-tool rate trends, broadening reach) and any newly-problematic tools, each with its own hypothesis; or rewrite the title/summary on a report you authored. This is the default when a match exists. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key.
+- **Edit** (`scout-edit-report`) when a still-live report already covers the category and it still has problem tools — the same ones, or new ones joining. Add the fresh numbers (per-tool rate trends, broadening reach) and any newly-problematic tools with `append_evidence`, each with its own hypothesis; or rewrite the title/summary on a report you authored. This is the default when a match exists. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key.
 - **Author** (`scout-emit-report`) only when nothing live covers the category — **one report per category** (tools aggregated over the window), never one per tool or per failed call. A **report-worthy finding**: confidence ≥ 0.85, each listed tool's problem (failure / struggle / latency / bloat) high over the volume floor with reach across multiple users/sessions, and — when a Tier-2 lens is available — localized to a class/message/intent with counts in the `evidence`. Below that bar, write memory instead. The `title` names the category and the scale ("MCP data-warehouse tools need improvement: 4 tools failing/struggling"). The `summary` follows Hook (category + N problem tools + combined volume/reach + the category's share of project MCP traffic from query 9) → one short block per problem tool (the quantified problem, its shape from the Tier-2 lens, the fix hypothesis) → Recommendation. Write for an engineer on the owning team who's never seen these tools, and **state which regime the evidence came from**. Attach the category's shape via `charts` — a per-tool bar of the active lens's metric (failure rate, struggling-session share, p95 duration, or response bloat), plus a daily series of that same metric when a regression is dated — so the reader sees the problem tools at a glance. Set `priority` (P0–P4) + `priority_explanation` — what the _worst_ tool would earn alone (P2 if any tool is high-rate/high-struggle, broad-reach, clearly-localized; P3 otherwise); bundling never raises priority. Set `suggested_reviewers` via `scout-members-list` (objects — a `{github_login}` or `{user_uuid}`, not bare strings; cache under `reviewer:mcp_analytics:<category>`, and check prior category reports' artefacts via `inbox-report-artefacts-list` for precedent); left empty the report reaches no one. Then choose the actionability + repo together:
   - In the **hono regime** the tools live in PostHog's own MCP server, so unless this project's team owns that code, the action is an investigation / upstream report → `actionability=requires_human_input` and `repository=NO_REPO` (NO_REPO is what stops `priority`+reviewers from spawning a pointless repo-selection sandbox).
   - When the team **owns the MCP server** (the external-SDK regime, or PostHog's own project — the hono tools live in `PostHog/posthog`, handlers under `services/mcp/` and each product's `mcp/tools.yaml`, so `repository="PostHog/posthog"`) and the hypotheses are concrete code changes — a schema/description fix, a handler bug — → `actionability=immediately_actionable` with `repository="owner/repo"` (or omit `repository` to let the selector pick) to open a draft PR, and end the summary with the **Fix loop metric** section (next heading) so the implementation task iterates until the number moves. A category report bundling _heterogeneous_ fixes across several tools leans `requires_human_input` even on an owned server — there's no single-PR shape; a single-tool or same-shape-systemic report can stay `immediately_actionable`.
diff --git a/skills/signals-scout-observability-gaps/SKILL.md b/skills/signals-scout-observability-gaps/SKILL.md
index a86af43..0c777e0 100644
--- a/skills/signals-scout-observability-gaps/SKILL.md
+++ b/skills/signals-scout-observability-gaps/SKILL.md
@@ -161,7 +161,7 @@ The bar trades off:
 
 Then, for each candidate that clears the bar:
 
-- **Edit** when a still-live report already recommends this gap and its evidence has only moved (volume climbed further, reach widened) — `append_note` the fresh numbers rather than minting a near-duplicate.
+- **Edit** when a still-live report already recommends this gap and its evidence has only moved (volume climbed further, reach widened) — add the fresh numbers with `append_evidence` rather than minting a near-duplicate.
 - **Author** a fresh report only when nothing live covers the gap. Recommendations are investigations, not code fixes → `actionability=requires_human_input` + `repository=NO_REPO`. Priority is almost always **P3** (a suggestion); a critical failure-semantics event (family 3 — `payment_failed`, `*_error`, `*_blocked`) firing with zero alert coverage is **P2**.
 - **Remember / Park** a below-bar candidate via the watch lifecycle below.
 - **Skip** with a one-line note if a `noise:` / `addressed:` / `dedupe:` entry, or an existing inbox report, already covers it.
diff --git a/skills/signals-scout-product-analytics/SKILL.md b/skills/signals-scout-product-analytics/SKILL.md
index 14ca499..885b4fd 100644
--- a/skills/signals-scout-product-analytics/SKILL.md
+++ b/skills/signals-scout-product-analytics/SKILL.md
@@ -88,14 +88,14 @@ Maintain the watchlist and baselines as you work, encoding the category in the k
 - `watchlist:product_analytics:flow:<short_id>` — a curated flow: name, kind (funnel/retention/lifecycle/stickiness), the events/steps, cadence, `inferred?`, and `last_scored` + `next_due`.
 - `baseline:product_analytics:flow:<short_id>` — the learned normal: per-step conversion % band (median + MAD), or the retention curve band per day-offset, so the next run scores cheaply instead of recomputing the full baseline.
 - `dedupe:product_analytics:flow:<short_id>:<date>` — a regression already surfaced, with the condition that should re-escalate it (a further drop, or recovery + relapse).
-- `report:product_analytics:flow:<short_id>:<rate>` — the `report_id` of a report you authored for a regression on this flow's specific rate (the affected step/cohort/state), so the next run edits _that rate's_ report (append_note with the fresh window) instead of duplicating; a distinct rate on the same insight gets its own pointer and its own report.
+- `report:product_analytics:flow:<short_id>:<rate>` — the `report_id` of a report you authored for a regression on this flow's specific rate (the affected step/cohort/state), so the next run edits _that rate's_ report (`append_evidence` with the fresh window) instead of duplicating; a distinct rate on the same insight gets its own pointer and its own report.
 - `reviewer:product_analytics:<area>` — a resolved owner (bare lowercase GitHub login) for a flow / product area, so reports route to a human faster.
 
 ### Decide
 
 Before you author, check whether this flow already has a report — the `report:product_analytics:flow:<short_id>` scratchpad pointer is the reliable path: it holds the `report_id`, so `inbox-reports-retrieve` it directly. Only with no pointer fall back to an `inbox-reports-list` search (`ordering=-updated_at`), and search the flow's _specific_ terms (its name, the step events, the `short_id`) — a broad word like `funnel` returns hundreds of unrelated reports on a busy project and buries yours. Classify each candidate against prior runs and the scratchpad (net-new / material-update / already-covered / addressed-or-noise), then:
 
-- **Edit** the existing report via `scout-edit-report` when the inbox already covers the flow. A regression is rarely brand-new — a funnel that's still sliding, a retention cliff that deepened, a flow that recovered then relapsed: `append_note` with the fresh window's rate, baseline band, and entrant volumes (or rewrite the title/summary on a report you authored). This is the default when a match exists **and it's still live in the inbox**; don't mint a near-duplicate. **A persistent regression is one report across weeks:** when a new complete window confirms the flow is still below baseline (or has deepened), that's a _re-escalation_ — `append_note` the fresh week onto the report your `report:product_analytics:flow:<short_id>` pointer names and advance the `dedupe:…:<week>` gate; do **not** author a fresh report per week. The same flow moving twice is one report, not two. **But scope the match to the same rate, not just the same `short_id`:** one funnel/retention insight carries several independent rates (step-2 vs step-5 conversion, one retention cohort vs another, one lifecycle state), and a drop on a _different_ step/cohort is its own regression with its own owner — keep the `report:product_analytics:flow:<short_id>` pointer keyed to the affected rate (e.g. `…:flow:<short_id>:step2`) and only `edit-report` when the matched report covers that same rate; a genuinely distinct rate gets a fresh report so it isn't buried under an unrelated thread. **And check the matched report's status first:** `edit-report` can't change status, so appending to a `resolved` / `suppressed` / `failed` report (one that won't surface in the inbox) buries a real relapse under a closed item. When the prior report is no longer live, **author a fresh report** for the relapse and repoint `report:product_analytics:flow:<short_id>` at the new id.
+- **Edit** the existing report via `scout-edit-report` when the inbox already covers the flow. A regression is rarely brand-new — a funnel that's still sliding, a retention cliff that deepened, a flow that recovered then relapsed: use `append_evidence` for the fresh window's rate, baseline band, and entrant volumes (or rewrite the title/summary on a report you authored). This is the default when a match exists **and it's still live in the inbox**; don't mint a near-duplicate. **A persistent regression is one report across weeks:** when a new complete window confirms the flow is still below baseline (or has deepened), that's a _re-escalation_ — add the fresh week with `append_evidence`, and advance the `dedupe:…:<week>` gate. Do **not** author a fresh report per week. The same flow moving twice is one report, not two. **But scope the match to the same rate, not just the same `short_id`:** one funnel/retention insight carries several independent rates (step-2 vs step-5 conversion, one retention cohort vs another, one lifecycle state), and a drop on a _different_ step/cohort is its own regression with its own owner — keep the `report:product_analytics:flow:<short_id>` pointer keyed to the affected rate (e.g. `…:flow:<short_id>:step2`) and only `edit-report` when the matched report covers that same rate; a genuinely distinct rate gets a fresh report so it isn't buried under an unrelated thread. **And check the matched report's status first:** `edit-report` can't change status, so appending to a `resolved` / `suppressed` / `failed` report (one that won't surface in the inbox) buries a real relapse under a closed item. When the prior report is no longer live, **author a fresh report** for the relapse and repoint `report:product_analytics:flow:<short_id>` at the new id.
 - **Author** a fresh report via `scout-emit-report` when nothing in the inbox covers it (or a known regression has new evidence that changes the verdict). A **strong finding** here: the rate dropped clearly below the flow's seasonality-matched baseline (robust z ≥ ~3, or a conversion-point drop beyond the baseline band), the **entrant denominator held** (quantify both — "step-2 conversion 62%→48% while step-1 entrants steady at ~5.2k/day"), the move is broad across segments (not one known cohort), it's not explained by a running experiment or a flow-definition edit, and confidence ≥ 0.8. Put the flow `short_id`, the latest-window rate, the baseline band, the per-step/per-cohort numbers, the entrant volumes, and the time window in the `evidence`. A rate regression is chart-shaped — attach the regressed rate via `charts`, matched to the flow type: a funnel or retention rate with its steady entrant denominator alongside (the drop-on-steady-entrants shape), lifecycle as the state composition over time, stickiness as the frequency distribution against its population. A behavioral regression is an investigation, not a one-line code fix, so set `actionability=requires_human_input` and **leave `priority` and `repository` unset** — they're PR-autostart fields, and supplying `priority` + `suggested_reviewers` with no `repository` signals PR intent that spins up a repo-selection sandbox only to no-op (autostart needs `immediately_actionable`). Reach for them (P2 broad regression on a human-saved flow, P3 single-segment / `inferred`) only on the rare regression you'd actually want a draft PR for. **Set `suggested_reviewers` whenever you can confidently resolve one** — each entry is `{github_login?, user_uuid?}`, and the usual route here is to pass the flow's owning person as a `user_uuid` (a saved insight's `created_by`; the server resolves it to their GitHub login), or reuse a cached `reviewer:product_analytics:<area>` login. **But `user_uuid` resolution is fail-loud: a `created_by` that isn't an org member with a linked GitHub identity (a PM, a customer, a since-departed user) rejects the _whole_ `emit-report`, not just the reviewer.** So don't reflexively hand a raw `created_by` you're unsure about — prefer a cached login or a `created_by` you've already routed; if you can't confidently resolve an owner, author the report **unrouted** and `edit-report` reviewers in later once you resolve one, rather than risk failing the emit. When the owner isn't already a `created_by` in your evidence, `scout-members-list` gives this project's members with their resolved `github_login` (the org-scoped resolver tools aren't available in a scout run). Routing is how the report reaches a human; left empty it's assigned to nobody and likely missed, so resolve one when you safely can. After authoring, write a rate-scoped `report:product_analytics:flow:<short_id>:<rate>` scratchpad entry (the affected step/cohort/state, not just the `short_id`) with the `report_id` so the next run edits _this rate's_ report instead of duplicating — and a distinct rate on the same insight gets its own pointer. The harness prompt carries the full report-channel contract (field schema, safety × actionability status mapping, reviewer routing, the non-idempotency caveat, and the edit rules) — this section only adds the product-analytics-specific framing.
 - **Remember** if suggestive but below the bar (confidence < 0.65), or to refresh a baseline.
 - **Skip** if a `noise:` / `addressed:` / `dedupe:` entry, or an existing inbox report, already covers it.
diff --git a/skills/signals-scout-replay-vision/SKILL.md b/skills/signals-scout-replay-vision/SKILL.md
index daa52ca..4a016ad 100644
--- a/skills/signals-scout-replay-vision/SKILL.md
+++ b/skills/signals-scout-replay-vision/SKILL.md
@@ -186,7 +186,7 @@ Write a scratchpad entry whenever you observe something a future run should know
 - key `noise:replay_vision:old-test-scanner` — _"Scanner 'Old test' (scanner_id abc…) abandoned, ~0 obs since 2026-05-20. Ignore in roster reads."_
 - key `dedupe:replay_vision:frustration-score-regression` — _"Reported scorer regression on 'Frustration' 2026-06-13 (mean 2.1→3.4/5 over the week, 210 sessions). Skip unless it recovers and re-steps."_
 - key `addressed:replay_vision:scanner-health-bundle` — _"Filed watch-gap bundle 2026-06-08 (2 enabled scanners silent on quota exhaustion). Don't re-report unless the silent set changes."_
-- key `report:replay_vision:frustration:score-regression` — the `report_id` of a report you authored for a scanner's aggregate shift, so the next run edits it (`append_note` the fresh window) instead of duplicating.
+- key `report:replay_vision:frustration:score-regression` — the `report_id` of a report you authored for a scanner's aggregate shift, so the next run edits it (`append_evidence` with the fresh window) instead of duplicating.
 - key `reviewer:replay_vision:<area>` — a resolved owner (bare lowercase GitHub login) for a scanner / replay surface, so reports route to a human faster.
 
 By run #5 you should know the live roster, each scanner's baseline output distribution, which scanners are on the push path, and which are dead — so a real shift stands out cheaply.
@@ -195,7 +195,7 @@ By run #5 you should know the live roster, each scanner's baseline output distri
 
 The generic report mechanics — search the inbox first (via the `report:replay_vision:<scanner-slug>` pointer, else an `inbox-reports-list` search on the scanner's _specific_ name, not a broad word like `scanner`), edit-vs-author, the status rules, reviewer routing, non-idempotent dedup, and the `priority` / `repository` / actionability fields — live in the harness prompt and in `authoring-scouts` → `references/report-contract.md`. Do not re-derive them here. This section is only the replay-vision judgment layered on top:
 
-- **Edit** when a still-live report already tracks the same scanner's shift and it's still moving — a `yes`-rate still climbing, a scorer mean still depressed, a tag still concentrating. A persistent aggregate shift is one report across runs: a fresh complete week confirming it's ongoing is a re-escalation (`append_note` the new rate/score and session count), not a new report per tick.
+- **Edit** when a still-live report already tracks the same scanner's shift and it is still moving — a `yes`-rate still climbing, a scorer mean still depressed, a tag still concentrating. A persistent aggregate shift is one report across runs: a fresh complete week confirming it is ongoing is a re-escalation (`append_evidence` with the new rate/score and session count), not a new report per tick.
 - **Author** a fresh report only when nothing live covers the shift. A report-worthy finding names the scanner and its type, quantifies the **aggregate** shift against the scanner's _own_ baseline (rate/score before vs after, distinct sessions, the dated onset), attaches the matching series via `charts` (the `yes`-rate, mean score, or tag share over time for an output shift; observation throughput with recording volume alongside for a watch gap, since failed or ineligible runs emit no `$recording_observed` to rate) so the shift is visible, links 2–3 example recordings, and — for anything touching an `emits_signals` scanner or a session-replay / error-tracking surface — cites the overlapping inbox report. These are watcher findings, not code fixes → `actionability=requires_human_input` + `repository=NO_REPO`. Priority: a high-value scanner fully silent or a clear aggregate regression on a key flow is **P2**; scanner-health bundles and minor trends **P3**; FYI themes **P4**. After authoring, write the `report:replay_vision:<scanner-slug>` pointer with the `report_id`.
 - **Remember** if below the bar but worth carrying forward (a rate drifting inside the noise band, a new scanner accruing its first baseline, a single-session storm), or to record what you ruled out.
 - **Skip** with a one-line note if a `noise:` / `addressed:` / `dedupe:` entry, or an existing inbox report, covers it, or if it's a per-session fact the push path already owns.
diff --git a/skills/signals-scout-revenue-analytics/SKILL.md b/skills/signals-scout-revenue-analytics/SKILL.md
index 04c98ad..58fb7d3 100644
--- a/skills/signals-scout-revenue-analytics/SKILL.md
+++ b/skills/signals-scout-revenue-analytics/SKILL.md
@@ -146,7 +146,7 @@ By run #5 the scratchpad knows the team's revenue config, currency mix, which da
 
 Before you author, check whether this source / metric already has a report — the `report:revenue_analytics:<entity>` scratchpad pointer is the reliable path: it holds the `report_id`, so `inbox-reports-retrieve` it directly. With no pointer, fall back to an `inbox-reports-list` search (`ordering=-updated_at`) on the source label / metric / dashboard id. Then, for each candidate:
 
-- **Edit** the existing report via `scout-edit-report` when the inbox already covers the source or metric. A revenue issue is rarely brand-new — a Stripe source still failing, a revenue event still depressed: `append_note` with the fresh status and the revenue-specific impact (which metrics are wrong, by how much), or rewrite the title/summary on a report you authored. This is the default when a match exists **and it's still live**; don't mint a near-duplicate. **Check the matched report's status first:** `edit-report` can't change status, so appending to a `resolved` / `suppressed` / `failed` report buries a real relapse — when the prior report is no longer live, author a fresh report and repoint `report:revenue_analytics:<entity>` at the new id. If a warehouse-source failure report already exists (filed by the data-warehouse scout or the pipeline), `append_note` the revenue angle onto it rather than authoring a parallel report for the same upstream failure.
+- **Edit** the existing report via `scout-edit-report` when the inbox already covers the source or metric. A revenue issue is rarely brand-new — a Stripe source still failing, a revenue event still depressed: use `append_evidence` for the fresh status and the revenue-specific impact (which metrics are wrong, by how much), or rewrite the title/summary on a report you authored. This is the default when a match exists **and it's still live**; don't mint a near-duplicate. **Check the matched report's status first:** `edit-report` can't change status, so appending to a `resolved` / `suppressed` / `failed` report buries a real relapse — when the prior report is no longer live, author a fresh report and repoint `report:revenue_analytics:<entity>` at the new id. If a warehouse-source failure report already exists (filed by the data-warehouse scout or the pipeline), `append_note` the revenue angle onto it rather than authoring a parallel report for the same upstream failure.
 - **Author** a fresh report via `scout-emit-report` when nothing live in the inbox covers it. A **strong finding** here: confidence ≥ 0.85, with concrete dashboard ids, source labels, view names, and quantified impact in the `evidence` (which finance metric is wrong, by how much, who reads it). When the finding is a metric move — an MRR step, a revenue cliff — rather than a config gap, attach the affected series via `charts` so the step and its onset are visible. A revenue finding is almost always an investigation, not a one-line code fix — the recovery action for a failing source lives in the warehouse, not a code PR — so set `actionability=requires_human_input` and leave `priority` / `repository` unset. **Set `suggested_reviewers`** — resolve the owning person with `scout-members-list` (each member carries a resolved `github_login`; cache it under a `reviewer:revenue_analytics:<area>` key), or pass a `{user_uuid}` when your evidence already names the owner. It's how the report reaches a human; left empty it's assigned to nobody and likely missed. After authoring, write a `report:revenue_analytics:<entity>` scratchpad entry with the `report_id` so the next run edits it instead of duplicating.
 - **Remember** via `scout-scratchpad-remember` if it's below the bar but worth carrying forward, or to record what you ruled out and why.
 - **Skip** with a one-line note if a scratchpad entry with a `noise:` / `addressed:` / `dedupe:` key prefix, or an existing inbox report, already covers it.
diff --git a/skills/signals-scout-session-replay/SKILL.md b/skills/signals-scout-session-replay/SKILL.md
index ed83b23..ea0fe62 100644
--- a/skills/signals-scout-session-replay/SKILL.md
+++ b/skills/signals-scout-session-replay/SKILL.md
@@ -239,7 +239,7 @@ Write a scratchpad entry whenever you observe something a future run should know
 - key `noise:session-replay:editor-canvas` — _"/editor is a drag-and-drop canvas; rapid same-spot clicks are normal use, not rage — require console errors to investigate."_
 - key `dedupe:session-replay:checkout-rageclick` — _"Filed a friction cluster on /checkout 'Pay now' 2026-06-10 (9/day → 110/day, 23 persons). Skip unless it recovers and re-spikes."_
 - key `addressed:session-replay:scanner-health` — _"Filed a scanner watch-gap bundle 2026-06-08. Don't re-file unless the failing set changes."_
-- key `report:session-replay:<surface>` — the `report_id` of a report you filed for a cliff or friction cluster on this surface (a URL/element, or the scanner-health bundle), so the next run edits it (append_note with the fresh window) instead of duplicating.
+- key `report:session-replay:<surface>` — the `report_id` of a report you filed for a cliff or friction cluster on this surface (a URL/element, or the scanner-health bundle), so the next run edits it (`append_evidence` with the fresh window) instead of duplicating.
 - key `reviewer:session-replay:<area>` — a resolved owner (bare lowercase GitHub login) for a page / flow / platform surface, so reports route to a human faster.
 
 By run #5 you should know the capture ratio and its rhythm, the friction watchlist with per-URL baselines, which surfaces are noisy by design, the scanner roster, and who owns each surface — so a real step-change stands out immediately and cheaply.
@@ -248,7 +248,7 @@ By run #5 you should know the capture ratio and its rhythm, the friction watchli
 
 The generic report mechanics — search the inbox first (via the `report:session-replay:<surface>` pointer, else an `inbox-reports-list` search on the surface's _specific_ terms, not a broad word like `rageclick`), edit-vs-author, the status rules, reviewer routing, non-idempotent dedup, and the `priority` / `repository` fields — live in the harness prompt and in `authoring-scouts` → `references/report-contract.md`. Do not re-derive them here. This section is only the session-replay judgment layered on top:
 
-- **Edit** when a still-live report already tracks the surface — a capture cliff still unrecovered, a friction cluster still spiking, a scanner still dark. A persistent cliff or cluster is one report across runs: a new window confirming it's ongoing is a re-escalation (`append_note` the fresh recording counts / rates), not a fresh report per tick.
+- **Edit** when a still-live report already tracks the surface — a capture cliff still unrecovered, a friction cluster still spiking, a scanner still dark. A persistent cliff or cluster is one report across runs: a new window confirming it is ongoing is a re-escalation (`append_evidence` with the fresh recording counts / rates), not a fresh report per tick.
 - **Author** when nothing live covers the surface. A report-worthy finding names the surface (URL and element, or the affected scanner set), quantifies the step against its own baseline (rate before/after, sessions, persons), passes the volume gates, dates the onset, and links 2–3 example recordings in the `evidence`. Attach the shape via `charts` — recordings vs site traffic for a capture cliff, the surface's friction-rate series for a cluster — so the step and its onset are visible. These are investigations, not code fixes → `actionability=requires_human_input`. Priority: a confirmed **capture cliff** is **P1–P2** (recordings are not retroactive — data loss compounds every day unfixed); a corroborated friction cluster or broken-experience cohort on a key flow is **P2**; scanner watch-gaps and friction on minor surfaces are **P3**.
 - **Remember** if it's below the bar but worth carrying forward (a URL drifting upward inside the noise band, a new page accumulating its first baseline, a single-person storm worth re-checking), or to record what you ruled out and why.
 - **Skip** with a one-line note if a `noise:` / `addressed:` / `dedupe:` entry, or an existing inbox report, already covers it.
diff --git a/skills/signals-scout-skills-store/SKILL.md b/skills/signals-scout-skills-store/SKILL.md
index 7ef4082..18d8afd 100644
--- a/skills/signals-scout-skills-store/SKILL.md
+++ b/skills/signals-scout-skills-store/SKILL.md
@@ -129,7 +129,7 @@ Encode the category in the key prefix; rewrite a key to update in place.
 - key `pattern:skills_store:high-leverage` — _"Top tier: deploy-runbook (42 loads/30d), querying-our-dwh (v11 in 3 weeks), incident-response (referenced by 4 skills). Ranked via usage events."_
 - key `pattern:skills_store:last-deep-pass` — _"Deep pass ran 2026-06-25, audited 5 of the high-leverage tier (through incident-response). Next due after 2026-07-02."_
 - key `dedupe:skills_store:<skill-name>` — _"2026-06-30: filed P3 report on `deploy-runbook` v7 — dead link references/rollback.md, body 1.4k lines. Skip until version > 7."_ One stable key per skill — update it in place, don't mint a dated variant.
-- key `report:skills_store:<skill-name>` — _"Report `019f0a96-…` covers `deploy-runbook`'s hygiene violations. Edit it (append_note the recheck) while the skill stays broken and the report is live; if it was resolved and the skill later regresses, that's a fresh report."_
+- key `report:skills_store:<skill-name>` — _"Report `019f0a96-…` covers `deploy-runbook`'s hygiene violations. Edit it (`append_evidence` with the recheck) while the skill stays broken and the report is live; if it was resolved and the skill later regresses, that's a fresh report."_
 - key `reviewer:skills_store:<skill-name>` — _"`deploy-runbook` reports route to its author `alice` (user_uuid from skill-get created_by)."_
 - key `addressed:skills_store:<skill-name>` — _"2026-07-04: `deploy-runbook` v9 recheck clean. Don't re-flag."_
 - key `noise:skills_store:<skill-name>` — _"`sql-cookbook` intentionally long (a cookbook by design, team confirmed via dismissal). Not a body-size violation."_
@@ -142,7 +142,7 @@ For each non-compliant skill, the call is **edit an existing report, author a ne
   The `report:skills_store:<skill-name>` scratchpad pointer is the reliable path (it holds the `report_id` — `inbox-reports-retrieve` it directly); with no pointer, `inbox-reports-list` searching the skill name.
   A skill with a live report and no new violations since the version you reported is a **skip**.
 - **Edit** (`scout-edit-report`) when a still-live report already covers the skill — it's still broken at a newer version, or picked up additional violations.
-  `append_note` the recheck (version judged, which violations persist / were fixed / are new), or rewrite the title/summary on a report you authored when the violation set materially changed.
+  Add the recheck with `append_evidence` (version judged, which violations persist / were fixed / are new), or rewrite the title/summary on a report you authored when the violation set materially changed.
   `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — a regressed skill gets a fresh report and a repointed `report:` key.
 - **Author** (`scout-emit-report`) only when no live report covers the skill — **one report per skill**, bundling every violated rule (confidence ≥ 0.65; most static checks land 0.85–0.95 because they're mechanical).
   A good report names the skill (linking `/llm-analytics/skills/<name>` — the name, not the UUID), lists each violated rule with the offending field/line and the rule it breaks in the summary, cites them in `evidence`, and gives the concrete fix — these are directly agent-fixable via `skill-update`, so make the fix copy-ready.
diff --git a/skills/signals-scout-surveys/SKILL.md b/skills/signals-scout-surveys/SKILL.md
index 7b821e1..36ba24e 100644
--- a/skills/signals-scout-surveys/SKILL.md
+++ b/skills/signals-scout-surveys/SKILL.md
@@ -212,7 +212,7 @@ Memory is a continuous activity. Write a scratchpad entry whenever you observe s
 - key `noise:surveys:feedback-modal` — _"`feedback-modal` exit-intent survey naturally has 70% dismiss rate — that's expected behavior for this trigger, not a regression."_
 - key `addressed:surveys:theme-checkout-step-2-2026-05-04` — _"Theme `checkout-step-2-confusion` raised in run on 2026-04-30; team acknowledged, fix shipped 2026-05-04. Don't re-file unless theme reappears post-2026-05-04."_
 - key `addressed:surveys:csat-old-stale` — _"Survey `csat-old` last got responses 2026-02; appears abandoned but the team still has it active. P3 recommendation already filed; don't re-recommend."_
-- key `report:surveys:theme-checkout-step-2` — _"Authored report `019f0a96-…` for the checkout-step-2 confusion theme on 2026-06-30. Edit it (append_note) if the theme grows or recurs rather than filing a new one."_
+- key `report:surveys:theme-checkout-step-2` — _"Authored report `019f0a96-…` for the checkout-step-2 confusion theme on 2026-06-30. Edit it (`append_evidence`) if the theme grows or recurs rather than filing a new one."_
 - key `reviewer:surveys:nps-q1-2026` — _"`nps-q1-2026` owned by `alice` (GitHub login) — route its reports there."_
 
 By run #5 you'll know the team's active surveys, healthy response volumes, score baselines, which dismiss rates are structural, which themes have already been raised, which report covers a theme, and who owns it — so when a real theme or regression appears, the report lands with the right context already attached.
@@ -221,7 +221,7 @@ By run #5 you'll know the team's active surveys, healthy response volumes, score
 
 Search the inbox before you author — a report covering this theme / survey / regression may already exist (`inbox-reports-list` with `ordering=-updated_at`, then `inbox-reports-retrieve` the closest matches). Then, for each candidate finding:
 
-- **Edit** the existing report via `scout-edit-report` when the inbox already covers the theme or survey. A theme that's growing, a regression that's deepening, a later iteration's responses confirming an earlier read: `append_note` with the fresh response counts, score deltas, and time range (or rewrite the title/summary on a report you authored). This is the default when a match exists; don't mint a near-duplicate.
+- **Edit** the existing report via `scout-edit-report` when the inbox already covers the theme or survey. A theme that's growing, a regression that's deepening, a later iteration's responses confirming an earlier read: use `append_evidence` for the fresh response counts, score deltas, and time range (or rewrite the title/summary on a report you authored). This is the default when a match exists; don't mint a near-duplicate.
 - **Author** a fresh report via `scout-emit-report` when nothing in the inbox covers it. The natural fits are a single validated theme (≥ 5 converging respondents, with 2–3 verbatim quotes — no PII) or one survey's score / response-rate / abandonment regression that clears the tiered bar, with concrete survey ids, question ids, response counts, and score deltas as evidence (the bar is confidence ≥ 0.85; sample-size matters more here than other domains — a report on 10 responses needs to be tighter than one on 200). A score or response-rate regression is chart-shaped — attach the survey's trend via `charts` so the drop against its own baseline is visible; a theme lives in its quotes, not a chart. A survey finding is an investigation, not a one-line code fix, so default to `requires_human_input`. **Always set `suggested_reviewers`** — resolve the owning person with `scout-members-list` (each member carries a resolved `github_login`; cache it under a `reviewer:surveys:<survey>` key). It's how the report reaches a human; left empty, the report is assigned to nobody and is likely missed. After authoring, write a `report:surveys:<theme-or-survey>` scratchpad entry with the `report_id` so the next run edits it instead of duplicating. The harness prompt carries the full report-channel contract (field schema, safety × actionability status mapping, reviewer routing, the non-idempotency caveat, and the edit rules) — this section only adds the surveys-specific framing.
 - **Remember** via `scout-scratchpad-remember` if below the bar but worth carrying forward (a theme with only 3 respondents that might grow, a score wobble that didn't yet hold for two weeks), or to record what you ruled out and why.
 - **Skip** with a one-line note if a scratchpad entry with a `noise:` or `addressed:` key prefix, or an existing inbox report, already covers it.
diff --git a/skills/signals-scout-tasks/SKILL.md b/skills/signals-scout-tasks/SKILL.md
index 9d35e58..a39d38c 100644
--- a/skills/signals-scout-tasks/SKILL.md
+++ b/skills/signals-scout-tasks/SKILL.md
@@ -202,7 +202,7 @@ Author / edit / remember / skip, against the four-states classifier:
 
 - **Search the inbox first.**
   The `report:tasks:<cluster>` pointer is the reliable path (retrieve the id directly); with no pointer, `inbox-reports-list` by repository name _and_ by the failure class.
-- **Edit** (`scout-edit-report`) when a live report covers the cluster and it's still failing — `append_note` the fresh rate, volume, and any newly-affected repos.
+- **Edit** (`scout-edit-report`) when a live report covers the cluster and it is still failing — add the fresh rate, volume, and newly affected repositories with `append_evidence`.
   This is the default when a match exists.
   `edit-report` can't change status, so a `resolved` / `suppressed` match means authoring fresh for the relapse and repointing the key.
 - **Cite a concrete run.** The lens-A queries aggregate, so they return no ids to quote. Before filing, run cookbook query 9 narrowed to the cluster for a representative `task_id` + `run_id` pair, and use those in the `evidence` (and for `tasks-runs-retrieve` if you want one worked example).
diff --git a/skills/signals-scout-web-analytics/SKILL.md b/skills/signals-scout-web-analytics/SKILL.md
index 35c2250..16a3b3e 100644
--- a/skills/signals-scout-web-analytics/SKILL.md
+++ b/skills/signals-scout-web-analytics/SKILL.md
@@ -241,7 +241,7 @@ Write a scratchpad entry whenever you observe something a future run should know
 - key `pattern:web-analytics:send-day-rhythm` — _"Newsletter channel spikes 4–6× every Tuesday (send day) and decays over 48h. Not a surge finding."_
 - key `noise:web-analytics:dev-hosts` — _"localhost:_ and _.staging._ appear in referrers and entry hosts — internal traffic, exclude from all candidate math."\*
 - key `dedupe:web-analytics:organic-search-cliff` — _"Filed report on Organic Search divergence 2026-06-09 (42k/day → 18k/day vs both aligned windows, concentrated on www.google.com). Skip unless it recovers and re-cliffs."_ One stable key per segment — update it in place, don't mint a dated variant.
-- key `report:web-analytics:organic-search-cliff` — _"Report `019f0a96-…` covers the Organic Search divergence. Edit it (append_note the fresh window) while it persists and the report is still live; if it was resolved and the channel later re-cliffs, that's a fresh report."_
+- key `report:web-analytics:organic-search-cliff` — _"Report `019f0a96-…` covers the Organic Search divergence. Edit it (`append_evidence` with the fresh window) while it persists and the report is still live; if it was resolved and the channel later re-cliffs, that's a fresh report."_
 - key `reviewer:web-analytics:marketing-site` — _"Marketing-site / acquisition reports route to `alice` (GitHub login)."_
 - key `addressed:web-analytics:utm-strip-2026-06` — _"Team confirmed consent banner was stripping UTMs (reported 2026-06-02, fixed 2026-06-04). Tagged share back to ~9%. Don't re-file the historical window."_
 
@@ -252,7 +252,7 @@ By run #5 you should know the weekday rhythm, the per-channel baselines, the sen
 For each candidate, the call is **edit an existing report, author a new one, remember, or skip** — use judgment, these are the rails:
 
 - **Search the inbox first.** The `report:web-analytics:<segment-slug>` scratchpad pointer is the reliable path (it holds the `report_id` — `inbox-reports-retrieve` it directly); with no pointer, `inbox-reports-list` by the segment's specific terms (the channel name, path, referrer domain, or campaign — `ordering=-updated_at`), never a broad word like `traffic`. A segment with a live report and no material change is a **skip**.
-- **Edit** (`scout-edit-report`) when a still-live report already covers the same segment problem — the channel still diverging, the tagged share still depressed, the 404 spike still running. `append_note` the fresh window's numbers (the 24h value against both aligned windows, deepening or recovering), or rewrite the title/summary on a report you authored. This is the default when a match exists — a divergence persisting across runs is one report across weeks, not one per run. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key.
+- **Edit** (`scout-edit-report`) when a still-live report already covers the same segment problem — the channel still diverging, the tagged share still depressed, the 404 spike still running. Add the fresh window's numbers with `append_evidence` (the 24h value against both aligned windows) while the divergence deepens or holds. Add a recovery with `append_note`, because the evidence counters only grow. Rewrite the title/summary on a report you authored. This is the default when a match exists — a divergence persisting across runs is one report across weeks, not one per run. `edit-report` can't change status, so if the matched report is `resolved` / `suppressed` / `failed`, don't append (it won't resurface) — author a fresh report for the relapse and repoint the `report:` key.
 - **Author** (`scout-emit-report`) only when nothing live covers it — one report per segment divergence, never one per query row. A **report-worthy finding** (confidence ≥ 0.8): names the segment (channel, path, referrer, campaign), quantifies the step against both aligned windows, shows the aggregate held (that's what makes it yours), dates the onset, and names the moving part inside the segment — with the numbers in the `evidence`. Below that bar, write memory instead. The divergence-on-steady-aggregate shape is the argument, so show it — attach the segment's daily series (with the aggregate alongside) via `charts`. The fix for a web-analytics finding almost always lives in the team's site, campaign tooling, or marketing stack — territory you can't open a PR against — so default to `actionability=requires_human_input` and `repository=NO_REPO` (NO_REPO is what stops `priority`+reviewers from spawning a pointless repo-selection sandbox).
   Because you default to a human handoff, the handoff must be explicit in the summary: who acts (the site, marketing, or campaign owner — name the surface), the exact change or check to make, and a success criterion — the metric, the target value or return-to-baseline level, and the re-measure window.
   A report that says "review the page" without those three is below the bar; hold it back and gather the missing piece instead.
diff --git a/skills/signals-scout-web-vitals/SKILL.md b/skills/signals-scout-web-vitals/SKILL.md
index a4d896e..9899470 100644
--- a/skills/signals-scout-web-vitals/SKILL.md
+++ b/skills/signals-scout-web-vitals/SKILL.md
@@ -405,7 +405,7 @@ the category in the key prefix — `pattern:`, `noise:`, `addressed:`, `dedupe:`
   page later re-crosses."_ One stable key per host+path+metric — update it in place,
   don't mint a dated variant.
 - key `report:web_vitals:checkout-inp` — _"Report `019f0a96-…` covers the `/checkout`
-  INP finding. Edit it (append_note the fresh p75 + sample count) while the page stays
+  INP finding. Edit it (`append_evidence` with the fresh p75 + sample count) while the page stays
   slow and the report is still live and not scope-frozen; if it closed (or shipped its
   fix — `ready` with an open or merged implementation PR) and the page later re-crosses,
   that's a fresh report."_
@@ -430,8 +430,10 @@ For each candidate, the call is **edit an existing report, author a new one, rem
   A page with a live report and no material change is a **skip**.
 - **Edit** (`scout-edit-report`) when a still-live report already covers the same
   page+metric problem — the page still standing in `poor`, the regression still holding,
-  the p75 deepening or recovering. `append_note` the fresh window's numbers (p75, band,
-  sample count), or rewrite the title/summary on a report you authored. This is the
+  the p75 deepening or recovering. Add the fresh window's numbers with `append_evidence` (p75, band,
+  sample count) while the page stays slow. Add a recovery with `append_note`, because the evidence
+  counters only grow and would rank a recovered report as stronger. Rewrite the title/summary on a
+  report you authored. This is the
   default when a match exists — a chronically slow page is one report across weeks, not
   one per run. `edit-report` can't change status, so if the matched report is `resolved` /
   `suppressed` / `failed`, don't append (it won't resurface) — and a `ready` report whose
diff --git a/skills/understanding-billing-usage/references/usage-type-routing.md b/skills/understanding-billing-usage/references/usage-type-routing.md
index 2399cf6..c30b0d3 100644
--- a/skills/understanding-billing-usage/references/usage-type-routing.md
+++ b/skills/understanding-billing-usage/references/usage-type-routing.md
@@ -28,31 +28,32 @@ Useful downstream skills for usage investigations include:
 - `posthog:exploring-replay-vision-observations` when Replay Vision credits point to scanner
   observations.
 
-| Usage type                                        | What Billing can show                                                | Customer-visible follow-up                                                                                                                                                                                                                                                                     |
-| ------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `event_count_in_period`                           | Events by day/project                                                | Use `posthog:investigate-metric` or Product Analytics SQL/insight tools on the affected project. Break down by event name and compare the alert/high-usage day to baseline days. If `$autocapture` dominates, continue with `posthog:exploring-autocapture-events`.                            |
-| `enhanced_persons_event_count_in_period`          | Identified events by day/project                                     | Start like Events, using `posthog:investigate-metric` when available, but avoid claiming the raw event-name breakdown exactly explains the identified/anonymous split unless that dimension is visible.                                                                                        |
-| `group_analytics`                                 | Group Analytics spend/usage attribution using identified-event usage | Treat as an alias-style product view. Use identified-event/Product Analytics drilldown, usually via `posthog:investigate-metric`, and explain that the Billing view is product-specific attribution, not a separate raw event stream.                                                          |
-| `recording_count_in_period`                       | Session recordings by day/project                                    | Use Session Replay tools or the Replay UI for recording volume, SDK/platform filters, and representative sessions. Use `posthog:investigating-replay` only after you have representative recording/session IDs.                                                                                |
-| `mobile_recording_count_in_period`                | Mobile recordings by day/project                                     | Use Session Replay/mobile replay surfaces. Look for mobile SDK/platform mix before suggesting product changes. Use `posthog:investigating-replay` only after you have representative mobile recording/session IDs.                                                                             |
-| `billable_feature_flag_requests_count_in_period`  | Feature flag requests by day/project                                 | Use feature flag tools, flag configuration, and activity history. The billable unit is flag evaluation/API request volume, not `$feature_flag_called` events. Do not use stale-flag cleanup workflows unless the user asks how to remove unused flags.                                         |
-| `exceptions_captured_in_period`                   | Exceptions by day/project                                            | Use Error Tracking issue tools and `$exception` aggregates in the affected project. If one issue dominates the movement, use `posthog:investigating-error-issue`. UI issue counts are grouped context, while Billing usage is captured exception volume.                                       |
-| `survey_responses_count_in_period`                | Survey responses by day/project                                      | Use survey tools and survey events such as `survey shown` and `survey sent` to distinguish reach from response-rate changes. Use `posthog:debugging-surveys` when the investigation turns into "why is this survey showing, not showing, or getting fewer/more responses than expected?"       |
-| `ai_event_count_in_period`                        | AI Observability events by day/project                               | Use AI Observability tools or SQL over `$ai_*` events in the affected project. Break down by provider/model/trace/user only when those properties are available. Use `posthog:exploring-llm-costs` for cost-shaped questions and `posthog:analyzing-expensive-users` for user-level drivers.   |
-| `ai_credits_used_in_period`                       | PostHog AI credits by day/project                                    | Use PostHog AI or AI Observability surfaces exposed to the user. Prefer `posthog:exploring-llm-costs` for credit/spend movement and `posthog:analyzing-expensive-users` for concentrated user drivers. Do not inspect internal PostHog-owned AI telemetry in a customer-facing investigation.  |
-| `signals_credits_used_in_period`                  | Inbox credits by day/project                                         | Use Signals/Inbox product tools when available. Start with `posthog:inbox-exploration` for report-level context; use `posthog:signals` only when raw signal search is needed. Billing shows chargeable credit movement; product tools should explain reports/PRs/refunds.                      |
-| `posthog_code_credits_used_in_period`             | PostHog Desktop credits by day/project                               | Use PostHog Desktop usage surfaces when available. Treat token credits and sandbox compute as possible sub-drivers if exposed.                                                                                                                                                                 |
-| `posthog_code_token_credits_used_in_period`       | PostHog Desktop token credits by day/project                         | Use PostHog Desktop/AI usage surfaces when available.                                                                                                                                                                                                                                          |
-| `sandbox_compute_credits_used_in_period`          | Sandbox compute credits by day/project                               | Use task/sandbox/PostHog Desktop surfaces when available.                                                                                                                                                                                                                                      |
-| `sandbox_compute_cpu_millicore_seconds_in_period` | Sandbox CPU usage by day/project                                     | Use task/sandbox surfaces when available. This is a raw usage diagnostic, not usually the headline spend type.                                                                                                                                                                                 |
-| `sandbox_compute_memory_mib_seconds_in_period`    | Sandbox memory usage by day/project                                  | Use task/sandbox surfaces when available. This is a raw usage diagnostic, not usually the headline spend type.                                                                                                                                                                                 |
-| `rows_synced_in_period`                           | Data Warehouse synced rows by day/project                            | Use Data Warehouse source/schema health and sync tools. Look for new sources, enabled schemas, failed/stale syncs, or expected backfills. Use `posthog:auditing-warehouse-source-health` for a project-wide scan and `posthog:diagnosing-failed-warehouse-syncs` for a specific source/schema. |
-| `free_historical_rows_synced_in_period`           | Historical synced rows by day/project                                | Use Data Warehouse source/schema tools. Explain it as historical sync activity, not ongoing incremental volume. Use `posthog:auditing-warehouse-source-health` or `posthog:diagnosing-failed-warehouse-syncs` if a source or schema needs investigation.                                       |
-| `rows_exported_in_period`                         | Batch export rows by day/project                                     | Use batch export/CDP export tools and export configuration. Check newly enabled exports or changed destinations.                                                                                                                                                                               |
-| `data_pipelines`                                  | Legacy Data Pipelines product attribution                            | Treat as a legacy/synthetic product view. Use the Product Analytics or CDP surface that actually produced the usage, depending on the user's context.                                                                                                                                          |
-| `cdp_billable_invocations_in_period`              | Realtime destination trigger events by day/project                   | Use CDP function tools: list functions, inspect enabled destinations, metrics, and logs for the affected window.                                                                                                                                                                               |
-| `workflow_emails_sent_in_period`                  | Workflow emails by day/project                                       | Use Workflows tools: workflow stats, invocation logs, enabled workflows, and recent changes.                                                                                                                                                                                                   |
-| `workflow_billable_invocations_in_period`         | Workflow destination dispatches by day/project                       | Use Workflows tools and destination/invocation logs. Keep it separate from email volume.                                                                                                                                                                                                       |
-| `logs_mb_in_period`                               | Logs ingested in MB by day/project                                   | Use `posthog:investigating-logs` with Logs tools: service overview, count ranges, facets, and pattern diffs. Prefer log-specific tools over raw SQL.                                                                                                                                           |
-| `logs_retention_30d_mb_in_period`                 | Logs ingested under 30-day retention by day/project                  | Use `posthog:investigating-logs` with Logs tools and retention/settings surfaces. Explain that this is retention-tier usage, not separate log content.                                                                                                                                         |
-| `replay_vision_credits_used_in_period`            | Replay Vision credits by day/project                                 | Use Replay Vision scanner/observation tools. Credits come from scanner observations, so inspect scanners and observation status/results. Use `posthog:exploring-replay-vision-observations` when scanner observations are the natural drilldown.                                               |
+| Usage type                                        | What Billing can show                                                                | Customer-visible follow-up                                                                                                                                                                                                                                                                     |
+| ------------------------------------------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `event_count_in_period`                           | Events by day/project                                                                | Use `posthog:investigate-metric` or Product Analytics SQL/insight tools on the affected project. Break down by event name and compare the alert/high-usage day to baseline days. If `$autocapture` dominates, continue with `posthog:exploring-autocapture-events`.                            |
+| `enhanced_persons_event_count_in_period`          | Identified events by day/project                                                     | Start like Events, using `posthog:investigate-metric` when available, but avoid claiming the raw event-name breakdown exactly explains the identified/anonymous split unless that dimension is visible.                                                                                        |
+| `group_analytics`                                 | Group Analytics spend/usage attribution using identified-event usage                 | Treat as an alias-style product view. Use identified-event/Product Analytics drilldown, usually via `posthog:investigate-metric`, and explain that the Billing view is product-specific attribution, not a separate raw event stream.                                                          |
+| `recording_count_in_period`                       | Session recordings by day/project                                                    | Use Session Replay tools or the Replay UI for recording volume, SDK/platform filters, and representative sessions. Use `posthog:investigating-replay` only after you have representative recording/session IDs.                                                                                |
+| `mobile_recording_count_in_period`                | Mobile recordings by day/project                                                     | Use Session Replay/mobile replay surfaces. Look for mobile SDK/platform mix before suggesting product changes. Use `posthog:investigating-replay` only after you have representative mobile recording/session IDs.                                                                             |
+| `billable_feature_flag_requests_count_in_period`  | Feature flag requests by day/project                                                 | Use feature flag tools, flag configuration, and activity history. The billable unit is flag evaluation/API request volume, not `$feature_flag_called` events. Do not use stale-flag cleanup workflows unless the user asks how to remove unused flags.                                         |
+| `exceptions_captured_in_period`                   | Exceptions by day/project                                                            | Use Error Tracking issue tools and `$exception` aggregates in the affected project. If one issue dominates the movement, use `posthog:investigating-error-issue`. UI issue counts are grouped context, while Billing usage is captured exception volume.                                       |
+| `survey_responses_count_in_period`                | Survey responses by day/project                                                      | Use survey tools and survey events such as `survey shown` and `survey sent` to distinguish reach from response-rate changes. Use `posthog:debugging-surveys` when the investigation turns into "why is this survey showing, not showing, or getting fewer/more responses than expected?"       |
+| `ai_event_count_in_period`                        | AI Observability events by day/project                                               | Use AI Observability tools or SQL over `$ai_*` events in the affected project. Break down by provider/model/trace/user only when those properties are available. Use `posthog:exploring-llm-costs` for cost-shaped questions and `posthog:analyzing-expensive-users` for user-level drivers.   |
+| `ai_credits_used_in_period`                       | PostHog AI credits by day/project                                                    | Use PostHog AI or AI Observability surfaces exposed to the user. Prefer `posthog:exploring-llm-costs` for credit/spend movement and `posthog:analyzing-expensive-users` for concentrated user drivers. Do not inspect internal PostHog-owned AI telemetry in a customer-facing investigation.  |
+| `signals_credits_used_in_period`                  | Inbox credits by day/project                                                         | Use Signals/Inbox product tools when available. Start with `posthog:inbox-exploration` for report-level context; use `posthog:signals` only when raw signal search is needed. Billing shows chargeable credit movement; product tools should explain reports/PRs/refunds.                      |
+| `posthog_code_credits_used_in_period`             | PostHog Desktop credits by day/project                                               | Use PostHog Desktop usage surfaces when available. Treat token credits and sandbox compute as possible sub-drivers if exposed.                                                                                                                                                                 |
+| `posthog_code_token_credits_used_in_period`       | PostHog Desktop token credits by day/project                                         | Use PostHog Desktop/AI usage surfaces when available.                                                                                                                                                                                                                                          |
+| `sandbox_compute_credits_used_in_period`          | Sandbox compute credits by day/project                                               | Use task/sandbox/PostHog Desktop surfaces when available.                                                                                                                                                                                                                                      |
+| `sandbox_compute_cpu_millicore_seconds_in_period` | Sandbox CPU usage by day/project                                                     | Use task/sandbox surfaces when available. This is a raw usage diagnostic, not usually the headline spend type.                                                                                                                                                                                 |
+| `sandbox_compute_memory_mib_seconds_in_period`    | Sandbox memory usage by day/project                                                  | Use task/sandbox surfaces when available. This is a raw usage diagnostic, not usually the headline spend type.                                                                                                                                                                                 |
+| `rows_synced_in_period`                           | Data Warehouse synced rows by day/project                                            | Use Data Warehouse source/schema health and sync tools. Look for new sources, enabled schemas, failed/stale syncs, or expected backfills. Use `posthog:auditing-warehouse-source-health` for a project-wide scan and `posthog:diagnosing-failed-warehouse-syncs` for a specific source/schema. |
+| `free_historical_rows_synced_in_period`           | Historical synced rows by day/project                                                | Use Data Warehouse source/schema tools. Explain it as historical sync activity, not ongoing incremental volume. Use `posthog:auditing-warehouse-source-health` or `posthog:diagnosing-failed-warehouse-syncs` if a source or schema needs investigation.                                       |
+| `rows_exported_in_period`                         | Batch export rows by day/project                                                     | Use batch export/CDP export tools and export configuration. Check newly enabled exports or changed destinations.                                                                                                                                                                               |
+| `data_pipelines`                                  | Legacy Data Pipelines product attribution                                            | Treat as a legacy/synthetic product view. Use the Product Analytics or CDP surface that actually produced the usage, depending on the user's context.                                                                                                                                          |
+| `cdp_billable_invocations_in_period`              | Realtime destination trigger events by day/project                                   | Use CDP function tools: list functions, inspect enabled destinations, metrics, and logs for the affected window.                                                                                                                                                                               |
+| `workflow_emails_sent_in_period`                  | Workflow emails by day/project                                                       | Use Workflows tools: workflow stats, invocation logs, enabled workflows, and recent changes.                                                                                                                                                                                                   |
+| `workflow_billable_invocations_in_period`         | Workflow destination dispatches by day/project                                       | Use Workflows tools and destination/invocation logs. Keep it separate from email volume.                                                                                                                                                                                                       |
+| `logs_mb_in_period`                               | Logs ingested in MB by day/project                                                   | Use `posthog:investigating-logs` with Logs tools: service overview, count ranges, facets, and pattern diffs. Prefer log-specific tools over raw SQL.                                                                                                                                           |
+| `logs_retention_30d_mb_in_period`                 | Logs ingested under 30-day retention by day/project                                  | Use `posthog:investigating-logs` with Logs tools and retention/settings surfaces. Explain that this is retention-tier usage, not separate log content.                                                                                                                                         |
+| `logs_retention_mb_days_in_period`                | Logs retention in MB-days (bytes ingested weighted by retention days) by day/project | Use `posthog:investigating-logs` with Logs tools and retention/settings surfaces. Explain that this is storage-duration usage (MB times days retained), not separate log content. Average retention days = this / `logs_mb_in_period`.                                                         |
+| `replay_vision_credits_used_in_period`            | Replay Vision credits by day/project                                                 | Use Replay Vision scanner/observation tools. Credits come from scanner observations, so inspect scanners and observation status/results. Use `posthog:exploring-replay-vision-observations` when scanner observations are the natural drilldown.                                               |
diff --git a/skills/validating-and-publishing-canvases/SKILL.md b/skills/validating-and-publishing-canvases/SKILL.md
index 7127d0e..e6fa438 100644
--- a/skills/validating-and-publishing-canvases/SKILL.md
+++ b/skills/validating-and-publishing-canvases/SKILL.md
@@ -69,7 +69,9 @@ Diagnostics carry `severity`, a stable `code`, a `message`, and (for file-specif
   `invalid_path`, `capability_missing_insight` / `capability_missing_capture_event` /
   `capability_missing_inline_queries` / `capability_missing_agent_requests` /
   `capability_missing_network_origin`,
-  `dependency_not_admitted` / `dependency_version_mismatch`, and path/size violations.
+  `dependency_not_admitted` / `dependency_version_mismatch`, `platform_token_redeclared` (a CSS
+  variable named like a Quill token that the platform stylesheet sets on every element, so the
+  value never applies; prefix your own variables), and path/size violations.
 - `warning` diagnostics don't block, but heed them: `network_fetch` / `network_xhr` mean the code
   reaches for the network directly. Declare the exact HTTPS origin or use the `ph` bridge.