[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-posthog-authoring-scouts":3,"mdc--uck15a-key":38,"related-repo-posthog-authoring-scouts":1859,"related-org-posthog-authoring-scouts":1971},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":23,"repoUrl":24,"updatedAt":25,"license":26,"forks":27,"topics":28,"repo":33,"sourceUrl":36,"mdContent":37},"authoring-scouts","author and edit PostHog Signals scouts","How to author, edit, and adapt PostHog Signals scouts — the scheduled agents that scan a project and write reports into the Signals inbox. Use when a user wants to customize a canonical scout for their own setup (narrow its scope, retune its thresholds, add disqualifiers), tweak a scout's schedule or dry-run posture, or write a brand-new scout from scratch for a specific use case (a custom event, a product surface no canonical scout covers), or steer a scout without editing it at all by leaving it a note. Covers the scout SKILL.md anatomy, the report contract, the dedupe + scratchpad-memory conventions, the scout-notes steering channel, the per-team skills-store path vs the canonical in-repo path, and the write-and-inspect test loop (with dry-run as an optional safety net). Trigger on \"write\u002Fedit\u002Fcustomize a signals scout\", \"new scout for X\", \"tune my scout schedule\", \"make a scout that watches \u003Cevent>\", \"leave a note for \u002F give feedback to a scout\", \"tell the scouts about X\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},"posthog","PostHog","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fposthog.png",[12,16,17,20],{"name":13,"slug":14,"type":15},"Observability","observability","tag",{"name":9,"slug":8,"type":15},{"name":18,"slug":19,"type":15},"Automation","automation",{"name":21,"slug":22,"type":15},"Agents","agents",59,"https:\u002F\u002Fgithub.com\u002FPostHog\u002Fai-plugin","2026-07-28T05:33:45.509154",null,11,[29,30,31,32],"claude-code-plugin","codex-plugin","cursor-plugin","gemini-cli-extension",{"repoUrl":24,"stars":23,"forks":27,"topics":34,"description":35},[29,30,31,32],"Official PostHog plugin for Claude Code, Cursor, Gemini, Codex and other AI coding tools","https:\u002F\u002Fgithub.com\u002FPostHog\u002Fai-plugin\u002Ftree\u002FHEAD\u002Fskills\u002Fauthoring-scouts","---\nname: authoring-scouts\ndescription: >\n  How to author, edit, and adapt PostHog Signals scouts — the scheduled agents that\n  scan a project and write reports into the Signals inbox. Use when a user wants to\n  customize a canonical scout for their own setup (narrow its scope, retune its\n  thresholds, add disqualifiers), tweak a scout's schedule or dry-run posture, or\n  write a brand-new scout from scratch for a specific use case (a custom event, a\n  product surface no canonical scout covers), or steer a scout without editing it at all\n  by leaving it a note. Covers the scout SKILL.md anatomy, the\n  report contract, the dedupe + scratchpad-memory conventions, the scout-notes steering\n  channel, the per-team skills-store\n  path vs the canonical in-repo path, and the write-and-inspect test loop (with dry-run as an\n  optional safety net). Trigger on\n  \"write\u002Fedit\u002Fcustomize a signals scout\", \"new scout for X\", \"tune my scout schedule\",\n  \"make a scout that watches \u003Cevent>\", \"leave a note for \u002F give feedback to a scout\",\n  \"tell the scouts about X\".\nmetadata:\n  owner_team: signals\n---\n\n# Authoring Signals scouts\n\nA **scout** is a scheduled agent that wakes on its own interval, looks at one PostHog project, decides what's genuinely worth surfacing, and writes it into the Signals inbox as a **report** — or closes out empty, which is a real outcome.\nPostHog ships a fleet of **canonical scouts** (a cross-product generalist plus per-surface specialists).\nThis skill helps you and your agent **adapt those canonical scouts to a specific project**, or **author new scouts from scratch** for a use case the fleet doesn't cover.\n\nA scout's output is the **report channel**: it lists `emit_report` \u002F `edit_report` in its frontmatter `allowed_tools` and authors or edits full inbox reports 1:1 directly.\nThe canonical fleet runs this way, and **every new scout should too** — always include the `allowed_tools` opt-in when authoring one.\n(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.)\n\nA scout is just an `LLMSkill` whose name starts with `signals-scout-`.\nThe 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.\n**The `signals-scout-` name prefix is load-bearing: a skill named anything else will never run as a scout.**\n\n## The job before the writing\n\nDon't write a scout in the abstract.\nGround it in the target project first — a scout is only as good as its fit to the data it watches.\n(The scout tools were recently renamed from `signals-scout-*` to `scout-*`; if a `scout-*` name comes back unknown, the server may still expose it under the legacy `signals-scout-*` name — search the tool catalog and call whichever name it returns.)\n\n1. **Read the project.** `posthog:scout-project-profile-get` returns the deterministic snapshot the scout itself cold-starts from: products in use, top events with reach\u002Fburst metrics, integrations, existing inbox counts.\n   If the scout watches a specific event, confirm it exists and check its shape with `posthog:read-data-schema`.\n   A scout for an event the project doesn't capture is dead on arrival.\n2. **See what already runs.** `posthog:scout-config-list` lists every existing scout on the project with its schedule, `enabled`, and `emit` posture, plus each scout's `description` (pulled from the skill's frontmatter) so you can tell what a scout watches without loading its body.\n   Don't duplicate a surface a canonical scout already covers — adapt that one instead.\n3. **Read the closest canonical scout.** It's your template and your reference shape.\n   Pull it with `posthog:skill-get {\"skill_name\": \"signals-scout-\u003Cx>\"}` (per-team rows) or read it from the repo at `products\u002Fsignals\u002Fskills\u002Fsignals-scout-*\u002F`.\n   The generalist (`signals-scout-general`) is the broad template; if your scope is domain-tight, pick the specialist closest to your surface — list the live roster with `posthog:skill-list {\"search\": \"signals-scout\"}` (specialists exist for most product surfaces: error tracking, logs, AI observability, experiments, feature flags, session replay, web analytics, surveys, and more).\n4. **Skim the inbox.** `posthog:inbox-reports-list` shows what reports are actually landing — calibrate so your scout adds signal, not noise.\n\n## Choose the path\n\nThere are two independent decisions: **what** you're building, and **where** it lives.\n\n### What\n\n| Situation                                                                                      | Approach                                                                                                                           |\n| ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |\n| A canonical scout is close but too broad \u002F too noisy \u002F missing a disqualifier for this project | **Adapt** it — narrow the scope, add disqualifiers, retune thresholds.                                                             |\n| You want a surface no canonical scout covers (a custom event, a product-specific funnel)       | **New scout from scratch** — copy the closest canonical scout as scaffolding, replace the domain discriminator + explore patterns. |\n| You only want to change _when_ \u002F _whether_ a scout runs                                        | **No authoring** — just tune the config (see Run posture).                                                                         |\n| You have one-off feedback, a pointer, or short-lived context for a scout                       | **No authoring** — leave a note (see Steering with notes).                                                                         |\n\n### Where\n\n| Path                                 | Mechanism                                                                                                                                                                                                                                                                                                                 | Use when                                                                                                                              |\n| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |\n| **Per-team** (the common user path)  | Prepare a new runnable scout via `posthog:scout-create-prepare`, show its confirmation message, wait for the user to type `confirm`, then call `posthog:scout-create-execute`; edit its prompt or files later via `posthog:skill-update` \u002F `-file-create`, and tune its runtime config via `posthog:scout-config-update`. | Customizing for one project. The harness globs the row in on the next tick; canonical sync leaves your edited (\"diverged\") row alone. |\n| **Canonical** (PostHog contributors) | Edit disk under `products\u002Fsignals\u002Fskills\u002Fsignals-scout-*\u002F`, lint\u002Fbuild, open a PR.                                                                                                                                                                                                                                        | Improving a scout for _every_ enrolled project. `lazy_seed` mirrors it onto all enrolled teams on the next tick.                      |\n\n**Adapting-in-place tradeoff:** editing a canonical scout's row for your team marks it **diverged** — you stop receiving upstream improvements to that scout.\nIf you only need an _additional_ behavior, prefer authoring a **new, differently-named** scout (`signals-scout-\u003Cyour-scope>`) and leaving the canonical one intact.\n\nSee [`references\u002Flifecycle-and-testing.md`](references\u002Flifecycle-and-testing.md) for the exact skills-store calls, the build\u002Flint commands, and how seeding works.\n\n## Write the scout\n\nFirst pick the **shape**.\n[`references\u002Fscout-patterns.md`](references\u002Fscout-patterns.md) is a cookbook of the reference architectures scouts fall into — anomaly watcher, liveness\u002Fabsence watcher, watchlist explore\u002Fexploit, cross-product correlation, recommendation\u002Fgap, warehouse-backed source, custom single-event, open-text theme, external-tool\u002Fcode, state∩code intersection, daily digest\u002Froll-up, triage over a pre-detected stream, first-person dogfooding\u002Fprobe — each mapped to a canonical scout you can copy as scaffolding.\nIt also makes the key point that **a scout can watch any source PostHog ingests into the data warehouse, not just analytics events** (a Slack channel sync, a billing system, a CRM, a support inbox), plus external systems reachable from the sandbox.\nFind the closest pattern, then write the body.\n\nFollow [`references\u002Fscout-anatomy.md`](references\u002Fscout-anatomy.md) — it has the frontmatter schema (including the `allowed_tools` report-channel opt-in every scout needs), the canonical body structure (quick close-out → orient → domain discriminator → explore patterns → save-memory → decide → disqualifiers → close-out), the lean-body rule, and copy-ready skeleton templates for both a specialist and the generalist.\n\nTwo craft references the whole fleet reasons in terms of — a good scout's **Decide** and **memory** sections are built on them, so read them before writing those sections:\n\n- [`references\u002Freport-contract.md`](references\u002Freport-contract.md) — the report tools (`scout-emit-report` \u002F `scout-edit-report`), the report bar (author 1:1 only for a finding you'd own end-to-end), `suggested_reviewers` routing, the dedup-via-`report_id` discipline (the channel isn't idempotent — reconcile against existing reports via the vanilla `inbox-reports-list` \u002F `inbox-reports-retrieve` before authoring), and the accepted caveat that the pipeline may later rewrite an authored title\u002Fsummary.\n  This is how your scout decides _what clears the bar_ and _how to file it_.\n- [`references\u002Fdedupe-and-memory.md`](references\u002Fdedupe-and-memory.md) — the four-states classifier (net-new \u002F material-update \u002F already-covered \u002F addressed-or-noise), the scratchpad key-prefix vocabulary, and the cross-project noise patterns.\n  This is how your scout avoids re-filing and learns across runs.\n\nThe single most important design decision in any scout is its **signal-vs-noise discriminator** — the cheap profile-shape read that separates \"worth investigating\" from \"baseline\".\nFor error tracking it's the `count` vs `distinct_users` ratio; for CSP it's reach over raw count.\nYour new scout needs its own.\nName it explicitly near the top of the body so every run anchors on it.\n\n## Run posture (config)\n\nA scout's schedule and emit behavior live on its `SignalScoutConfig`, separate from the skill body.\nFor a **brand-new scout**, pass these settings in the nested `config` object of the `posthog:scout-create-prepare` call, including creating it disabled or in dry-run **before it ever runs**.\nShow 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.\nThe endpoint creates the skill and config atomically, always opts the scout into the report channel, and safely re-applies config fields when the same definition is retried.\nOtherwise the coordinator auto-registers an enabled config on the default every-24-hours schedule on its next tick (up to ~30 min).\nFor an **existing scout**, tune with `posthog:scout-config-update` (find the `id` via `-config-list`):\n\n- `run_interval_minutes` — 30 to 43200.\n  Default 1440 (every 24 hours).\n  Slow a chatty or expensive scout by raising this.\n- `enabled` — `false` pauses the scout entirely (coordinator skips it).\n- `emit` — defaults to **`true`**: the scout writes its reports straight to the inbox.\n  The standard flow is to make a scout and let it write — seeing what actually lands is the fastest way to calibrate it.\n  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.\n  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.\n\n## Steering with notes (no authoring needed)\n\nSometimes you don't want to change the scout — you want to _tell it something_.\nThat's what **scout notes** are for: short steering messages any team member (or an agent acting for one) leaves for the fleet, which every run picks up as prior context alongside its scratchpad and run history.\nReach for a note instead of an edit when the steer is feedback, a pointer, or context with a shelf life:\n\n- Feedback on output: \"the staging traffic spike you keep flagging is known noise, stop reporting it\".\n- A pointer: \"dig into the EU signup funnel this week — we think something regressed\".\n- Context the scout couldn't know: \"we shipped a new checkout on Tuesday, treat conversion shifts after that as expected\".\n\nThe tools (reads on the public `signal_scout:read` scope; because scouts read notes verbatim, writing or deleting one requires the same authorization as editing a scout's skill — the `llm_skill:write` scope plus skill editor access):\n\n- `posthog:scout-notes-create {\"content\": \"...\", \"skill_name\": \"signals-scout-web-analytics\"}` — address one scout by its exact skill name (roster via `scout-config-list`; the skill must already exist, so a typo'd target is rejected instead of silently steering no one), or omit `skill_name` for a general note every scout sees.\n  Optionally set `expires_at` so a time-boxed note (\"watch closely this week\") retires itself.\n- `posthog:scout-notes-list` — browse the active notes; pass `skill_name` to see what a given scout will read.\n- `posthog:scout-notes-delete {\"id\": \"...\"}` — retire a note that's been acted on or no longer applies.\n\nHow scouts treat notes: every run reads its notes in step 1 and is told to let a fresh note visibly shape what it investigates — but notes are **advisory**.\nThey direct attention; they don't lower the scout's evidence bar or force a report, so a note saying \"report X\" still gets an honest investigation, not an automatic emit.\nThe scout closes the loop in its run summary (which notes it acted on and how) and folds absorbed guidance into its scratchpad.\n\nChoosing between a note and an edit: a note is the right tool for _this project, right now_ steering and for trying a nudge before committing to it; a skill edit is the right tool once the steer is permanent policy (a disqualifier, a threshold, a scope change).\nA note that you keep re-leaving is a skill edit waiting to happen — promote it.\nNote lifecycle stays with humans: scouts never delete notes, so retire acted-on notes yourself (or set `expires_at` up front) to keep the channel high-signal.\n\n## Test loop\n\n**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, `scout-project-profile-get`).\nThe cheapest, fastest iteration doesn't touch a scout run at all: walk the scout's own logic against the live project by hand.\nConfirm the watched event\u002Fentity 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.\nThis 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.\nThis is where the real iteration happens.\n\nOnly once you're happy with the body do you spend an actual run.\n`posthog:scout-run-now {\"id\": \u003Cconfig_id>}` dispatches one run of the scout immediately, regardless of its schedule (find the `id` via `-config-list`).\nThis is the **initial real run** — the scout executing end-to-end in the harness, writing scratchpad memory and (with the default `emit=true`) writing reports to the inbox.\nThe run is **asynchronous**: the call returns a workflow id right away, so poll `-runs-list` \u002F `-runs-retrieve` for the result.\nA few things to know:\n\n- A **disabled** scout can still be run this way — you can test it before ever enabling it.\n- A manual run does **not** change the scout's schedule or `last_run_at`.\n- 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.\n- It draws from the **same daily run budget** as scheduled runs — and a dry-run (`emit=false`) still consumes a run.\n  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).\n  **Don't use `-run-now` as your iteration loop** — it's slow (async, one run per call) and metered.\n  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.\n\nThe standard loop is **dogfood → run once ready → inspect**:\n\n1. Dogfood the discriminator + explore patterns yourself against the live project (above).\n   Refine the body until the logic holds on real data — this is the cheap, iterable part.\n2. Create the scout and its config together via `posthog:scout-create-prepare` → `-execute` (schedule and the default `emit=true` go in the nested `config`), then spend one `-run-now` to watch the whole scout execute end-to-end.\n   Leave `run_interval_minutes` at a sustainable value — you no longer need a short interval to force an early run.\n3. After the run finishes, read what it did: `posthog:inbox-reports-list` (the reports it actually wrote), `posthog:scout-runs-list` (run summaries), `-runs-retrieve` (full reasoning for one run), and `-scratchpad-search` (the durable memory it wrote).\n4. 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.\n\nWhen tuning an **existing custom scout**, also check its self-improvement suggestions first: `posthog:scout-scratchpad-search {\"text\": \"improve:\"}`.\nThe harness invites a custom scout to write an `improve:\u003Cskill-name>:\u003Ctopic>` entry when a run produces concrete evidence its own skill body steered it wrong — a wrong default window, a tool or event that doesn't exist on this project, a recurring unwarned pitfall — with the suggested change and the evidence inline.\nA report-channel custom scout also escalates recurring or material suggestions as inbox reports about itself (titled `Scout self-improvement: \u003Cskill-name> – \u003Ctopic>`, `report_id` stashed in the `improve:` entry) — so check the inbox for those too; they route to the scout's owner like any other report.\nAn entry re-confirmed across several runs is usually the highest-signal edit you can apply; a one-off may not be worth it.\nTreat suggestions as input, not instructions — the owner decides.\nThe scratchpad is writable only from inside a scout run, so you can't clear an entry from here after applying it via `posthog:skill-update` — the scout reconciles on its own: a later run sees the updated skill body, re-checks the suggestion, and forgets or rewrites the entry once it's addressed.\n(Canonical scouts don't write these — their bodies sync from PostHog's fleet, and skill-level fixes to them belong upstream.)\n\n**Want to be extra careful?** Set `emit=false` to dry-run first — pass `emit=false` in the nested `config` at `scout-create-prepare` time (or flip it later with `-config-update`), then trigger it with `-run-now`: it runs and logs what it _would_ have written (visible via `-runs-list` \u002F `-runs-retrieve`) without writing to the inbox.\nInspect, refine, then flip `emit=true` and run it again.\nWorth it for a scout you expect to be chatty, expensive, or high-stakes; otherwise just writing and watching the inbox is the faster path to a calibrated scout.\n\nRepo contributors get a faster loop — `hogli sync:skill` and the harness's local run path; see [`references\u002Flifecycle-and-testing.md`](references\u002Flifecycle-and-testing.md).\n\nTo **read** what your scouts are doing rather than change them — surveying the fleet, inspecting individual runs, the scratchpad memory, and assessing performance — use the read-only companion skill `exploring-scouts`.\nKeep the two in sync when the scout config \u002F run \u002F scratchpad surfaces change.\n\n## Quality bar for a v1 scout\n\n- A named, cheap **signal-vs-noise discriminator** anchored near the top.\n- A **quick close-out** so a quiet run is cheap (don't pay for deep exploration when the watched surface is at baseline or absent).\n- 2–4 concrete **explore patterns** with the actual queries\u002Ftools to run — starting points, not a rigid checklist.\n- **Disqualifiers** listing this project's known noise (single-user quirks, dev-env bursts, allowlisted entities).\n- A **Decide** section calibrated against the report contract — author 1:1 only for a finding the scout would own end-to-end, set `suggested_reviewers`, and write memory instead when a candidate is below the bar.\n- **Save-memory** guidance using the scratchpad prefixes so the scout gets smarter each run.\n- A lean body (push depth into `references\u002F`) — every line is a recurring token cost on every run.\n- A **tight frontmatter `description`** — a sentence or two naming the surface and the shapes it watches.\n  Every scout's description loads into the caller's AI plugin together, so wordy descriptions waste token budget and get truncated; skip the fleet-wide boilerplate (report bar, durable memory, self-contained peer).\n",{"data":39,"body":42},{"name":4,"description":6,"metadata":40},{"owner_team":41},"signals",{"type":43,"children":44},"root",[45,54,96,155,203,210,244,375,381,400,406,519,524,666,705,722,728,758,781,800,890,918,924,1017,1083,1089,1108,1126,1147,1214,1226,1245,1251,1306,1369,1455,1467,1570,1627,1708,1730,1750,1756],{"type":46,"tag":47,"props":48,"children":50},"element","h1",{"id":49},"authoring-signals-scouts",[51],{"type":52,"value":53},"text","Authoring Signals scouts",{"type":46,"tag":55,"props":56,"children":57},"p",{},[58,60,66,68,73,75,80,82,87,89,94],{"type":52,"value":59},"A ",{"type":46,"tag":61,"props":62,"children":63},"strong",{},[64],{"type":52,"value":65},"scout",{"type":52,"value":67}," is a scheduled agent that wakes on its own interval, looks at one PostHog project, decides what's genuinely worth surfacing, and writes it into the Signals inbox as a ",{"type":46,"tag":61,"props":69,"children":70},{},[71],{"type":52,"value":72},"report",{"type":52,"value":74}," — or closes out empty, which is a real outcome.\nPostHog ships a fleet of ",{"type":46,"tag":61,"props":76,"children":77},{},[78],{"type":52,"value":79},"canonical scouts",{"type":52,"value":81}," (a cross-product generalist plus per-surface specialists).\nThis skill helps you and your agent ",{"type":46,"tag":61,"props":83,"children":84},{},[85],{"type":52,"value":86},"adapt those canonical scouts to a specific project",{"type":52,"value":88},", or ",{"type":46,"tag":61,"props":90,"children":91},{},[92],{"type":52,"value":93},"author new scouts from scratch",{"type":52,"value":95}," for a use case the fleet doesn't cover.",{"type":46,"tag":55,"props":97,"children":98},{},[99,101,106,108,115,117,123,125,131,133,138,140,145,147,153],{"type":52,"value":100},"A scout's output is the ",{"type":46,"tag":61,"props":102,"children":103},{},[104],{"type":52,"value":105},"report channel",{"type":52,"value":107},": it lists ",{"type":46,"tag":109,"props":110,"children":112},"code",{"className":111},[],[113],{"type":52,"value":114},"emit_report",{"type":52,"value":116}," \u002F ",{"type":46,"tag":109,"props":118,"children":120},{"className":119},[],[121],{"type":52,"value":122},"edit_report",{"type":52,"value":124}," in its frontmatter ",{"type":46,"tag":109,"props":126,"children":128},{"className":127},[],[129],{"type":52,"value":130},"allowed_tools",{"type":52,"value":132}," and authors or edits full inbox reports 1:1 directly.\nThe canonical fleet runs this way, and ",{"type":46,"tag":61,"props":134,"children":135},{},[136],{"type":52,"value":137},"every new scout should too",{"type":52,"value":139}," — always include the ",{"type":46,"tag":109,"props":141,"children":143},{"className":142},[],[144],{"type":52,"value":130},{"type":52,"value":146}," opt-in when authoring one.\n(A historical signal-emitting channel — weak ",{"type":46,"tag":109,"props":148,"children":150},{"className":149},[],[151],{"type":52,"value":152},"emit-signal",{"type":52,"value":154}," 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.)",{"type":46,"tag":55,"props":156,"children":157},{},[158,160,166,168,174,176,182,184,189,191],{"type":52,"value":159},"A scout is just an ",{"type":46,"tag":109,"props":161,"children":163},{"className":162},[],[164],{"type":52,"value":165},"LLMSkill",{"type":52,"value":167}," whose name starts with ",{"type":46,"tag":109,"props":169,"children":171},{"className":170},[],[172],{"type":52,"value":173},"signals-scout-",{"type":52,"value":175},".\nThe harness discovers scouts by globbing ",{"type":46,"tag":109,"props":177,"children":179},{"className":178},[],[180],{"type":52,"value":181},"signals-scout-*",{"type":52,"value":183}," over the project's skills, loads the body ",{"type":46,"tag":61,"props":185,"children":186},{},[187],{"type":52,"value":188},"verbatim",{"type":52,"value":190}," as the agent's system prompt, and progressively reads any bundled reference files on demand.\n",{"type":46,"tag":61,"props":192,"children":193},{},[194,196,201],{"type":52,"value":195},"The ",{"type":46,"tag":109,"props":197,"children":199},{"className":198},[],[200],{"type":52,"value":173},{"type":52,"value":202}," name prefix is load-bearing: a skill named anything else will never run as a scout.",{"type":46,"tag":204,"props":205,"children":207},"h2",{"id":206},"the-job-before-the-writing",[208],{"type":52,"value":209},"The job before the writing",{"type":46,"tag":55,"props":211,"children":212},{},[213,215,220,222,228,230,235,237,242],{"type":52,"value":214},"Don't write a scout in the abstract.\nGround it in the target project first — a scout is only as good as its fit to the data it watches.\n(The scout tools were recently renamed from ",{"type":46,"tag":109,"props":216,"children":218},{"className":217},[],[219],{"type":52,"value":181},{"type":52,"value":221}," to ",{"type":46,"tag":109,"props":223,"children":225},{"className":224},[],[226],{"type":52,"value":227},"scout-*",{"type":52,"value":229},"; if a ",{"type":46,"tag":109,"props":231,"children":233},{"className":232},[],[234],{"type":52,"value":227},{"type":52,"value":236}," name comes back unknown, the server may still expose it under the legacy ",{"type":46,"tag":109,"props":238,"children":240},{"className":239},[],[241],{"type":52,"value":181},{"type":52,"value":243}," name — search the tool catalog and call whichever name it returns.)",{"type":46,"tag":245,"props":246,"children":247},"ol",{},[248,275,316,358],{"type":46,"tag":249,"props":250,"children":251},"li",{},[252,257,259,265,267,273],{"type":46,"tag":61,"props":253,"children":254},{},[255],{"type":52,"value":256},"Read the project.",{"type":52,"value":258}," ",{"type":46,"tag":109,"props":260,"children":262},{"className":261},[],[263],{"type":52,"value":264},"posthog:scout-project-profile-get",{"type":52,"value":266}," returns the deterministic snapshot the scout itself cold-starts from: products in use, top events with reach\u002Fburst metrics, integrations, existing inbox counts.\nIf the scout watches a specific event, confirm it exists and check its shape with ",{"type":46,"tag":109,"props":268,"children":270},{"className":269},[],[271],{"type":52,"value":272},"posthog:read-data-schema",{"type":52,"value":274},".\nA scout for an event the project doesn't capture is dead on arrival.",{"type":46,"tag":249,"props":276,"children":277},{},[278,283,284,290,292,298,300,306,308,314],{"type":46,"tag":61,"props":279,"children":280},{},[281],{"type":52,"value":282},"See what already runs.",{"type":52,"value":258},{"type":46,"tag":109,"props":285,"children":287},{"className":286},[],[288],{"type":52,"value":289},"posthog:scout-config-list",{"type":52,"value":291}," lists every existing scout on the project with its schedule, ",{"type":46,"tag":109,"props":293,"children":295},{"className":294},[],[296],{"type":52,"value":297},"enabled",{"type":52,"value":299},", and ",{"type":46,"tag":109,"props":301,"children":303},{"className":302},[],[304],{"type":52,"value":305},"emit",{"type":52,"value":307}," posture, plus each scout's ",{"type":46,"tag":109,"props":309,"children":311},{"className":310},[],[312],{"type":52,"value":313},"description",{"type":52,"value":315}," (pulled from the skill's frontmatter) so you can tell what a scout watches without loading its body.\nDon't duplicate a surface a canonical scout already covers — adapt that one instead.",{"type":46,"tag":249,"props":317,"children":318},{},[319,324,326,332,334,340,342,348,350,356],{"type":46,"tag":61,"props":320,"children":321},{},[322],{"type":52,"value":323},"Read the closest canonical scout.",{"type":52,"value":325}," It's your template and your reference shape.\nPull it with ",{"type":46,"tag":109,"props":327,"children":329},{"className":328},[],[330],{"type":52,"value":331},"posthog:skill-get {\"skill_name\": \"signals-scout-\u003Cx>\"}",{"type":52,"value":333}," (per-team rows) or read it from the repo at ",{"type":46,"tag":109,"props":335,"children":337},{"className":336},[],[338],{"type":52,"value":339},"products\u002Fsignals\u002Fskills\u002Fsignals-scout-*\u002F",{"type":52,"value":341},".\nThe generalist (",{"type":46,"tag":109,"props":343,"children":345},{"className":344},[],[346],{"type":52,"value":347},"signals-scout-general",{"type":52,"value":349},") is the broad template; if your scope is domain-tight, pick the specialist closest to your surface — list the live roster with ",{"type":46,"tag":109,"props":351,"children":353},{"className":352},[],[354],{"type":52,"value":355},"posthog:skill-list {\"search\": \"signals-scout\"}",{"type":52,"value":357}," (specialists exist for most product surfaces: error tracking, logs, AI observability, experiments, feature flags, session replay, web analytics, surveys, and more).",{"type":46,"tag":249,"props":359,"children":360},{},[361,366,367,373],{"type":46,"tag":61,"props":362,"children":363},{},[364],{"type":52,"value":365},"Skim the inbox.",{"type":52,"value":258},{"type":46,"tag":109,"props":368,"children":370},{"className":369},[],[371],{"type":52,"value":372},"posthog:inbox-reports-list",{"type":52,"value":374}," shows what reports are actually landing — calibrate so your scout adds signal, not noise.",{"type":46,"tag":204,"props":376,"children":378},{"id":377},"choose-the-path",[379],{"type":52,"value":380},"Choose the path",{"type":46,"tag":55,"props":382,"children":383},{},[384,386,391,393,398],{"type":52,"value":385},"There are two independent decisions: ",{"type":46,"tag":61,"props":387,"children":388},{},[389],{"type":52,"value":390},"what",{"type":52,"value":392}," you're building, and ",{"type":46,"tag":61,"props":394,"children":395},{},[396],{"type":52,"value":397},"where",{"type":52,"value":399}," it lives.",{"type":46,"tag":401,"props":402,"children":403},"h3",{"id":390},[404],{"type":52,"value":405},"What",{"type":46,"tag":407,"props":408,"children":409},"table",{},[410,429],{"type":46,"tag":411,"props":412,"children":413},"thead",{},[414],{"type":46,"tag":415,"props":416,"children":417},"tr",{},[418,424],{"type":46,"tag":419,"props":420,"children":421},"th",{},[422],{"type":52,"value":423},"Situation",{"type":46,"tag":419,"props":425,"children":426},{},[427],{"type":52,"value":428},"Approach",{"type":46,"tag":430,"props":431,"children":432},"tbody",{},[433,452,470,502],{"type":46,"tag":415,"props":434,"children":435},{},[436,442],{"type":46,"tag":437,"props":438,"children":439},"td",{},[440],{"type":52,"value":441},"A canonical scout is close but too broad \u002F too noisy \u002F missing a disqualifier for this project",{"type":46,"tag":437,"props":443,"children":444},{},[445,450],{"type":46,"tag":61,"props":446,"children":447},{},[448],{"type":52,"value":449},"Adapt",{"type":52,"value":451}," it — narrow the scope, add disqualifiers, retune thresholds.",{"type":46,"tag":415,"props":453,"children":454},{},[455,460],{"type":46,"tag":437,"props":456,"children":457},{},[458],{"type":52,"value":459},"You want a surface no canonical scout covers (a custom event, a product-specific funnel)",{"type":46,"tag":437,"props":461,"children":462},{},[463,468],{"type":46,"tag":61,"props":464,"children":465},{},[466],{"type":52,"value":467},"New scout from scratch",{"type":52,"value":469}," — copy the closest canonical scout as scaffolding, replace the domain discriminator + explore patterns.",{"type":46,"tag":415,"props":471,"children":472},{},[473,492],{"type":46,"tag":437,"props":474,"children":475},{},[476,478,484,485,490],{"type":52,"value":477},"You only want to change ",{"type":46,"tag":479,"props":480,"children":481},"em",{},[482],{"type":52,"value":483},"when",{"type":52,"value":116},{"type":46,"tag":479,"props":486,"children":487},{},[488],{"type":52,"value":489},"whether",{"type":52,"value":491}," a scout runs",{"type":46,"tag":437,"props":493,"children":494},{},[495,500],{"type":46,"tag":61,"props":496,"children":497},{},[498],{"type":52,"value":499},"No authoring",{"type":52,"value":501}," — just tune the config (see Run posture).",{"type":46,"tag":415,"props":503,"children":504},{},[505,510],{"type":46,"tag":437,"props":506,"children":507},{},[508],{"type":52,"value":509},"You have one-off feedback, a pointer, or short-lived context for a scout",{"type":46,"tag":437,"props":511,"children":512},{},[513,517],{"type":46,"tag":61,"props":514,"children":515},{},[516],{"type":52,"value":499},{"type":52,"value":518}," — leave a note (see Steering with notes).",{"type":46,"tag":401,"props":520,"children":521},{"id":397},[522],{"type":52,"value":523},"Where",{"type":46,"tag":407,"props":525,"children":526},{},[527,548],{"type":46,"tag":411,"props":528,"children":529},{},[530],{"type":46,"tag":415,"props":531,"children":532},{},[533,538,543],{"type":46,"tag":419,"props":534,"children":535},{},[536],{"type":52,"value":537},"Path",{"type":46,"tag":419,"props":539,"children":540},{},[541],{"type":52,"value":542},"Mechanism",{"type":46,"tag":419,"props":544,"children":545},{},[546],{"type":52,"value":547},"Use when",{"type":46,"tag":430,"props":549,"children":550},{},[551,621],{"type":46,"tag":415,"props":552,"children":553},{},[554,564,616],{"type":46,"tag":437,"props":555,"children":556},{},[557,562],{"type":46,"tag":61,"props":558,"children":559},{},[560],{"type":52,"value":561},"Per-team",{"type":52,"value":563}," (the common user path)",{"type":46,"tag":437,"props":565,"children":566},{},[567,569,575,577,583,585,591,593,599,600,606,608,614],{"type":52,"value":568},"Prepare a new runnable scout via ",{"type":46,"tag":109,"props":570,"children":572},{"className":571},[],[573],{"type":52,"value":574},"posthog:scout-create-prepare",{"type":52,"value":576},", show its confirmation message, wait for the user to type ",{"type":46,"tag":109,"props":578,"children":580},{"className":579},[],[581],{"type":52,"value":582},"confirm",{"type":52,"value":584},", then call ",{"type":46,"tag":109,"props":586,"children":588},{"className":587},[],[589],{"type":52,"value":590},"posthog:scout-create-execute",{"type":52,"value":592},"; edit its prompt or files later via ",{"type":46,"tag":109,"props":594,"children":596},{"className":595},[],[597],{"type":52,"value":598},"posthog:skill-update",{"type":52,"value":116},{"type":46,"tag":109,"props":601,"children":603},{"className":602},[],[604],{"type":52,"value":605},"-file-create",{"type":52,"value":607},", and tune its runtime config via ",{"type":46,"tag":109,"props":609,"children":611},{"className":610},[],[612],{"type":52,"value":613},"posthog:scout-config-update",{"type":52,"value":615},".",{"type":46,"tag":437,"props":617,"children":618},{},[619],{"type":52,"value":620},"Customizing for one project. The harness globs the row in on the next tick; canonical sync leaves your edited (\"diverged\") row alone.",{"type":46,"tag":415,"props":622,"children":623},{},[624,634,646],{"type":46,"tag":437,"props":625,"children":626},{},[627,632],{"type":46,"tag":61,"props":628,"children":629},{},[630],{"type":52,"value":631},"Canonical",{"type":52,"value":633}," (PostHog contributors)",{"type":46,"tag":437,"props":635,"children":636},{},[637,639,644],{"type":52,"value":638},"Edit disk under ",{"type":46,"tag":109,"props":640,"children":642},{"className":641},[],[643],{"type":52,"value":339},{"type":52,"value":645},", lint\u002Fbuild, open a PR.",{"type":46,"tag":437,"props":647,"children":648},{},[649,651,656,658,664],{"type":52,"value":650},"Improving a scout for ",{"type":46,"tag":479,"props":652,"children":653},{},[654],{"type":52,"value":655},"every",{"type":52,"value":657}," enrolled project. ",{"type":46,"tag":109,"props":659,"children":661},{"className":660},[],[662],{"type":52,"value":663},"lazy_seed",{"type":52,"value":665}," mirrors it onto all enrolled teams on the next tick.",{"type":46,"tag":55,"props":667,"children":668},{},[669,674,676,681,683,688,690,695,697,703],{"type":46,"tag":61,"props":670,"children":671},{},[672],{"type":52,"value":673},"Adapting-in-place tradeoff:",{"type":52,"value":675}," editing a canonical scout's row for your team marks it ",{"type":46,"tag":61,"props":677,"children":678},{},[679],{"type":52,"value":680},"diverged",{"type":52,"value":682}," — you stop receiving upstream improvements to that scout.\nIf you only need an ",{"type":46,"tag":479,"props":684,"children":685},{},[686],{"type":52,"value":687},"additional",{"type":52,"value":689}," behavior, prefer authoring a ",{"type":46,"tag":61,"props":691,"children":692},{},[693],{"type":52,"value":694},"new, differently-named",{"type":52,"value":696}," scout (",{"type":46,"tag":109,"props":698,"children":700},{"className":699},[],[701],{"type":52,"value":702},"signals-scout-\u003Cyour-scope>",{"type":52,"value":704},") and leaving the canonical one intact.",{"type":46,"tag":55,"props":706,"children":707},{},[708,710,720],{"type":52,"value":709},"See ",{"type":46,"tag":711,"props":712,"children":714},"a",{"href":713},"references\u002Flifecycle-and-testing.md",[715],{"type":46,"tag":109,"props":716,"children":718},{"className":717},[],[719],{"type":52,"value":713},{"type":52,"value":721}," for the exact skills-store calls, the build\u002Flint commands, and how seeding works.",{"type":46,"tag":204,"props":723,"children":725},{"id":724},"write-the-scout",[726],{"type":52,"value":727},"Write the scout",{"type":46,"tag":55,"props":729,"children":730},{},[731,733,738,740,749,751,756],{"type":52,"value":732},"First pick the ",{"type":46,"tag":61,"props":734,"children":735},{},[736],{"type":52,"value":737},"shape",{"type":52,"value":739},".\n",{"type":46,"tag":711,"props":741,"children":743},{"href":742},"references\u002Fscout-patterns.md",[744],{"type":46,"tag":109,"props":745,"children":747},{"className":746},[],[748],{"type":52,"value":742},{"type":52,"value":750}," is a cookbook of the reference architectures scouts fall into — anomaly watcher, liveness\u002Fabsence watcher, watchlist explore\u002Fexploit, cross-product correlation, recommendation\u002Fgap, warehouse-backed source, custom single-event, open-text theme, external-tool\u002Fcode, state∩code intersection, daily digest\u002Froll-up, triage over a pre-detected stream, first-person dogfooding\u002Fprobe — each mapped to a canonical scout you can copy as scaffolding.\nIt also makes the key point that ",{"type":46,"tag":61,"props":752,"children":753},{},[754],{"type":52,"value":755},"a scout can watch any source PostHog ingests into the data warehouse, not just analytics events",{"type":52,"value":757}," (a Slack channel sync, a billing system, a CRM, a support inbox), plus external systems reachable from the sandbox.\nFind the closest pattern, then write the body.",{"type":46,"tag":55,"props":759,"children":760},{},[761,763,772,774,779],{"type":52,"value":762},"Follow ",{"type":46,"tag":711,"props":764,"children":766},{"href":765},"references\u002Fscout-anatomy.md",[767],{"type":46,"tag":109,"props":768,"children":770},{"className":769},[],[771],{"type":52,"value":765},{"type":52,"value":773}," — it has the frontmatter schema (including the ",{"type":46,"tag":109,"props":775,"children":777},{"className":776},[],[778],{"type":52,"value":130},{"type":52,"value":780}," report-channel opt-in every scout needs), the canonical body structure (quick close-out → orient → domain discriminator → explore patterns → save-memory → decide → disqualifiers → close-out), the lean-body rule, and copy-ready skeleton templates for both a specialist and the generalist.",{"type":46,"tag":55,"props":782,"children":783},{},[784,786,791,793,798],{"type":52,"value":785},"Two craft references the whole fleet reasons in terms of — a good scout's ",{"type":46,"tag":61,"props":787,"children":788},{},[789],{"type":52,"value":790},"Decide",{"type":52,"value":792}," and ",{"type":46,"tag":61,"props":794,"children":795},{},[796],{"type":52,"value":797},"memory",{"type":52,"value":799}," sections are built on them, so read them before writing those sections:",{"type":46,"tag":801,"props":802,"children":803},"ul",{},[804,876],{"type":46,"tag":249,"props":805,"children":806},{},[807,816,818,824,825,831,833,839,841,847,849,855,856,862,864,869,870,875],{"type":46,"tag":711,"props":808,"children":810},{"href":809},"references\u002Freport-contract.md",[811],{"type":46,"tag":109,"props":812,"children":814},{"className":813},[],[815],{"type":52,"value":809},{"type":52,"value":817}," — the report tools (",{"type":46,"tag":109,"props":819,"children":821},{"className":820},[],[822],{"type":52,"value":823},"scout-emit-report",{"type":52,"value":116},{"type":46,"tag":109,"props":826,"children":828},{"className":827},[],[829],{"type":52,"value":830},"scout-edit-report",{"type":52,"value":832},"), the report bar (author 1:1 only for a finding you'd own end-to-end), ",{"type":46,"tag":109,"props":834,"children":836},{"className":835},[],[837],{"type":52,"value":838},"suggested_reviewers",{"type":52,"value":840}," routing, the dedup-via-",{"type":46,"tag":109,"props":842,"children":844},{"className":843},[],[845],{"type":52,"value":846},"report_id",{"type":52,"value":848}," discipline (the channel isn't idempotent — reconcile against existing reports via the vanilla ",{"type":46,"tag":109,"props":850,"children":852},{"className":851},[],[853],{"type":52,"value":854},"inbox-reports-list",{"type":52,"value":116},{"type":46,"tag":109,"props":857,"children":859},{"className":858},[],[860],{"type":52,"value":861},"inbox-reports-retrieve",{"type":52,"value":863}," before authoring), and the accepted caveat that the pipeline may later rewrite an authored title\u002Fsummary.\nThis is how your scout decides ",{"type":46,"tag":479,"props":865,"children":866},{},[867],{"type":52,"value":868},"what clears the bar",{"type":52,"value":792},{"type":46,"tag":479,"props":871,"children":872},{},[873],{"type":52,"value":874},"how to file it",{"type":52,"value":615},{"type":46,"tag":249,"props":877,"children":878},{},[879,888],{"type":46,"tag":711,"props":880,"children":882},{"href":881},"references\u002Fdedupe-and-memory.md",[883],{"type":46,"tag":109,"props":884,"children":886},{"className":885},[],[887],{"type":52,"value":881},{"type":52,"value":889}," — the four-states classifier (net-new \u002F material-update \u002F already-covered \u002F addressed-or-noise), the scratchpad key-prefix vocabulary, and the cross-project noise patterns.\nThis is how your scout avoids re-filing and learns across runs.",{"type":46,"tag":55,"props":891,"children":892},{},[893,895,900,902,908,910,916],{"type":52,"value":894},"The single most important design decision in any scout is its ",{"type":46,"tag":61,"props":896,"children":897},{},[898],{"type":52,"value":899},"signal-vs-noise discriminator",{"type":52,"value":901}," — the cheap profile-shape read that separates \"worth investigating\" from \"baseline\".\nFor error tracking it's the ",{"type":46,"tag":109,"props":903,"children":905},{"className":904},[],[906],{"type":52,"value":907},"count",{"type":52,"value":909}," vs ",{"type":46,"tag":109,"props":911,"children":913},{"className":912},[],[914],{"type":52,"value":915},"distinct_users",{"type":52,"value":917}," ratio; for CSP it's reach over raw count.\nYour new scout needs its own.\nName it explicitly near the top of the body so every run anchors on it.",{"type":46,"tag":204,"props":919,"children":921},{"id":920},"run-posture-config",[922],{"type":52,"value":923},"Run posture (config)",{"type":46,"tag":55,"props":925,"children":926},{},[927,929,935,937,942,944,950,952,957,959,964,966,971,972,977,979,985,987,992,994,999,1001,1007,1009,1015],{"type":52,"value":928},"A scout's schedule and emit behavior live on its ",{"type":46,"tag":109,"props":930,"children":932},{"className":931},[],[933],{"type":52,"value":934},"SignalScoutConfig",{"type":52,"value":936},", separate from the skill body.\nFor a ",{"type":46,"tag":61,"props":938,"children":939},{},[940],{"type":52,"value":941},"brand-new scout",{"type":52,"value":943},", pass these settings in the nested ",{"type":46,"tag":109,"props":945,"children":947},{"className":946},[],[948],{"type":52,"value":949},"config",{"type":52,"value":951}," object of the ",{"type":46,"tag":109,"props":953,"children":955},{"className":954},[],[956],{"type":52,"value":574},{"type":52,"value":958}," call, including creating it disabled or in dry-run ",{"type":46,"tag":61,"props":960,"children":961},{},[962],{"type":52,"value":963},"before it ever runs",{"type":52,"value":965},".\nShow the returned confirmation message, wait for the user to type ",{"type":46,"tag":109,"props":967,"children":969},{"className":968},[],[970],{"type":52,"value":582},{"type":52,"value":584},{"type":46,"tag":109,"props":973,"children":975},{"className":974},[],[976],{"type":52,"value":590},{"type":52,"value":978}," with the returned ",{"type":46,"tag":109,"props":980,"children":982},{"className":981},[],[983],{"type":52,"value":984},"confirmation_hash",{"type":52,"value":986}," and that literal confirmation.\nThe endpoint creates the skill and config atomically, always opts the scout into the report channel, and safely re-applies config fields when the same definition is retried.\nOtherwise the coordinator auto-registers an enabled config on the default every-24-hours schedule on its next tick (up to ~30 min).\nFor an ",{"type":46,"tag":61,"props":988,"children":989},{},[990],{"type":52,"value":991},"existing scout",{"type":52,"value":993},", tune with ",{"type":46,"tag":109,"props":995,"children":997},{"className":996},[],[998],{"type":52,"value":613},{"type":52,"value":1000}," (find the ",{"type":46,"tag":109,"props":1002,"children":1004},{"className":1003},[],[1005],{"type":52,"value":1006},"id",{"type":52,"value":1008}," via ",{"type":46,"tag":109,"props":1010,"children":1012},{"className":1011},[],[1013],{"type":52,"value":1014},"-config-list",{"type":52,"value":1016},"):",{"type":46,"tag":801,"props":1018,"children":1019},{},[1020,1031,1049],{"type":46,"tag":249,"props":1021,"children":1022},{},[1023,1029],{"type":46,"tag":109,"props":1024,"children":1026},{"className":1025},[],[1027],{"type":52,"value":1028},"run_interval_minutes",{"type":52,"value":1030}," — 30 to 43200.\nDefault 1440 (every 24 hours).\nSlow a chatty or expensive scout by raising this.",{"type":46,"tag":249,"props":1032,"children":1033},{},[1034,1039,1041,1047],{"type":46,"tag":109,"props":1035,"children":1037},{"className":1036},[],[1038],{"type":52,"value":297},{"type":52,"value":1040}," — ",{"type":46,"tag":109,"props":1042,"children":1044},{"className":1043},[],[1045],{"type":52,"value":1046},"false",{"type":52,"value":1048}," pauses the scout entirely (coordinator skips it).",{"type":46,"tag":249,"props":1050,"children":1051},{},[1052,1057,1059,1068,1070,1081],{"type":46,"tag":109,"props":1053,"children":1055},{"className":1054},[],[1056],{"type":52,"value":305},{"type":52,"value":1058}," — defaults to ",{"type":46,"tag":61,"props":1060,"children":1061},{},[1062],{"type":46,"tag":109,"props":1063,"children":1065},{"className":1064},[],[1066],{"type":52,"value":1067},"true",{"type":52,"value":1069},": the scout writes its reports straight to the inbox.\nThe standard flow is to make a scout and let it write — seeing what actually lands is the fastest way to calibrate it.\nSet ",{"type":46,"tag":61,"props":1071,"children":1072},{},[1073,1079],{"type":46,"tag":109,"props":1074,"children":1076},{"className":1075},[],[1077],{"type":52,"value":1078},"emit=false",{"type":52,"value":1080}," (dry-run)",{"type":52,"value":1082}," only when you want to be extra careful: the scout still runs and logs its reasoning but writes nothing to the inbox.\nReach 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.",{"type":46,"tag":204,"props":1084,"children":1086},{"id":1085},"steering-with-notes-no-authoring-needed",[1087],{"type":52,"value":1088},"Steering with notes (no authoring needed)",{"type":46,"tag":55,"props":1090,"children":1091},{},[1092,1094,1099,1101,1106],{"type":52,"value":1093},"Sometimes you don't want to change the scout — you want to ",{"type":46,"tag":479,"props":1095,"children":1096},{},[1097],{"type":52,"value":1098},"tell it something",{"type":52,"value":1100},".\nThat's what ",{"type":46,"tag":61,"props":1102,"children":1103},{},[1104],{"type":52,"value":1105},"scout notes",{"type":52,"value":1107}," are for: short steering messages any team member (or an agent acting for one) leaves for the fleet, which every run picks up as prior context alongside its scratchpad and run history.\nReach for a note instead of an edit when the steer is feedback, a pointer, or context with a shelf life:",{"type":46,"tag":801,"props":1109,"children":1110},{},[1111,1116,1121],{"type":46,"tag":249,"props":1112,"children":1113},{},[1114],{"type":52,"value":1115},"Feedback on output: \"the staging traffic spike you keep flagging is known noise, stop reporting it\".",{"type":46,"tag":249,"props":1117,"children":1118},{},[1119],{"type":52,"value":1120},"A pointer: \"dig into the EU signup funnel this week — we think something regressed\".",{"type":46,"tag":249,"props":1122,"children":1123},{},[1124],{"type":52,"value":1125},"Context the scout couldn't know: \"we shipped a new checkout on Tuesday, treat conversion shifts after that as expected\".",{"type":46,"tag":55,"props":1127,"children":1128},{},[1129,1131,1137,1139,1145],{"type":52,"value":1130},"The tools (reads on the public ",{"type":46,"tag":109,"props":1132,"children":1134},{"className":1133},[],[1135],{"type":52,"value":1136},"signal_scout:read",{"type":52,"value":1138}," scope; because scouts read notes verbatim, writing or deleting one requires the same authorization as editing a scout's skill — the ",{"type":46,"tag":109,"props":1140,"children":1142},{"className":1141},[],[1143],{"type":52,"value":1144},"llm_skill:write",{"type":52,"value":1146}," scope plus skill editor access):",{"type":46,"tag":801,"props":1148,"children":1149},{},[1150,1185,1203],{"type":46,"tag":249,"props":1151,"children":1152},{},[1153,1159,1161,1167,1169,1175,1177,1183],{"type":46,"tag":109,"props":1154,"children":1156},{"className":1155},[],[1157],{"type":52,"value":1158},"posthog:scout-notes-create {\"content\": \"...\", \"skill_name\": \"signals-scout-web-analytics\"}",{"type":52,"value":1160}," — address one scout by its exact skill name (roster via ",{"type":46,"tag":109,"props":1162,"children":1164},{"className":1163},[],[1165],{"type":52,"value":1166},"scout-config-list",{"type":52,"value":1168},"; the skill must already exist, so a typo'd target is rejected instead of silently steering no one), or omit ",{"type":46,"tag":109,"props":1170,"children":1172},{"className":1171},[],[1173],{"type":52,"value":1174},"skill_name",{"type":52,"value":1176}," for a general note every scout sees.\nOptionally set ",{"type":46,"tag":109,"props":1178,"children":1180},{"className":1179},[],[1181],{"type":52,"value":1182},"expires_at",{"type":52,"value":1184}," so a time-boxed note (\"watch closely this week\") retires itself.",{"type":46,"tag":249,"props":1186,"children":1187},{},[1188,1194,1196,1201],{"type":46,"tag":109,"props":1189,"children":1191},{"className":1190},[],[1192],{"type":52,"value":1193},"posthog:scout-notes-list",{"type":52,"value":1195}," — browse the active notes; pass ",{"type":46,"tag":109,"props":1197,"children":1199},{"className":1198},[],[1200],{"type":52,"value":1174},{"type":52,"value":1202}," to see what a given scout will read.",{"type":46,"tag":249,"props":1204,"children":1205},{},[1206,1212],{"type":46,"tag":109,"props":1207,"children":1209},{"className":1208},[],[1210],{"type":52,"value":1211},"posthog:scout-notes-delete {\"id\": \"...\"}",{"type":52,"value":1213}," — retire a note that's been acted on or no longer applies.",{"type":46,"tag":55,"props":1215,"children":1216},{},[1217,1219,1224],{"type":52,"value":1218},"How scouts treat notes: every run reads its notes in step 1 and is told to let a fresh note visibly shape what it investigates — but notes are ",{"type":46,"tag":61,"props":1220,"children":1221},{},[1222],{"type":52,"value":1223},"advisory",{"type":52,"value":1225},".\nThey direct attention; they don't lower the scout's evidence bar or force a report, so a note saying \"report X\" still gets an honest investigation, not an automatic emit.\nThe scout closes the loop in its run summary (which notes it acted on and how) and folds absorbed guidance into its scratchpad.",{"type":46,"tag":55,"props":1227,"children":1228},{},[1229,1231,1236,1238,1243],{"type":52,"value":1230},"Choosing between a note and an edit: a note is the right tool for ",{"type":46,"tag":479,"props":1232,"children":1233},{},[1234],{"type":52,"value":1235},"this project, right now",{"type":52,"value":1237}," steering and for trying a nudge before committing to it; a skill edit is the right tool once the steer is permanent policy (a disqualifier, a threshold, a scope change).\nA note that you keep re-leaving is a skill edit waiting to happen — promote it.\nNote lifecycle stays with humans: scouts never delete notes, so retire acted-on notes yourself (or set ",{"type":46,"tag":109,"props":1239,"children":1241},{"className":1240},[],[1242],{"type":52,"value":1182},{"type":52,"value":1244}," up front) to keep the channel high-signal.",{"type":46,"tag":204,"props":1246,"children":1248},{"id":1247},"test-loop",[1249],{"type":52,"value":1250},"Test loop",{"type":46,"tag":55,"props":1252,"children":1253},{},[1254,1259,1261,1267,1269,1275,1277,1283,1285,1290,1292,1297,1299,1304],{"type":46,"tag":61,"props":1255,"children":1256},{},[1257],{"type":52,"value":1258},"Dogfood the scout yourself before you ever spend a real run.",{"type":52,"value":1260}," You — the agent authoring the scout — have the same PostHog MCP tools a scout uses at runtime (",{"type":46,"tag":109,"props":1262,"children":1264},{"className":1263},[],[1265],{"type":52,"value":1266},"execute-sql",{"type":52,"value":1268},", ",{"type":46,"tag":109,"props":1270,"children":1272},{"className":1271},[],[1273],{"type":52,"value":1274},"read-data-schema",{"type":52,"value":1276},", the per-product list tools, ",{"type":46,"tag":109,"props":1278,"children":1280},{"className":1279},[],[1281],{"type":52,"value":1282},"scout-project-profile-get",{"type":52,"value":1284},").\nThe cheapest, fastest iteration doesn't touch a scout run at all: walk the scout's own logic against the live project by hand.\nConfirm the watched event\u002Fentity exists and has the shape you assumed, run the ",{"type":46,"tag":61,"props":1286,"children":1287},{},[1288],{"type":52,"value":1289},"discriminator",{"type":52,"value":1291}," to check it actually separates signal from noise on ",{"type":46,"tag":479,"props":1293,"children":1294},{},[1295],{"type":52,"value":1296},"this",{"type":52,"value":1298}," project's data, and run each ",{"type":46,"tag":61,"props":1300,"children":1301},{},[1302],{"type":52,"value":1303},"explore pattern",{"type":52,"value":1305},"'s queries to see what they surface.\nThis 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.\nThis is where the real iteration happens.",{"type":46,"tag":55,"props":1307,"children":1308},{},[1309,1311,1317,1319,1324,1325,1330,1332,1337,1339,1345,1347,1352,1354,1360,1361,1367],{"type":52,"value":1310},"Only once you're happy with the body do you spend an actual run.\n",{"type":46,"tag":109,"props":1312,"children":1314},{"className":1313},[],[1315],{"type":52,"value":1316},"posthog:scout-run-now {\"id\": \u003Cconfig_id>}",{"type":52,"value":1318}," dispatches one run of the scout immediately, regardless of its schedule (find the ",{"type":46,"tag":109,"props":1320,"children":1322},{"className":1321},[],[1323],{"type":52,"value":1006},{"type":52,"value":1008},{"type":46,"tag":109,"props":1326,"children":1328},{"className":1327},[],[1329],{"type":52,"value":1014},{"type":52,"value":1331},").\nThis is the ",{"type":46,"tag":61,"props":1333,"children":1334},{},[1335],{"type":52,"value":1336},"initial real run",{"type":52,"value":1338}," — the scout executing end-to-end in the harness, writing scratchpad memory and (with the default ",{"type":46,"tag":109,"props":1340,"children":1342},{"className":1341},[],[1343],{"type":52,"value":1344},"emit=true",{"type":52,"value":1346},") writing reports to the inbox.\nThe run is ",{"type":46,"tag":61,"props":1348,"children":1349},{},[1350],{"type":52,"value":1351},"asynchronous",{"type":52,"value":1353},": the call returns a workflow id right away, so poll ",{"type":46,"tag":109,"props":1355,"children":1357},{"className":1356},[],[1358],{"type":52,"value":1359},"-runs-list",{"type":52,"value":116},{"type":46,"tag":109,"props":1362,"children":1364},{"className":1363},[],[1365],{"type":52,"value":1366},"-runs-retrieve",{"type":52,"value":1368}," for the result.\nA few things to know:",{"type":46,"tag":801,"props":1370,"children":1371},{},[1372,1383,1402,1407],{"type":46,"tag":249,"props":1373,"children":1374},{},[1375,1376,1381],{"type":52,"value":59},{"type":46,"tag":61,"props":1377,"children":1378},{},[1379],{"type":52,"value":1380},"disabled",{"type":52,"value":1382}," scout can still be run this way — you can test it before ever enabling it.",{"type":46,"tag":249,"props":1384,"children":1385},{},[1386,1388,1393,1395,1401],{"type":52,"value":1387},"A manual run does ",{"type":46,"tag":61,"props":1389,"children":1390},{},[1391],{"type":52,"value":1392},"not",{"type":52,"value":1394}," change the scout's schedule or ",{"type":46,"tag":109,"props":1396,"children":1398},{"className":1397},[],[1399],{"type":52,"value":1400},"last_run_at",{"type":52,"value":615},{"type":46,"tag":249,"props":1403,"children":1404},{},[1405],{"type":52,"value":1406},"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.",{"type":46,"tag":249,"props":1408,"children":1409},{},[1410,1412,1417,1419,1424,1426,1432,1434,1446,1448,1453],{"type":52,"value":1411},"It draws from the ",{"type":46,"tag":61,"props":1413,"children":1414},{},[1415],{"type":52,"value":1416},"same daily run budget",{"type":52,"value":1418}," as scheduled runs — and a dry-run (",{"type":46,"tag":109,"props":1420,"children":1422},{"className":1421},[],[1423],{"type":52,"value":1078},{"type":52,"value":1425},") still consumes a run.\nThere's no free test run: every ",{"type":46,"tag":109,"props":1427,"children":1429},{"className":1428},[],[1430],{"type":52,"value":1431},"-run-now",{"type":52,"value":1433}," 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).\n",{"type":46,"tag":61,"props":1435,"children":1436},{},[1437,1439,1444],{"type":52,"value":1438},"Don't use ",{"type":46,"tag":109,"props":1440,"children":1442},{"className":1441},[],[1443],{"type":52,"value":1431},{"type":52,"value":1445}," as your iteration loop",{"type":52,"value":1447}," — it's slow (async, one run per call) and metered.\nDogfood the queries by hand to get the body right; reserve ",{"type":46,"tag":109,"props":1449,"children":1451},{"className":1450},[],[1452],{"type":52,"value":1431},{"type":52,"value":1454}," for the initial real run and the occasional re-check after a genuinely meaningful change.",{"type":46,"tag":55,"props":1456,"children":1457},{},[1458,1460,1465],{"type":52,"value":1459},"The standard loop is ",{"type":46,"tag":61,"props":1461,"children":1462},{},[1463],{"type":52,"value":1464},"dogfood → run once ready → inspect",{"type":52,"value":1466},":",{"type":46,"tag":245,"props":1468,"children":1469},{},[1470,1475,1523,1558],{"type":46,"tag":249,"props":1471,"children":1472},{},[1473],{"type":52,"value":1474},"Dogfood the discriminator + explore patterns yourself against the live project (above).\nRefine the body until the logic holds on real data — this is the cheap, iterable part.",{"type":46,"tag":249,"props":1476,"children":1477},{},[1478,1480,1485,1487,1493,1495,1500,1502,1507,1509,1514,1516,1521],{"type":52,"value":1479},"Create the scout and its config together via ",{"type":46,"tag":109,"props":1481,"children":1483},{"className":1482},[],[1484],{"type":52,"value":574},{"type":52,"value":1486}," → ",{"type":46,"tag":109,"props":1488,"children":1490},{"className":1489},[],[1491],{"type":52,"value":1492},"-execute",{"type":52,"value":1494}," (schedule and the default ",{"type":46,"tag":109,"props":1496,"children":1498},{"className":1497},[],[1499],{"type":52,"value":1344},{"type":52,"value":1501}," go in the nested ",{"type":46,"tag":109,"props":1503,"children":1505},{"className":1504},[],[1506],{"type":52,"value":949},{"type":52,"value":1508},"), then spend one ",{"type":46,"tag":109,"props":1510,"children":1512},{"className":1511},[],[1513],{"type":52,"value":1431},{"type":52,"value":1515}," to watch the whole scout execute end-to-end.\nLeave ",{"type":46,"tag":109,"props":1517,"children":1519},{"className":1518},[],[1520],{"type":52,"value":1028},{"type":52,"value":1522}," at a sustainable value — you no longer need a short interval to force an early run.",{"type":46,"tag":249,"props":1524,"children":1525},{},[1526,1528,1533,1535,1541,1543,1548,1550,1556],{"type":52,"value":1527},"After the run finishes, read what it did: ",{"type":46,"tag":109,"props":1529,"children":1531},{"className":1530},[],[1532],{"type":52,"value":372},{"type":52,"value":1534}," (the reports it actually wrote), ",{"type":46,"tag":109,"props":1536,"children":1538},{"className":1537},[],[1539],{"type":52,"value":1540},"posthog:scout-runs-list",{"type":52,"value":1542}," (run summaries), ",{"type":46,"tag":109,"props":1544,"children":1546},{"className":1545},[],[1547],{"type":52,"value":1366},{"type":52,"value":1549}," (full reasoning for one run), and ",{"type":46,"tag":109,"props":1551,"children":1553},{"className":1552},[],[1554],{"type":52,"value":1555},"-scratchpad-search",{"type":52,"value":1557}," (the durable memory it wrote).",{"type":46,"tag":249,"props":1559,"children":1560},{},[1561,1563,1568],{"type":52,"value":1562},"If it needs work, go back to dogfooding the queries by hand for the iteration — only spend another ",{"type":46,"tag":109,"props":1564,"children":1566},{"className":1565},[],[1567],{"type":52,"value":1431},{"type":52,"value":1569}," once you've batched a meaningful change worth a fresh end-to-end run.",{"type":46,"tag":55,"props":1571,"children":1572},{},[1573,1575,1580,1582,1588,1590,1596,1598,1604,1605,1610,1612,1618,1620,1625],{"type":52,"value":1574},"When tuning an ",{"type":46,"tag":61,"props":1576,"children":1577},{},[1578],{"type":52,"value":1579},"existing custom scout",{"type":52,"value":1581},", also check its self-improvement suggestions first: ",{"type":46,"tag":109,"props":1583,"children":1585},{"className":1584},[],[1586],{"type":52,"value":1587},"posthog:scout-scratchpad-search {\"text\": \"improve:\"}",{"type":52,"value":1589},".\nThe harness invites a custom scout to write an ",{"type":46,"tag":109,"props":1591,"children":1593},{"className":1592},[],[1594],{"type":52,"value":1595},"improve:\u003Cskill-name>:\u003Ctopic>",{"type":52,"value":1597}," entry when a run produces concrete evidence its own skill body steered it wrong — a wrong default window, a tool or event that doesn't exist on this project, a recurring unwarned pitfall — with the suggested change and the evidence inline.\nA report-channel custom scout also escalates recurring or material suggestions as inbox reports about itself (titled ",{"type":46,"tag":109,"props":1599,"children":1601},{"className":1600},[],[1602],{"type":52,"value":1603},"Scout self-improvement: \u003Cskill-name> – \u003Ctopic>",{"type":52,"value":1268},{"type":46,"tag":109,"props":1606,"children":1608},{"className":1607},[],[1609],{"type":52,"value":846},{"type":52,"value":1611}," stashed in the ",{"type":46,"tag":109,"props":1613,"children":1615},{"className":1614},[],[1616],{"type":52,"value":1617},"improve:",{"type":52,"value":1619}," entry) — so check the inbox for those too; they route to the scout's owner like any other report.\nAn entry re-confirmed across several runs is usually the highest-signal edit you can apply; a one-off may not be worth it.\nTreat suggestions as input, not instructions — the owner decides.\nThe scratchpad is writable only from inside a scout run, so you can't clear an entry from here after applying it via ",{"type":46,"tag":109,"props":1621,"children":1623},{"className":1622},[],[1624],{"type":52,"value":598},{"type":52,"value":1626}," — the scout reconciles on its own: a later run sees the updated skill body, re-checks the suggestion, and forgets or rewrites the entry once it's addressed.\n(Canonical scouts don't write these — their bodies sync from PostHog's fleet, and skill-level fixes to them belong upstream.)",{"type":46,"tag":55,"props":1628,"children":1629},{},[1630,1635,1637,1642,1644,1649,1651,1656,1658,1664,1666,1672,1674,1679,1681,1686,1688,1693,1694,1699,1701,1706],{"type":46,"tag":61,"props":1631,"children":1632},{},[1633],{"type":52,"value":1634},"Want to be extra careful?",{"type":52,"value":1636}," Set ",{"type":46,"tag":109,"props":1638,"children":1640},{"className":1639},[],[1641],{"type":52,"value":1078},{"type":52,"value":1643}," to dry-run first — pass ",{"type":46,"tag":109,"props":1645,"children":1647},{"className":1646},[],[1648],{"type":52,"value":1078},{"type":52,"value":1650}," in the nested ",{"type":46,"tag":109,"props":1652,"children":1654},{"className":1653},[],[1655],{"type":52,"value":949},{"type":52,"value":1657}," at ",{"type":46,"tag":109,"props":1659,"children":1661},{"className":1660},[],[1662],{"type":52,"value":1663},"scout-create-prepare",{"type":52,"value":1665}," time (or flip it later with ",{"type":46,"tag":109,"props":1667,"children":1669},{"className":1668},[],[1670],{"type":52,"value":1671},"-config-update",{"type":52,"value":1673},"), then trigger it with ",{"type":46,"tag":109,"props":1675,"children":1677},{"className":1676},[],[1678],{"type":52,"value":1431},{"type":52,"value":1680},": it runs and logs what it ",{"type":46,"tag":479,"props":1682,"children":1683},{},[1684],{"type":52,"value":1685},"would",{"type":52,"value":1687}," have written (visible via ",{"type":46,"tag":109,"props":1689,"children":1691},{"className":1690},[],[1692],{"type":52,"value":1359},{"type":52,"value":116},{"type":46,"tag":109,"props":1695,"children":1697},{"className":1696},[],[1698],{"type":52,"value":1366},{"type":52,"value":1700},") without writing to the inbox.\nInspect, refine, then flip ",{"type":46,"tag":109,"props":1702,"children":1704},{"className":1703},[],[1705],{"type":52,"value":1344},{"type":52,"value":1707}," and run it again.\nWorth it for a scout you expect to be chatty, expensive, or high-stakes; otherwise just writing and watching the inbox is the faster path to a calibrated scout.",{"type":46,"tag":55,"props":1709,"children":1710},{},[1711,1713,1719,1721,1729],{"type":52,"value":1712},"Repo contributors get a faster loop — ",{"type":46,"tag":109,"props":1714,"children":1716},{"className":1715},[],[1717],{"type":52,"value":1718},"hogli sync:skill",{"type":52,"value":1720}," and the harness's local run path; see ",{"type":46,"tag":711,"props":1722,"children":1723},{"href":713},[1724],{"type":46,"tag":109,"props":1725,"children":1727},{"className":1726},[],[1728],{"type":52,"value":713},{"type":52,"value":615},{"type":46,"tag":55,"props":1731,"children":1732},{},[1733,1735,1740,1742,1748],{"type":52,"value":1734},"To ",{"type":46,"tag":61,"props":1736,"children":1737},{},[1738],{"type":52,"value":1739},"read",{"type":52,"value":1741}," what your scouts are doing rather than change them — surveying the fleet, inspecting individual runs, the scratchpad memory, and assessing performance — use the read-only companion skill ",{"type":46,"tag":109,"props":1743,"children":1745},{"className":1744},[],[1746],{"type":52,"value":1747},"exploring-scouts",{"type":52,"value":1749},".\nKeep the two in sync when the scout config \u002F run \u002F scratchpad surfaces change.",{"type":46,"tag":204,"props":1751,"children":1753},{"id":1752},"quality-bar-for-a-v1-scout",[1754],{"type":52,"value":1755},"Quality bar for a v1 scout",{"type":46,"tag":801,"props":1757,"children":1758},{},[1759,1770,1781,1793,1803,1820,1830,1843],{"type":46,"tag":249,"props":1760,"children":1761},{},[1762,1764,1768],{"type":52,"value":1763},"A named, cheap ",{"type":46,"tag":61,"props":1765,"children":1766},{},[1767],{"type":52,"value":899},{"type":52,"value":1769}," anchored near the top.",{"type":46,"tag":249,"props":1771,"children":1772},{},[1773,1774,1779],{"type":52,"value":59},{"type":46,"tag":61,"props":1775,"children":1776},{},[1777],{"type":52,"value":1778},"quick close-out",{"type":52,"value":1780}," so a quiet run is cheap (don't pay for deep exploration when the watched surface is at baseline or absent).",{"type":46,"tag":249,"props":1782,"children":1783},{},[1784,1786,1791],{"type":52,"value":1785},"2–4 concrete ",{"type":46,"tag":61,"props":1787,"children":1788},{},[1789],{"type":52,"value":1790},"explore patterns",{"type":52,"value":1792}," with the actual queries\u002Ftools to run — starting points, not a rigid checklist.",{"type":46,"tag":249,"props":1794,"children":1795},{},[1796,1801],{"type":46,"tag":61,"props":1797,"children":1798},{},[1799],{"type":52,"value":1800},"Disqualifiers",{"type":52,"value":1802}," listing this project's known noise (single-user quirks, dev-env bursts, allowlisted entities).",{"type":46,"tag":249,"props":1804,"children":1805},{},[1806,1807,1811,1813,1818],{"type":52,"value":59},{"type":46,"tag":61,"props":1808,"children":1809},{},[1810],{"type":52,"value":790},{"type":52,"value":1812}," section calibrated against the report contract — author 1:1 only for a finding the scout would own end-to-end, set ",{"type":46,"tag":109,"props":1814,"children":1816},{"className":1815},[],[1817],{"type":52,"value":838},{"type":52,"value":1819},", and write memory instead when a candidate is below the bar.",{"type":46,"tag":249,"props":1821,"children":1822},{},[1823,1828],{"type":46,"tag":61,"props":1824,"children":1825},{},[1826],{"type":52,"value":1827},"Save-memory",{"type":52,"value":1829}," guidance using the scratchpad prefixes so the scout gets smarter each run.",{"type":46,"tag":249,"props":1831,"children":1832},{},[1833,1835,1841],{"type":52,"value":1834},"A lean body (push depth into ",{"type":46,"tag":109,"props":1836,"children":1838},{"className":1837},[],[1839],{"type":52,"value":1840},"references\u002F",{"type":52,"value":1842},") — every line is a recurring token cost on every run.",{"type":46,"tag":249,"props":1844,"children":1845},{},[1846,1847,1857],{"type":52,"value":59},{"type":46,"tag":61,"props":1848,"children":1849},{},[1850,1852],{"type":52,"value":1851},"tight frontmatter ",{"type":46,"tag":109,"props":1853,"children":1855},{"className":1854},[],[1856],{"type":52,"value":313},{"type":52,"value":1858}," — a sentence or two naming the surface and the shapes it watches.\nEvery scout's description loads into the caller's AI plugin together, so wordy descriptions waste token budget and get truncated; skip the fleet-wide boilerplate (report bar, durable memory, self-contained peer).",{"items":1860,"total":1970},[1861,1878,1896,1913,1920,1934,1952],{"slug":1862,"name":1862,"fn":1863,"description":1864,"org":1865,"tags":1866,"stars":23,"repoUrl":24,"updatedAt":1877},"analyzing-experiment-session-replays","analyze session replays for PostHog experiments","Analyze session replay patterns across experiment variants to understand user behavior differences. Use when the user wants to see how users interact with different experiment variants, identify usability issues, compare behavior patterns between control and test groups, or get qualitative insights to complement quantitative experiment results.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1867,1870,1873,1874],{"name":1868,"slug":1869,"type":15},"Analytics","analytics",{"name":1871,"slug":1872,"type":15},"Design","design",{"name":9,"slug":8,"type":15},{"name":1875,"slug":1876,"type":15},"User Research","user-research","2026-04-06T18:44:38.291781",{"slug":1879,"name":1879,"fn":1880,"description":1881,"org":1882,"tags":1883,"stars":23,"repoUrl":24,"updatedAt":1895},"assessing-heatmaps","analyze page heatmaps and suggest improvements","Assesses what a page's heatmap is telling you and recommends concrete changes. Pulls click \u002F rageclick \u002F scroll-depth data for a URL, names the hot elements by cross-referencing autocapture events on the same page, and can create a saved heatmap the user opens in PostHog, then summarizes the behavior and proposes improvements.\nTRIGGER when: user asks what a heatmap shows, why people aren't clicking something, where users rage-click, how far they scroll, what to change on a page based on heatmap\u002Fclick data, or to 'analyze\u002Fassess\u002Freview the heatmap' for a URL.\nDO NOT TRIGGER when: the user only wants to create a saved heatmap screenshot with no analysis (use heatmaps-saved-create directly), or is asking about session replay in general (use investigating-replay).",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1884,1885,1888,1889,1892],{"name":1868,"slug":1869,"type":15},{"name":1886,"slug":1887,"type":15},"Frontend","frontend",{"name":9,"slug":8,"type":15},{"name":1890,"slug":1891,"type":15},"Product Management","product-management",{"name":1893,"slug":1894,"type":15},"UX Design","ux-design","2026-06-05T07:40:43.37798",{"slug":1897,"name":1897,"fn":1898,"description":1899,"org":1900,"tags":1901,"stars":23,"repoUrl":24,"updatedAt":1912},"auditing-experiments-flags","audit PostHog experiments and feature flags","Audit PostHog experiments and feature flags for configuration issues, staleness, and best-practice violations. Read when the user asks to audit, health-check, or review experiments or feature flags, check flag hygiene, or verify experiment setup.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1902,1905,1908,1909],{"name":1903,"slug":1904,"type":15},"Audit","audit",{"name":1906,"slug":1907,"type":15},"Feature Flags","feature-flags",{"name":9,"slug":8,"type":15},{"name":1910,"slug":1911,"type":15},"QA","qa","2026-04-06T18:44:30.657553",{"slug":4,"name":4,"fn":5,"description":6,"org":1914,"tags":1915,"stars":23,"repoUrl":24,"updatedAt":25},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1916,1917,1918,1919],{"name":21,"slug":22,"type":15},{"name":18,"slug":19,"type":15},{"name":13,"slug":14,"type":15},{"name":9,"slug":8,"type":15},{"slug":1921,"name":1921,"fn":1922,"description":1923,"org":1924,"tags":1925,"stars":23,"repoUrl":24,"updatedAt":1933},"building-a-dashboard","build and update PostHog dashboards","Build a new dashboard, or update an existing one, from a set of insights — the same job the in-app assistant does with its upsert-dashboard tool, but over MCP. Use when a user asks to create a dashboard, put several metrics\u002Fcharts together on one page, assemble a dashboard for a topic (product analytics, retention, revenue, activation, etc.), or add\u002Fremove\u002Freplace insights on a dashboard they already have. Covers deciding create vs update, reusing existing insights vs creating new ones, and using PostHog's vetted dashboard templates as reference for what a strong dashboard on a topic looks like.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1926,1927,1930],{"name":1868,"slug":1869,"type":15},{"name":1928,"slug":1929,"type":15},"Dashboards","dashboards",{"name":1931,"slug":1932,"type":15},"MCP","mcp","2026-07-21T06:07:38.060598",{"slug":1935,"name":1935,"fn":1936,"description":1937,"org":1938,"tags":1939,"stars":23,"repoUrl":24,"updatedAt":1951},"checking-deploy-timing","correlate PostHog deployments with GitHub commits","Determine when a PostHog code change reached a given environment by reading the hidden GIT deploy annotations in the project and correlating them with the merge commit on GitHub. Use when PostHog staff ask \"when was X deployed\", \"is my change live in the US\u002FEU yet\", \"has my PR shipped\", \"did the fix roll out to prod-us\", or otherwise want to know whether\u002Fwhen a commit, PR, or feature went out to a region. Do not answer deploy-timing questions from event\u002Fdata volume alone — that only shows when data changed, not when code shipped.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1940,1943,1946,1949,1950],{"name":1941,"slug":1942,"type":15},"Deployment","deployment",{"name":1944,"slug":1945,"type":15},"Git","git",{"name":1947,"slug":1948,"type":15},"GitHub","github",{"name":13,"slug":14,"type":15},{"name":9,"slug":8,"type":15},"2026-06-28T07:46:59.53536",{"slug":1953,"name":1953,"fn":1954,"description":1955,"org":1956,"tags":1957,"stars":23,"repoUrl":24,"updatedAt":1969},"choosing-trend-or-slope-view","visualize trends and growth over time","Clarify how to visualize change over a time range before building a trend. Use whenever the user asks how much something changed, grew, dropped, improved, or regressed between two points or periods — \"how much did X change from A to B\", \"before vs after\", \"start vs end\", \"week over week\", \"compare this month to last\", \"change over time\" — or mentions a \"slope chart\" \u002F \"slopegraph\". Two readings of \"change\" need different charts: the whole trend (a line, every interval) versus just the two endpoints (a slope, start vs end). Ask which they want, then render it. Not for choosing a saved insight ChartDisplayType in the insight editor.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1958,1959,1962,1965,1966],{"name":1868,"slug":1869,"type":15},{"name":1960,"slug":1961,"type":15},"Charts","charts",{"name":1963,"slug":1964,"type":15},"Data Visualization","data-visualization",{"name":9,"slug":8,"type":15},{"name":1967,"slug":1968,"type":15},"Reporting","reporting","2026-06-18T08:18:57.960157",56,{"items":1972,"total":2131},[1973,1988,1998,2011,2024,2039,2055,2068,2080,2095,2105,2121],{"slug":1974,"name":1974,"fn":1975,"description":1976,"org":1977,"tags":1978,"stars":1985,"repoUrl":1986,"updatedAt":1987},"analyzing-expensive-users","analyze expensive users in AI observability","Analyze the most expensive users in AI observability and explain why they cost so much. Use when the user asks about top spenders, expensive users, per-user LLM cost, user-level cost drivers, or patterns behind high AI observability spend.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1979,1980,1983,1984],{"name":1868,"slug":1869,"type":15},{"name":1981,"slug":1982,"type":15},"Cost Optimization","cost-optimization",{"name":13,"slug":14,"type":15},{"name":9,"slug":8,"type":15},35568,"https:\u002F\u002Fgithub.com\u002FPostHog\u002Fposthog","2026-07-28T05:34:11.117757",{"slug":1989,"name":1989,"fn":1990,"description":1991,"org":1992,"tags":1993,"stars":1985,"repoUrl":1986,"updatedAt":1997},"auditing-endpoints","audit PostHog project endpoints","Audit every endpoint in a PostHog project for staleness, failed materialisations, and unused materialised versions. Use when the user asks \"what endpoints can I clean up?\", \"are any of my endpoints broken?\", \"which materialised versions are still being called?\", or wants a one-shot cleanup pass over the Endpoints product. Produces a prioritised report grouped by issue type, with recommended actions but does not modify anything without explicit confirmation.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1994,1995,1996],{"name":1868,"slug":1869,"type":15},{"name":1903,"slug":1904,"type":15},{"name":9,"slug":8,"type":15},"2026-06-08T08:08:33.693989",{"slug":1999,"name":1999,"fn":2000,"description":2001,"org":2002,"tags":2003,"stars":1985,"repoUrl":1986,"updatedAt":2010},"auditing-warehouse-source-health","audit PostHog data warehouse source health","Audit the health of a PostHog project's data warehouse sources and syncs — find every broken or degraded source connection, sync schema, and webhook channel. Use when the user asks \"why are my imports failing?\", \"what's broken with my sources?\", \"why is my warehouse data stale?\", or wants a one-shot triage of source\u002Fsync health before deciding where to dig in. Produces a prioritized report grouped by severity, with recommended next steps. For materialized-view health use `auditing-warehouse-view-health`; for a single failing sync use `diagnosing-failed-warehouse-syncs`.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2004,2005,2008,2009],{"name":1903,"slug":1904,"type":15},{"name":2006,"slug":2007,"type":15},"Data Warehouse","data-warehouse",{"name":13,"slug":14,"type":15},{"name":9,"slug":8,"type":15},"2026-06-18T08:22:57.67984",{"slug":2012,"name":2012,"fn":2013,"description":2014,"org":2015,"tags":2016,"stars":1985,"repoUrl":1986,"updatedAt":2023},"auditing-warehouse-view-health","audit PostHog materialized view health","Audit the health of a PostHog project's materialized views (saved queries) — find every failed materialization and flag unused or stale materialized views that cost storage and compute. Use when the user asks \"which of my views are broken?\", \"why is this materialized view failing?\", \"are any of my views wasting compute?\", or wants a one-shot triage of view health. For source\u002Fsync health use `auditing-warehouse-source-health`.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2017,2018,2019,2022],{"name":1903,"slug":1904,"type":15},{"name":2006,"slug":2007,"type":15},{"name":2020,"slug":2021,"type":15},"Performance","performance",{"name":9,"slug":8,"type":15},"2026-06-18T08:25:10.936787",{"slug":2025,"name":2025,"fn":2026,"description":2027,"org":2028,"tags":2029,"stars":1985,"repoUrl":1986,"updatedAt":2038},"authoring-error-tracking-alerts","author PostHog error tracking alerts","Author error tracking alerts that fire when an issue is created, reopened, or starts spiking. Use when the user asks to set up error notifications, route exceptions to Slack\u002Fwebhook\u002FLinear, or evaluate which error events are worth alerting on. Covers trigger-event selection, integration choice, dedup against existing alerts, and shipping with the canonical message body shape.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2030,2033,2036,2037],{"name":2031,"slug":2032,"type":15},"Alerting","alerting",{"name":2034,"slug":2035,"type":15},"Debugging","debugging",{"name":13,"slug":14,"type":15},{"name":9,"slug":8,"type":15},"2026-06-18T08:24:40.318583",{"slug":2040,"name":2040,"fn":2041,"description":2042,"org":2043,"tags":2044,"stars":1985,"repoUrl":1986,"updatedAt":2054},"authoring-log-alerts","author log alerts in PostHog","Author useful, low-noise log alerts on services in a PostHog project. Use when the user asks to set up alerts for their logs, suggest alerts they should add, or evaluate whether a service is worth monitoring. Covers service triage, baseline characterisation, threshold drafting, back-testing via simulate, and shipping with a notification destination.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2045,2046,2049,2050,2053],{"name":1868,"slug":1869,"type":15},{"name":2047,"slug":2048,"type":15},"Monitoring","monitoring",{"name":13,"slug":14,"type":15},{"name":2051,"slug":2052,"type":15},"Operations","operations",{"name":9,"slug":8,"type":15},"2026-07-18T05:10:54.430898",{"slug":2056,"name":2056,"fn":2057,"description":2058,"org":2059,"tags":2060,"stars":1985,"repoUrl":1986,"updatedAt":2067},"building-workflows","build and edit PostHog workflows","Build, edit, test, enable, and monitor PostHog workflows over MCP. Author the action\u002Fedge graph so it runs and opens cleanly in the visual editor, then change drafts surgically with patch operations. Use when asked to build, set up, automate, change, fix, or debug a workflow, campaign, broadcast, drip sequence, or event-triggered automation in the workflows product.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2061,2062,2063,2064],{"name":18,"slug":19,"type":15},{"name":1931,"slug":1932,"type":15},{"name":9,"slug":8,"type":15},{"name":2065,"slug":2066,"type":15},"Workflow Automation","workflow-automation","2026-07-28T05:34:12.167015",{"slug":2069,"name":2069,"fn":2070,"description":2071,"org":2072,"tags":2073,"stars":1985,"repoUrl":1986,"updatedAt":2079},"check-posthog-loading","inspect PostHog SDK loading across URLs","Inspect how the PostHog JavaScript SDK is loaded across a list of URLs. Use to confirm consistent installation across pages, find pages missing the snippet, detect mismatched API keys or hosts between pages, and verify the load method (head snippet vs deferred vs array.js).\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2074,2075,2076,2077,2078],{"name":1868,"slug":1869,"type":15},{"name":2034,"slug":2035,"type":15},{"name":1886,"slug":1887,"type":15},{"name":13,"slug":14,"type":15},{"name":9,"slug":8,"type":15},"2026-05-07T05:56:19.828048",{"slug":2081,"name":2081,"fn":2082,"description":2083,"org":2084,"tags":2085,"stars":1985,"repoUrl":1986,"updatedAt":2094},"consuming-endpoints-from-client-code","integrate PostHog endpoints into client applications","Wire a PostHog endpoint into a client app or SDK. Covers fetching the OpenAPI spec, generating a typed client with openapi-generator or @hey-api\u002Fopenapi-ts, sending the right auth header, shaping the variables payload (HogQL code_name vs insight breakdown property), handling rate-limit and materialised-endpoint error responses. Use when the user says \"how do I call my endpoint\", \"generate a client for this\", or \"what auth header do I use\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2086,2089,2090,2091],{"name":2087,"slug":2088,"type":15},"API Development","api-development",{"name":1886,"slug":1887,"type":15},{"name":9,"slug":8,"type":15},{"name":2092,"slug":2093,"type":15},"SDK","sdk","2026-06-08T08:08:34.929454",{"slug":2096,"name":2096,"fn":2097,"description":2098,"org":2099,"tags":2100,"stars":1985,"repoUrl":1986,"updatedAt":2104},"copying-endpoints-across-projects","copy PostHog endpoints across projects","Copy a PostHog endpoint (a saved HogQL\u002Finsight query exposed as an API route) to another project in the same organization, or duplicate it under a new name in the same project. Use when the user wants to duplicate an endpoint, promote an endpoint from staging to production, replicate an endpoint's query\u002Fvariables\u002Ffreshness config in another workspace, or clone an endpoint to iterate on it. Unlike feature flags and experiments, endpoints have NO native cross-project copy tool — this skill covers the read-then-recreate flow (endpoint-get then endpoint-create), the active-project switching it requires, name-collision checks, and the safe defaults (land unmaterialised in the target, verify with endpoint-run). Does not cover editing endpoint versions (see managing-endpoint-versions) or authoring a brand-new endpoint from scratch (see creating-an-endpoint).\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2101,2102,2103],{"name":2087,"slug":2088,"type":15},{"name":2051,"slug":2052,"type":15},{"name":9,"slug":8,"type":15},"2026-07-15T05:29:58.442727",{"slug":2106,"name":2106,"fn":2107,"description":2108,"org":2109,"tags":2110,"stars":1985,"repoUrl":1986,"updatedAt":2120},"creating-ai-subscription","schedule recurring AI-generated PostHog reports","Create a recurring AI-generated PostHog report — schedule a free-text prompt to run on a cron, with the LLM-synthesized markdown delivered to email or Slack on each tick. Use when the user wants a recurring AI summary of X on any cadence (daily, weekly, monthly, yearly) rather than a one-off report. (To attach an AI summary to an existing insight\u002Fdashboard subscription instead of a free-text prompt, see `managing-subscriptions` and its `summary_enabled` option.)\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2111,2112,2115,2116,2117],{"name":18,"slug":19,"type":15},{"name":2113,"slug":2114,"type":15},"Email","email",{"name":9,"slug":8,"type":15},{"name":1967,"slug":1968,"type":15},{"name":2118,"slug":2119,"type":15},"Slack","slack","2026-06-09T07:32:27.935712",{"slug":2122,"name":2122,"fn":2123,"description":2124,"org":2125,"tags":2126,"stars":1985,"repoUrl":1986,"updatedAt":2130},"creating-an-endpoint","create PostHog API endpoints","Create a PostHog endpoint with the right shape on the first try — covers query kind choice, name conventions, what to expose as variables (HogQL code_name vs insight breakdown), data_freshness_seconds, and whether to materialise on day one. Use when the user says \"create an endpoint\", \"expose this query as an API\", \"turn this insight into an endpoint\", or asks for help structuring a new endpoint. Steers away from common mistakes: materialising a query with cohort breakdowns or compare mode, inline-only variables on a materialised endpoint, unbounded date ranges, ambiguous names.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2127,2128,2129],{"name":1868,"slug":1869,"type":15},{"name":2087,"slug":2088,"type":15},{"name":9,"slug":8,"type":15},"2026-06-08T08:08:29.624498",231]