chore: sync skills (agent-skills-v0.706.0, context-mill@v1.41.0) (#176)

Co-authored-by: releaser-ai-plugin[bot] <273148615+releaser-ai-plugin[bot]@users.noreply.github.com>

Author: releaser-ai-plugin[bot]

.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.55",
+  "version": "1.1.56",
   "author": {
     "name": "PostHog",
     "email": "hey@posthog.com",

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "posthog",
-  "version": "1.0.53",
+  "version": "1.0.54",
   "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Codex",
   "author": {
     "name": "PostHog",

.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "posthog",
   "displayName": "PostHog",
-  "version": "1.1.49",
+  "version": "1.1.50",
   "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Cursor",
   "author": {
     "name": "PostHog",

gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "posthog",
-  "version": "1.0.51",
+  "version": "1.0.52",
   "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Gemini CLI",
   "mcpServers": {
     "posthog": {

skills/.sync-manifest

@@ -76,6 +76,7 @@ managing-endpoint-versions
 managing-experiment-lifecycle
 managing-path-cleaning-rules
 managing-reminders
+managing-streamlit-apps
 managing-subscriptions
 planning-voice-agent-user-interviews
 querying-posthog-data
@@ -105,7 +106,6 @@ signals-scout-feature-flags
 signals-scout-general
 signals-scout-health-checks
 signals-scout-inbox-validation
-signals-scout-ingestion-warnings
 signals-scout-insight-alerts
 signals-scout-logs
 signals-scout-mcp-tool-calls
@@ -128,3 +128,4 @@ triaging-visual-review-runs
 tuning-incremental-sync-config
 turning-engineering-analytics-into-insights
 working-with-skills
+writing-streamlit-apps

skills/analyzing-expensive-users/SKILL.md

@@ -60,8 +60,9 @@ Use this first when the question asks for the most expensive users:
 ```sql
 posthog:execute-sql
 SELECT
-    argMax(user_tuple, timestamp) AS __llm_person,
     distinct_id,
+    argMax(email, timestamp) AS email,
+    argMax(name, timestamp) AS name,
     countDistinctIf(ai_trace_id, notEmpty(ai_trace_id)) AS traces,
     count() AS generations,
     countIf(notEmpty(ai_error) OR ai_is_error = 'true') AS errors,
@@ -81,7 +82,8 @@ FROM (
         toString(properties.$ai_is_error) AS ai_is_error,
         toInt(properties.$ai_input_tokens) AS ai_input_tokens,
         toInt(properties.$ai_output_tokens) AS ai_output_tokens,
-        tuple(distinct_id, person.created_at, person.properties) AS user_tuple
+        toString(person.properties.email) AS email,
+        toString(person.properties.name) AS name
     FROM events
     WHERE event = '$ai_generation'
         AND timestamp >= now() - INTERVAL 30 DAY
@@ -101,8 +103,10 @@ AND (
 )
 ```
 
-Use person properties only for labeling, such as email or name. Do not expose
-more personal data than needed.
+Project only the explicit label columns you need, such as `email` and `name`.
+Never select the raw `person.properties` object or a tuple containing it: it
+serializes the full property blob into the result and leaks personal data far
+beyond a label. If a user has no email or name, fall back to `distinct_id`.
 
 ### 2. Establish the baseline
 
@@ -312,7 +316,9 @@ the trace timestamp so the UI opens the right time window.
 Lead with the answer, not the queries. A good response has:
 
 1. **Top users** - ranked by total cost, with total cost, share of spend,
-   generations, traces, average cost per generation, and error rate.
+   generations, traces, average cost per generation, and error rate. Identify
+   each user by a label only (email, name, or `distinct_id`). Do not print raw
+   `person.properties` objects or other personal fields the user did not ask for.
 2. **Why they are expensive** - one or two concrete drivers per user, compared
    against the baseline.
 3. **Evidence** - model/token/cache/custom-dimension breakdowns plus linked

skills/authoring-scouts/SKILL.md

@@ -112,6 +112,10 @@ For an **existing scout**, tune with `posthog:scout-config-update` (find the `id
   The standard flow is to make a scout and let it write — seeing what actually lands is the fastest way to calibrate it.
   Set **`emit=false` (dry-run)** only when you want to be extra careful: the scout still runs and logs its reasoning but writes nothing to the inbox.
   Reach for dry-run on a scout you expect to be chatty, expensive, or high-stakes; for most scouts, just writing and watching the inbox is the better loop.
+- `auto_pause_exempt` — defaults to `false`.
+  A scout whose reports nobody acts on 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, and marks it exempt so the sweep never overrules a person twice.
+  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.
 
 ## Steering with notes (no authoring needed)
 

skills/authoring-scouts/references/lifecycle-and-testing.md

@@ -21,6 +21,8 @@ How scouts get discovered, scheduled, and dispatched; the two distribution paths
   The body is the system prompt; the agent orients, explores, files reports or remembers, and writes a one-paragraph summary to the run row.
 
 Pausing a scout = `enabled=false`.
+That records `status=paused_by_user`, which automatic lifecycle sweeps never resume or re-pause; `enabled=true` resumes from any pause, including a system-applied one (`status=paused_by_system`, cause in the read-only `pause_reason`).
+Config responses expose `status` and `pause_reason` read-only; writes flow through `enabled`.
 Slowing it = a larger `run_interval_minutes`.
 Dry-running it = `emit=false`.
 All three via `posthog:scout-config-update` (get the `id` from `-config-list`), or set at creation time in the nested `config` object passed to `posthog:scout-create-prepare`.

skills/authoring-scouts/references/report-contract.md

@@ -36,6 +36,7 @@ Judges the report for safety, then persists it at the judged status.
 | `actionability_explanation` | string                  | One sentence justifying the actionability call below.                                                                                                                                                                                                                                                              |
 | `actionability`             | enum                    | `immediately_actionable` / `requires_human_input` / `not_actionable`. You make this call — the channel does not re-research it.                                                                                                                                                                                    |
 | `already_addressed`         | bool, default `false`   | Set when the underlying issue is already handled and you're filing for the record.                                                                                                                                                                                                                                 |
+| `charts`                    | list, ≤20, optional     | Queries the inbox draws on the report — the report's full set, replacing any it already had. Each `{chart_id, title, query, caption?, size?}`. See _Attaching charts_ below.                                                                                                                                       |
 
 **Status is decided for you, from safety × actionability:**
 
@@ -48,6 +49,83 @@ Judges the report for safety, then persists it at the judged status.
 
 The result tells you what happened: `report_id` (always set when a report was persisted — **even when suppressed**, so you can edit or dedup against it), `report_status` (the birth status — `ready` / `pending_input` / `suppressed` — the field is named `report_status` in the response, not `status`), `emitted` (true only when it actually surfaced — `READY` / `PENDING_INPUT`), `safety_explanation`, and `skipped_reason` (set only when a preflight gate stopped the call before any report was created — the AI-data-processing / source-enabled gates that govern every scout write).
 
+### Attaching charts
+
+`charts` puts the data next to the claim, so a reader sees the move instead of taking the number on trust.
+Worth it when the _shape_ is the point — a trend that broke, a distribution that shifted, a funnel step that collapsed.
+A chart restating one number the summary already gives is noise; just write the number.
+
+| Field      | Type             | Notes                                                                                                                                                                                                  |
+| ---------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `chart_id` | string, required | Your own slug (lowercase letters, numbers, `_`, `-`). How the summary points at the chart, and the key a later edit refreshes it under. Unique within the report.                                      |
+| `title`    | string, required | Heading above the chart.                                                                                                                                                                               |
+| `query`    | object, required | An `InsightVizNode`, `DataVisualizationNode` (a `HogQLQuery` source, plus `display` and `chartSettings` for a graph), or `SavedInsightNode` (by `shortId`). Any other `kind` is refused at write time. |
+| `caption`  | string, optional | One line on what to look at.                                                                                                                                                                           |
+| `size`     | enum, optional   | `small` / `medium` / `large`. Leave it out unless the default looks wrong — the inbox sizes a chart from its query (a big single number gets a short box, a retention grid a tall scrolling one).      |
+
+A trends chart and a graph built from SQL, as they arrive in `charts`:
+
+```json
+[
+  {
+    "chart_id": "exceptions-daily",
+    "title": "Exceptions per day",
+    "caption": "The step up starts on 18 June.",
+    "query": {
+      "kind": "InsightVizNode",
+      "source": {
+        "kind": "TrendsQuery",
+        "dateRange": { "date_from": "2026-06-01", "date_to": "2026-07-02" },
+        "interval": "day",
+        "series": [{ "kind": "EventsNode", "event": "$exception", "math": "total" }],
+        "trendsFilter": { "display": "ActionsLineGraph" }
+      }
+    }
+  },
+  {
+    "chart_id": "exceptions-by-type",
+    "title": "People affected, by exception type",
+    "query": {
+      "kind": "DataVisualizationNode",
+      "source": {
+        "kind": "HogQLQuery",
+        "query": "SELECT exception_type, uniq(distinct_id) AS people FROM ... GROUP BY exception_type ORDER BY people DESC"
+      },
+      "display": "ActionsBar",
+      "chartSettings": { "xAxis": { "column": "exception_type" }, "yAxis": [{ "column": "people" }] }
+    }
+  }
+]
+```
+
+**A graph from SQL needs its axes named.** Setting `display` without `chartSettings` draws an empty box; `chartSettings.xAxis.column` and `chartSettings.yAxis[].column` say which columns of the result are which.
+Omit `display` altogether and the node renders the result table, which reads better than a chart for a handful of rows.
+
+**Only the node's `kind` and its serialized size are checked on write.** A well-formed node of an allowed kind carrying a broken query is stored without complaint, then fails to draw when a reader opens the report, and nothing reports that back to the scout.
+So a scout should attach a query it has already run in the same session, or point at an insight that already exists via `SavedInsightNode`, rather than composing a node from memory.
+This is the single most useful thing to reinforce in a scout body that leans on charts.
+
+**A chart query must not carry anything executable.** HogVM `bytecode` (what conditional formatting compiles to), a nested `HogQuery`, and `sendRawQuery` are each refused with a 400 wherever they sit in the node, because a chart renders data rather than running code in the reader's session.
+A nested `SuggestedQuestionsQuery` is refused the same way, for cost rather than execution: its runner calls an LLM, so a chart carrying one buys a completion every time a reader opens the report.
+A query over a warehouse connection is fine as long as it goes through HogQL: keep `connectionId`, drop `sendRawQuery`.
+So a direct-warehouse query you ran with the raw-SQL bypass has to be rewritten before it can be attached.
+
+**Placement comes from the summary.** A markdown link with a `chart:` target — `[Daily signups](chart:signups-drop)` — draws the chart at that point in the body; a chart you never reference still renders, after the prose.
+Reference each chart once: a repeated reference reads as pointing back at the chart, not as asking for a second copy of it.
+Two references in one paragraph sit side by side, so put a pair you want compared in a paragraph of their own.
+A reference inside a code span, a table cell, or a heading has no room to draw — its chart falls to the end of the report instead.
+
+**The summary has to read without the charts.** A report can also be delivered to Slack, where nothing draws and each reference degrades to the plain label it was given.
+"Signups fell 60% over the week" survives that; "the chart below shows the drop" leaves a Slack reader with nothing.
+
+**Pin the window** to absolute dates wherever the node supports it, so a reader opening the report days later sees the data you wrote about rather than whatever a relative range resolves to then.
+
+**`charts` on an edit is the report's whole set, not an addition.**
+It replaces what the report had, the way `summary` replaces the summary — so send every chart you want kept, and re-send an id under a newer window to refresh that chart.
+Leave `charts` out entirely and the report keeps the ones it has; read the report first (`inbox-reports-retrieve` returns its `charts`) when you mean to add to them.
+Send `charts: []` to take every chart down, for when the finding has moved on and the old chart would now mislead.
+Cap is **20 charts per report** (and a combined query-size budget), which is far more than most reports should use. Each chart runs its query when the report is opened, so attach the ones that carry the argument rather than everything you looked at: three charts a reader studies beat a dozen they scroll past.
+
 ### Opening a draft PR (autostart)
 
 A surfaced, immediately-actionable report can open a draft PR automatically — the same autostart path the pipeline uses.
@@ -105,7 +183,7 @@ The fleet's reviewer map should compound over time.
 ## `edit_report` — update an existing report
 
 Rewrite `title`/`summary`, append a note, and/or set `suggested_reviewers` 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`.
+Pass `run_id` (the current run) and `report_id`, plus at least one of `title`, `summary`, `append_note`, `suggested_reviewers`, `charts`.
 
 `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.