chore: sync skills (agent-skills-v0.315.0, context-mill@v1.26.1)

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

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "posthog",
-  "version": "1.0.43",
+  "version": "1.0.44",
   "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.39",
+  "version": "1.1.40",
   "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.41",
+  "version": "1.0.42",
   "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Gemini CLI",
   "mcpServers": {
     "posthog": {

skills/.sync-manifest

@@ -89,11 +89,13 @@ signals-scout-health-checks
 signals-scout-inbox-validation
 signals-scout-insight-alerts
 signals-scout-logs
+signals-scout-mcp-tool-calls
 signals-scout-observability-gaps
 signals-scout-product-analytics
 signals-scout-replay-vision
 signals-scout-revenue-analytics
 signals-scout-session-replay
+signals-scout-skills-store
 signals-scout-surveys
 signals-scout-web-analytics
 skills-store

skills/authoring-scouts/SKILL.md

@@ -166,29 +166,58 @@ config on the default every-24-hours schedule on its next tick (up to ~30 min).
 
 ## Test loop
 
-You can't force a synchronous run as a user — scouts fire on their schedule. The standard
-loop is **emit + inspect**: ship the scout live, let it emit, and calibrate against what
-actually lands.
-
-1. Ship the scout (the default `emit=true`) with a short `run_interval_minutes` so it fires
-   soon — set it at creation via
-   `posthog:signals-scout-config-create {"skill_name": ..., "run_interval_minutes": 30}`
-   right after `skill-create`, rather than waiting for the coordinator to
-   auto-register the default every-24-hours schedule.
-2. After a tick, read what it did: `posthog:inbox-reports-list` (the findings it actually
-   emitted), `posthog:signals-scout-runs-list` (run summaries), `-runs-retrieve` (full
+**Dogfood the scout yourself before you ever spend a real run.** You — the agent authoring
+the scout — have the same PostHog MCP tools a scout uses at runtime (`execute-sql`,
+`read-data-schema`, the per-product list tools, `signals-scout-project-profile-get`). The
+cheapest, fastest iteration doesn't touch a scout run at all: walk the scout's own logic
+against the live project by hand. Confirm the watched event/entity exists and has the shape
+you assumed, run the **discriminator** to check it actually separates signal from noise on
+_this_ project's data, and run each **explore pattern**'s queries to see what they surface.
+This loop is free and instant — refine the body against what you find, re-run the queries,
+repeat, until the scout's logic holds up on real data. This is where the real iteration
+happens.
+
+Only once you're happy with the body do you spend an actual run.
+`posthog:signals-scout-run-now {"id": <config_id>}` dispatches one run of the scout
+immediately, regardless of its schedule (find the `id` via `-config-list`). This is the
+**initial real run** — the scout executing end-to-end in the harness, writing scratchpad
+memory and (with the default `emit=true`) emitting to the inbox. The run is **asynchronous**:
+the call returns a workflow id right away, so poll `-runs-list` / `-runs-retrieve` for the
+result. A few things to know:
+
+- A **disabled** scout can still be run this way — you can test it before ever enabling it.
+- A manual run does **not** change the scout's schedule or `last_run_at`.
+- It inherits every guard the scheduled path has: 403 if scouts aren't enabled for the
+  project, 429 if the project is over its Signals credits quota or daily run budget, 409 if a
+  run for this scout is already in progress.
+- It draws from the **same daily run budget** as scheduled runs — and a dry-run
+  (`emit=false`) still consumes a run. There's no free test run: every `-run-now` spends the
+  project's daily scout-run allowance, so firing the same scout repeatedly in a short window
+  burns through the budget (and can leave the project's scheduled scouts unable to run that
+  day). **Don't use `-run-now` as your iteration loop** — it's slow (async, one run per call)
+  and metered. Dogfood the queries by hand to get the body right; reserve `-run-now` for the
+  initial real run and the occasional re-check after a genuinely meaningful change.
+
+The standard loop is **dogfood → run once ready → inspect**:
+
+1. Dogfood the discriminator + explore patterns yourself against the live project (above).
+   Refine the body until the logic holds on real data — this is the cheap, iterable part.
+2. Author the scout and register its config (`-config-create`, the default `emit=true`), then
+   spend one `-run-now` to watch the whole scout execute end-to-end. Leave
+   `run_interval_minutes` at a sustainable value — you no longer need a short interval to
+   force an early run.
+3. After the run finishes, read what it did: `posthog:inbox-reports-list` (the findings it
+   actually emitted), `posthog:signals-scout-runs-list` (run summaries), `-runs-retrieve` (full
    reasoning for one run), and `-scratchpad-search` (the durable memory it wrote).
-3. Refine the body — tighten the discriminator, add disqualifiers for whatever it
-   false-positived on, fix the emit calibration.
-4. Once it's landing the right findings, restore the interval to something sustainable
-   (the 3h default or longer).
+4. If it needs work, go back to dogfooding the queries by hand for the iteration — only spend
+   another `-run-now` once you've batched a meaningful change worth a fresh end-to-end run.
 
 **Want to be extra careful?** Set `emit=false` to dry-run first — create the config with
-`emit=false` via `-config-create` so the scout never has a live first run; it runs and logs
-what it _would_ have emitted (visible via `-runs-list` / `-runs-retrieve`) without writing to
-the inbox. Inspect, refine, then flip `emit=true`. Worth it for a scout you expect to be
-chatty, expensive, or high-stakes; otherwise just emitting and watching the inbox is the
-faster path to a calibrated scout.
+`emit=false` via `-config-create`, then trigger it with `-run-now`: it runs and logs what it
+_would_ have emitted (visible via `-runs-list` / `-runs-retrieve`) without writing to the
+inbox. Inspect, refine, then flip `emit=true` and run it again. Worth it for a scout you
+expect to be chatty, expensive, or high-stakes; otherwise just emitting and watching the
+inbox is the faster path to a calibrated scout.
 
 Repo contributors get a faster loop — `hogli sync:skill` and the harness's local run path;
 see [`references/lifecycle-and-testing.md`](references/lifecycle-and-testing.md).

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

@@ -98,27 +98,46 @@ the standalone skills repo) automatically.
 
 ## Testing
 
-You can't trigger a synchronous run as a user — scouts fire on their schedule. The standard
-loop is **emit + inspect**: ship the scout live (`emit=true` is the default), let it emit,
-and calibrate against what actually lands.
-
-1. Ship with the default `emit=true` and a short `run_interval_minutes` (e.g. 30) so it
-   fires soon — set both at creation via `posthog:signals-scout-config-create`.
-2. After a tick, inspect:
+**Dogfood the scout yourself first — before spending any real run.** The authoring agent has
+the same PostHog MCP tools a scout uses at runtime (`execute-sql`, `read-data-schema`, the
+per-product list tools, `signals-scout-project-profile-get`), so the cheapest iteration is to
+walk the scout's own logic against the live project by hand: confirm the watched entity
+exists and has the assumed shape, run the **discriminator** to check it separates signal from
+noise on this project's data, and run each **explore pattern**'s queries. Free and instant —
+refine the body, re-run the queries, repeat, until the logic holds on real data.
+
+Only once you're happy do you spend a real run. `posthog:signals-scout-run-now {"id":
+<config_id>}` dispatches one run of the scout immediately, regardless of its schedule (get the
+`id` from `-config-list`) — the **initial real run**, the scout executing end-to-end in the
+harness. The run is **asynchronous** — the call returns a workflow id right away; poll
+`-runs-list` / `-runs-retrieve` for the result. A disabled scout can still be run this way
+(test before enabling), and a manual run doesn't touch the schedule or `last_run_at`. It
+inherits the scheduled path's guards (403 not enabled, 429 over quota / daily run budget, 409
+a run already in progress) and draws from the **same daily run budget** as scheduled runs — a
+dry-run (`emit=false`) counts too. There's no free test run, and it's slow (async, one run per
+call): firing the same scout repeatedly in a short window burns the project's daily allowance
+(and can starve its scheduled scouts). **Don't iterate via `-run-now`** — dogfood the queries
+by hand to get the body right, and reserve `-run-now` for the initial real run and the odd
+re-check after a genuinely meaningful change. The loop is **dogfood → run once ready →
+inspect**:
+
+1. Dogfood the discriminator + explore patterns yourself against the live project (above),
+   refining the body until the logic holds — the cheap, iterable part.
+2. Author the scout and register its config (`-config-create`, default `emit=true`), leaving
+   `run_interval_minutes` at a sustainable value — no short-interval trick needed. Then spend
+   one `-run-now` to watch the whole scout execute end-to-end, and inspect once it finishes:
    - `posthog:inbox-reports-list` — the findings it actually emitted.
    - `posthog:signals-scout-runs-list` — run summaries.
    - `posthog:signals-scout-runs-retrieve` — the full reasoning for one run.
    - `posthog:signals-scout-scratchpad-search` — the durable memory it wrote.
-3. Refine the body for whatever it false-positived or missed — tighten the discriminator,
-   add disqualifiers, fix emit calibration. Re-edit via `skill-update`.
-4. Once it's landing the right findings, `config-update` to restore a sustainable interval
-   (the 3h default or slower).
+3. If it needs work, go back to dogfooding the queries by hand for the iteration, re-edit via
+   `skill-update`, and spend another `-run-now` only once you've batched a meaningful change.
 
 **Extra-careful variant — dry-run first.** For a scout you expect to be chatty, expensive,
 or high-stakes, set `emit=false` so it runs and logs what it _would_ have emitted (visible in
-`-runs-list` / `-runs-retrieve`) without writing to the inbox. Inspect, refine, then
-`config-update` to `emit=true`. For most scouts, emitting straight away and watching the
-inbox is the faster calibration.
+`-runs-list` / `-runs-retrieve`) without writing to the inbox. Trigger it with `-run-now`,
+inspect, refine, then `config-update` to `emit=true`. For most scouts, emitting straight away
+and watching the inbox is the faster calibration.
 
 Repo contributors additionally get `hogli sync:skill` to run the scout against the local
 harness for a tighter loop before merging.

skills/configuring-experiment-analytics/SKILL.md

@@ -81,16 +81,18 @@ compare on what each metric measures (its `query`), never on its title.
    (mean / funnel / ratio / retention) before searching — see Step 2 to confirm the event exists via
    `read-data-schema`. You can only recognize a duplicate once you know the concrete event/action,
    so this check runs _after_ you've pinned down the event, not before.
-2. **List the library and compare each candidate's `query`.** Call `experiment-saved-metrics-list`
-   and inspect every result's **`query`** field (not just `name`/`description`). A saved metric is a
-   reuse match when its `query` measures the **same event or action with the same `metric_type`**
-   (and compatible `math`) as the metric you'd otherwise build — even if its name is
-   different.
-   - **Match locally, not via `search`.** `search` matches only `name` / `description` / tags —
-     never the underlying event or action — so it cannot find a definition match, and an empty
-     result means nothing here. Page through the full library with `limit`/`offset` and compare each
-     row's `query` yourself. (Use `search` only when the user names a specific saved metric to
-     attach — that's name resolution, not a definition match.)
+2. **Search by the event, then compare each candidate's `query`.** Call `experiment-saved-metrics-list`
+   with `?event=<the event you're measuring>` to find metrics that reference it — matched directly (an
+   `EventsNode`) **or** via the step events of any action a metric references, so action-based metrics are
+   found by the event their action fires on. Then for each returned row, inspect its **`query`** (not the
+   `name`/`description`): a saved metric is a reuse match when its `query` measures the **same event or
+   action with the same `metric_type`** (and compatible `math`) as the metric you'd otherwise build, even
+   if its name is different.
+   - **Match on the event, not the action's name.** An action-based metric is discoverable by the event
+     the action fires on — pass that event, not the action's label.
+   - **Do not use `search` for this.** `search` matches only the metric's own `name` / `description` / tags —
+     never the underlying event or action — so it cannot find a definition match. Use `search` only when the
+     user names a specific saved metric to attach (name resolution, not a definition match).
 3. **If a saved metric matches the definition** — confirm the match with the user by name/description,
    then attach it instead of building a new one:
    - Call `experiment-get` to read the experiment's current `saved_metrics`.

skills/designing-email-templates/SKILL.md

@@ -31,6 +31,16 @@ Marketing emails must include an unsubscribe link — render it with the built-i
 
 (`{{ unsubscribe_url_one_click }}` is also available for one-click list-unsubscribe flows.)
 
+## Click tracking and opt-out
+
+Every link is automatically rewritten through a click-tracking redirect. This breaks mobile universal links / app deeplinks, which only resolve when the href stays on their own domain. To keep a link untracked, mark its anchor (use an `html` block) with `clicktracking="off"` or `data-ph-no-track`:
+
+```html
+<a href="https://app.example.com/deeplink" data-ph-no-track>Open in app</a>
+```
+
+The marker must be on the `<a>` tag itself, not a child element. Opted-out links get no click metrics.
+
 ## Creating a template
 
 Call `workflows-create-email-template` with:

skills/exploring-apm-traces/SKILL.md

@@ -43,13 +43,13 @@ posthog:apm-trace-get
 }
 ```
 
-The response is `{ results: [span, span, …] }` — a flat list of every span in the trace.
+The response is `{ results: [span, span, …], _posthogUrl: "…" }` — a flat list of every span in the trace.
 The list can be very large for fan-out request flows; when it exceeds the inline limit, Claude Code auto-persists it to a file.
 
 From the result you get:
 
 - Every span with `name`, `service_name`, `kind`, `status_code`, `parent_span_id`, `duration_nano`, `is_root_span`
-- The `_posthogUrl` — **always include this in your response** so the user can click through to the UI
+- The `_posthogUrl` — a deep link to this trace in the tracing UI; **always include this in your response** so the user can click through
 
 ### Step 2 — Parse large results with scripts
 
@@ -148,9 +148,11 @@ Each span carries an `attributes` map (span-level OTel attributes like `http.met
 
 ## Constructing UI links
 
-`apm-trace-get` and `query-apm-spans` return `_posthogUrl` — **always surface this to the user** so they can verify in the PostHog UI.
+`apm-trace-get` returns a `_posthogUrl` deep link that opens the trace in the tracing UI — **always surface this to the user** so they can verify in the PostHog UI.
 
-When presenting findings, include the relevant PostHog URL.
+`query-apm-spans` does not return `_posthogUrl`.
+To link a trace found via the query tool, feed its `trace_id` to `apm-trace-get` and surface the `_posthogUrl` from that response.
+Never hand-construct PostHog URLs.
 
 ## Finding traces
 
@@ -237,7 +239,7 @@ results (array of span dicts)
 ## Tips
 
 - Always set `dateRange` on `query-apm-spans` — queries without a time range are slow. Default is `-1h`; widen only when needed.
-- Always include the `_posthogUrl` in your response so the user can click through.
+- Always include the `_posthogUrl` from `apm-trace-get` in your response so the user can click through to the trace.
 - Span-level attributes **are** in the `apm-trace-get` / `query-apm-spans` payload (each span's `attributes` map). Resource attributes are not — use `apm-attributes-list` (type `resource`) and `apm-attribute-values-list` for those.
 - `is_root_span` is the cheap way to find the trace entry — don't string-match `00000000…`.
 - For aggregates (p95 by operation, slowest children of a span), use `apm-spans-aggregate` for a flat view or `apm-spans-tree` for parent→child edges — don't reach for SQL.