chore: sync skills (agent-skills-v0.1165.0, context-mill@v1.52.0)

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

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

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "posthog",
-  "version": "1.0.61",
+  "version": "1.0.62",
   "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.57",
+  "version": "1.1.58",
   "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.59",
+  "version": "1.0.60",
   "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Gemini CLI",
   "mcpServers": {
     "posthog": {

skills/.sync-manifest

@@ -17,6 +17,7 @@ building-html-canvases
 building-react-quill-canvases
 building-workflows
 checking-deploy-timing
+checking-member-access
 choosing-trend-or-slope-view
 cleaning-up-stale-feature-flags
 composing-grid-canvases
@@ -34,6 +35,7 @@ creating-box-plot-insights
 creating-experiments
 creating-online-evaluations
 creating-replay-vision-scanners
+creating-surveys
 debugging-experiments
 debugging-local-replay
 debugging-mcp-analytics

skills/authoring-scouts/SKILL.md

@@ -28,9 +28,11 @@ A scout's output is the **report channel**: it lists `emit_report` / `edit_repor
 The canonical fleet runs this way, and **every new scout should too** — always include the `allowed_tools` opt-in when authoring one.
 (A historical signal-emitting channel — weak `emit-signal` findings a pipeline consolidated — still exists in the harness for scouts that never opted in, but it is deprecated: don't author new scouts on it, and opt an old one in rather than extending it.)
 
-A scout is just an `LLMSkill` whose name starts with `signals-scout-`.
-The harness discovers scouts by globbing `signals-scout-*` over the project's skills, loads the body **verbatim** as the agent's system prompt, and progressively reads any bundled reference files on demand.
-**The `signals-scout-` name prefix is load-bearing: a skill named anything else will never run as a scout.**
+A scout is an `LLMSkill` that holds a `SignalScoutConfig`.
+The harness loads the body **verbatim** as the agent's system prompt, and progressively reads any bundled reference files on demand.
+**The config row is what makes a skill a scout.** Any valid skill name works, so the `signals-scout-` prefix is optional.
+The prefix controls one thing: the coordinator globs `signals-scout-*` to auto-register a config for a skill that has none.
+A skill with any other name needs its config created alongside it, which is what `scout-create-prepare` / `-execute` does.
 
 ## The job before the writing
 

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

@@ -4,11 +4,11 @@ How scouts get discovered, scheduled, and dispatched; the two distribution paths
 
 ## How a scout runs
 
-- **Discovery.** The harness globs `signals-scout-*` over the project's skills (`LLMSkill` rows).
-  Any matching skill is a scout.
-  No registration step.
+- **Discovery.** A scout is a skill that holds a `SignalScoutConfig`, and the coordinator dispatches from those config rows.
+  The `signals-scout-` name prefix is optional; it controls only auto-registration, below.
 - **Config.** Each scout has one `SignalScoutConfig` per `(project, skill_name)` carrying `run_interval_minutes` (default 1440), `enabled`, `emit`, `network_access` (`trusted` default, `full` for scouts that read arbitrary external sites), and a `last_run_at` stamp.
-  A config is **auto-registered** the first time the coordinator sees a `signals-scout-*` skill without one — authoring the skill is enough to get a scout.
+  A config is **auto-registered** the first time the coordinator sees a `signals-scout-*` skill without one, so authoring a prefixed skill is enough to get a scout.
+  A skill named anything else needs its config created with it.
   Prepare a fresh per-team scout and its config together with `posthog:scout-create-prepare`; the nested `config` object sets its schedule, emit posture, and destinations before it can run.
   Show the returned confirmation message, wait for the user to type `confirm`, then call `posthog:scout-create-execute` with the returned `confirmation_hash` and that literal confirmation.
   The lower-level `posthog:scout-config-create` remains available when a skill already exists without a config.

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

@@ -203,9 +203,9 @@ Each entry identifies one reviewer by **`github_login`**, **`user_uuid`**, or bo
 - **`github_login`** — a **bare, lowercase GitHub login** (e.g. `octocat`, not `@OctoCat`).
   Internal assignment matches it against each user's linked GitHub login by exact, lowercased comparison, so a mis-cased handle, an `@`-prefix, a display name, a CODEOWNERS **team** slug, or an email won't set `is_suggested_reviewer` for anyone (autostart's PR-selection path is more lenient, but the assignment path is not).
 - **`user_uuid`** — a **PostHog user UUID**.
-  The server resolves it to that org member's linked GitHub login for you (and it wins if you also pass a `github_login`).
-  Use this whenever your evidence already names a PostHog user — an account owner, an entity's `created_by`, a CSM — so you can route to them without ever looking up their handle.
-  A `user_uuid` that isn't an org member of this team **with a linked GitHub identity** is rejected (the whole call fails), so it never silently drops.
+  The server resolves it to that org member. It wins if you also pass a `github_login`.
+  Use this whenever your evidence already names a PostHog user. It works without a linked GitHub account.
+  A `user_uuid` that is not an org member of this team is rejected, so it never silently drops.
 
 So you have two routes to a reviewer.
 If you already hold a PostHog user UUID, prefer passing it as `user_uuid` — it's the most reliable.
@@ -219,7 +219,7 @@ Otherwise resolve a `github_login`, cheapest source first:
    `.github/CODEOWNERS` for the owning path, or the last `git log` author for the file.
    Neither usually hands you a usable login directly: CODEOWNERS entries are often **team** slugs (`@your-org/team-name`) and `git log` gives a name + email — both must be resolved to an **individual** GitHub login before you write the reviewer (a team slug or an email won't match any user).
 4. **`scout-members-list`** — the in-run roster lookup, for the cold-start case where the cheaper paths above don't resolve an owner.
-   It returns this project's members, each with `user_uuid`, `email`, name, and a resolved `github_login` (pass `search=` to narrow); match the owner and route to their `github_login`, or hand the `user_uuid` straight through and let the server resolve it.
+   It returns this project's members, each with `user_uuid`, email, name, and a resolved `github_login`. Pass `search=` to narrow the result. Match the owner and route with `user_uuid`.
    The org-scoped `org-members-list` / `org-member-get-github-login` tools are **not available in a scout run** — a scoped-team token can't reach the org-nested endpoint, so don't build a scout's reviewer recipe around them.
 
 **If you can't confidently identify a reviewer, leave `suggested_reviewers` empty** — the report still surfaces for a human to grab.

skills/authoring-scouts/references/scout-anatomy.md

@@ -14,9 +14,11 @@ Keep the body lean and push depth into references — every line of the body is
 
 ## Naming
 
-The skill name **must** match `signals-scout-<scope>` — the harness discovers scouts by globbing `signals-scout-*`.
-`<scope>` is lowercase kebab-case naming the surface or question the scout watches: `signals-scout-error-tracking`, `signals-scout-checkout-funnel`, `signals-scout-mcp-feedback`.
-A skill named anything else is just a normal skill and never runs as a scout.
+Any valid skill name works: lowercase letters, numbers, and hyphens.
+The `SignalScoutConfig` row is what makes a skill a scout.
+Name it in lowercase kebab-case after the surface or question the scout watches: `error-tracking`, `checkout-funnel`, `mcp-feedback`.
+The canonical fleet keeps the `signals-scout-` prefix, and a per-team scout can use it too.
+The prefix only controls whether the coordinator auto-registers a config for a skill that has none, so a scout named anything else comes in through `scout-create-prepare` / `-execute`, which writes the skill and its config in one call.
 
 ## Frontmatter
 

skills/building-canvases/SKILL.md

@@ -157,6 +157,12 @@ That field is the only valid link to a canvas — never construct one yourself;
   `canvases-actions-retrieve` tool and follow each verb's `usage` (payload/result shape,
   behavior, and the confirmation copy it warrants) before wiring it.
 
+- **`ph.connectors.call(provider, tool, args)`** — read live third-party data (GitHub, or any
+  MCP store server) with the VIEWER's own connection at view time. Never call GitHub, Calendly,
+  or another service yourself and paste the result into the source: that snapshot is stale on
+  publish and shows every viewer the author's data. Declare each provider and tool in
+  `capabilities.connectors`; discover them with the `canvas-connectors-retrieve` tool. See
+  `querying-canvas-data` for the result and not-connected handling.
 - **`ph.agent.request(prompt)`** — ask the canvas's authoring agent for a change, with the viewer's
   approval. Declare `agentRequests: true` in `capabilities.posthog`. Call it only from a direct
   click or form submission — the host shows the exact prompt and asks the viewer to accept before