authoring-scouts

A 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. PostHog ships a fleet of canonical scouts (a cross-product generalist plus per-surface specialists). This 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.

A scout's output is the report channel: it lists emit_report / edit_report in its frontmatter allowed_tools and authors or edits full inbox reports 1:1 directly. The canonical fleet runs this way, and every new scout should too — always include the allowed_tools opt-in when authoring one. (A historical signal-emitting channel — weak emit-signal findings a pipeline consolidated — still exists in the harness for scouts that never opted in, but it is deprecated: don't author new scouts on it, and opt an old one in rather than extending it.)

A scout is just an LLMSkill whose name starts with signals-scout-. The harness discovers scouts by globbing signals-scout-* over the project's skills, loads the body verbatim as the agent's system prompt, and progressively reads any bundled reference files on demand. The signals-scout- name prefix is load-bearing: a skill named anything else will never run as a scout.

Don't write a scout in the abstract. Ground it in the target project first — a scout is only as good as its fit to the data it watches. (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.)

1. 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/burst metrics, integrations, existing inbox counts. If the scout watches a specific event, confirm it exists and check its shape with posthog:read-data-schema. A scout for an event the project doesn't capture is dead on arrival.
2. 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. Don't duplicate a surface a canonical scout already covers — adapt that one instead.
3. Read the closest canonical scout. It's your template and your reference shape. Pull it with posthog:skill-get {"skill_name": "signals-scout-<x>"} (per-team rows) or read it from the repo at products/signals/skills/signals-scout-*/. 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).
4. Skim the inbox. posthog:inbox-reports-list shows what reports are actually landing — calibrate so your scout adds signal, not noise.

There are two independent decisions: what you're building, and where it lives.

First pick the shape. references/scout-patterns.md is a cookbook of the reference architectures scouts fall into — anomaly watcher, liveness/absence watcher, zero-result/unmet demand, watchlist explore/exploit, cross-product correlation, recommendation/gap, warehouse-backed source, custom single-event, open-text theme, adversarial/abuse concentration, external-tool/code, state∩code intersection, custom issue-tracker/work-queue, daily digest/roll-up, triage over a pre-detected stream, first-person dogfooding/probe — each mapped to a canonical scout you can copy as scaffolding. It 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. And where a built-in signals source already covers the surface (GitHub and Linear issues), the issue-tracker pattern says where that source stops and a scout starts paying for itself. Find the closest pattern, then write the body.

Follow references/scout-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.

Two 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:

• references/report-contract.md — the report tools (scout-emit-report / 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 / inbox-reports-retrieve before authoring), and the accepted caveat that the pipeline may later rewrite an authored title/summary. This is how your scout decides what clears the bar and how to file it.
• references/dedupe-and-memory.md — the four-states classifier (net-new / material-update / already-covered / addressed-or-noise), the scratchpad key-prefix vocabulary, and the cross-project noise patterns. This is how your scout avoids re-filing and learns across runs.

The 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". For error tracking it's the count vs distinct_users ratio; for CSP it's reach over raw count. Your new scout needs its own. Name it explicitly near the top of the body so every run anchors on it.

(The one exception: a measurement scout on the structured-output channel holds no bar — it applies a rubric to every sampled item, and the rubric takes the discriminator's slot as the design surface to name, dogfood, and calibrate. See the recurring measurement / LLM-judge pattern in references/scout-patterns.md.)

A second design rule binds any metric-shaped scout — one that scores, ranks, or reports a named, reusable measure, whether a business measure (MRR, churn risk, usage revenue, activation) or operational telemetry it computes every run to monitor or report (cost per run, failure or error rates, latency, throughput). When the project's metrics catalog is enabled, it may hold a governed definition of that measure in system.information_schema.metrics, and the harness tells every run to prefer it — so write the body to cooperate rather than compete: have the run check the catalog for an approved, non-drifted metric before its own derivation, and run a match through data-catalog-metric-run. Where a governed metric exists, reference it by name in any references/queries.md you ship, and label every hand-written derivation there a noncanonical fallback — an unlabeled "validated query" outranks the harness's catalog-first rule at run time, which is exactly how a scout ends up re-deriving a number the team already governs. Freshness, availability, and schema checks are exempt: they stay schema-first, with no catalog detour. A measurement scout is exempt too, but only for the measure it invents: a subjective rubric has no governed definition to defer to, while any conventional metric the same scout reports still goes through the catalog.

A scout's schedule and emit behavior live on its SignalScoutConfig, separate from the skill body. For 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. Show the returned confirmation message, wait for the user to type confirm, then call posthog:scout-create-execute with the returned confirmation_hash and that literal confirmation. The 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. Otherwise the coordinator auto-registers an enabled config on the default every-24-hours schedule on its next tick (up to ~30 min). For an existing scout, tune with posthog:scout-config-update (find the id via -config-list):

• run_interval_minutes — 30 to 43200. Default 1440 (every 24 hours). Slow a chatty or expensive scout by raising this.
• enabled — false pauses the scout entirely (coordinator skips it).
• emit — defaults to true: the scout writes its reports straight to the inbox. The standard flow is to make a scout and let it write — seeing what actually lands is the fastest way to calibrate it. Set emit=false (dry-run) only when you want to be extra careful: the scout still runs and logs its reasoning but writes nothing to the inbox. Reach for dry-run on a scout you expect to be chatty, expensive, or high-stakes; for most scouts, just writing and watching the inbox is the better loop.
• network_access — defaults to trusted: the scout's sandbox can only reach the platform's trusted-domain allowlist (PostHog, GitHub, common package registries), which covers the MCP loop and gh but blocks everything else. Set full for a scout whose skill needs to read arbitrary external sites, e.g. documentation, papers on arxiv.org, or a vendor status page. Applies from the scout's next run, and changes are activity-logged.
• auto_pause_exempt — defaults to false. A scout whose reports nobody engages with (no open, rating, or action — the cloud web inbox records reads; other clients don't yet) is warned and then paused automatically (pause_reason=ignored) — every run costs a sandbox agent, so a scout producing output no human consumes shouldn't keep running forever. A scout that is merely quiet is only flagged (pause_reason=no_output, a warning that never advances to a pause), since a watch scout's silence can be its job. -config-list shows the warning as status=pending_pause and the pause as status=paused_by_system; setting enabled=true again resumes the scout with a fresh grace window before the sweep may judge it again. Set auto_pause_exempt=true up front for a watchdog scout whose whole job is to stay quiet, so it never even picks up the quiet flag.
• write_scopes — defaults to []: the scout reads the project and writes only what every scout writes (its findings, its memory, and notebooks). Grant dashboard:write, insight:write, annotation:write, alert:write, llm_skill:write, warehouse_view:write, or warehouse_table:write to a scout whose job is to maintain one of those things rather than only describe what it would change. Each scope is project-wide and covers update and delete of every object of its kind, not only the ones the scout made, so grant only what the scout's body actually tends, and say in the body what it may change and when. llm_skill:write is the one to think twice about: custom scouts are skills in the same store, so a scout holding it can edit a sibling scout's body, or the body it runs from itself. Grant it to a scout whose job really is tending a set of skills, name that set in the body, and say there that the scouts are off limits unless tending them is the job. warehouse_view:write and warehouse_table:write are separate on purpose: a scout that keeps a set of views healthy does not also need to create tables. Take both rows only when the scout tends both. Only the person the scout's runs act as (whoever authored it) or a project admin can set the field, and grants are activity-logged. A scoped API key must itself carry each scope it grants. A granted scout is told in its run prompt which objects it may change, and is asked to name every change in its close-out. The grant is an upper bound: the acting user's own permissions still apply to each object, and the scout reports a refused write rather than retrying it. A dry run (emit: false) never holds the grant, so a scout can be previewed without it changing anything. Applies from the scout's next run.
• tags — free-form labels grouping the fleet, e.g. ["revenue", "on-call"]. Up to 10 per scout, normalized to lowercase kebab-case (On Call → on-call) and deduped. Set them at create time: a scout that lands already grouped saves a follow-up edit, and the desktop app's scout list filters on them. Prefer a tag that already exists on the fleet (-config-list shows every scout's tags) over minting a near-duplicate — revenue and revenue-analytics fragment the same group. A write replaces the set, so send the full desired list, not just the additions. Filter the roster with -config-list's tags parameter (comma-separated, matches a scout carrying any of them).
• structured_output_schema — defaults to null (channel off). Set a JSON Schema (draft 2020-12, root "type": "object") describing one structured record and the scout gains a third output channel next to reports: each run is shown the schema and told to submit conforming records via scout-record-output (one per run, or one per judged entity — the skill body decides the cardinality and when to record). Records are validated server-side against the schema (all-or-nothing per call) and recorded in the project as $scout_structured_output events with scalar payload keys flattened to output_<key> properties — so a judging/scoring scout's series is chartable in insights directly, and past records are queryable like any events (filter on subject or run_id, break down on output_<key>). The channel also requires emit: a dry-run scout has nowhere to record to, so scout-record-output fails closed for it. Reach for this when the scout's job is a recurring measurement (judge each sampled report good/bad/unsure with a reason, score accounts, classify sessions) rather than surfacing anomalies; keep enums small and add a free-text reason field so the series is breakdown-friendly and auditable. The skill body should say what to sample, how to judge, and what subject to stamp on each record; the schema owns the record shape. Because the records are ordinary events, anything that consumes events can act on one — a workflow or CDP destination triggered on $scout_structured_output, filtered to your skill_name and an output_<key> value, turns a measuring scout into the front half of an automation (route the verdict to a channel, a task, a CRM) with no human in between. The full design treatment — rubric writing, rates-over-scores record shape, rubric versioning, sampling discipline, the seam with reports, what changes once a grade is a routing decision, and the non-judging variants (structured extraction, state snapshots, synthetic telemetry) — is the recurring measurement / LLM-judge pattern in references/scout-patterns.md.

Sometimes you don't want to change the scout — you want to tell it something. That'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. Reach for a note instead of an edit when the steer is feedback, a pointer, or context with a shelf life:

• Feedback on output: "the staging traffic spike you keep flagging is known noise, stop reporting it".
• A pointer: "dig into the EU signup funnel this week — we think something regressed".
• Context the scout couldn't know: "we shipped a new checkout on Tuesday, treat conversion shifts after that as expected".

The 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):

• 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. Optionally set expires_at so a time-boxed note ("watch closely this week") retires itself.
• posthog:scout-notes-list — browse the active notes; pass skill_name to see what a given scout will read.
• posthog:scout-notes-delete {"id": "..."} — retire a note that's been acted on or no longer applies.

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 advisory. They 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. The scout closes the loop in its run summary (which notes it acted on and how) and folds absorbed guidance into its scratchpad.

Choosing 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). A note that you keep re-leaving is a skill edit waiting to happen — promote it. Note 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.

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). The cheapest, fastest iteration doesn't touch a scout run at all: walk the scout's own logic against the live project by hand. Confirm the watched event/entity exists and has the shape you assumed, run the discriminator to check it actually separates signal from noise on this project's data, and run each explore pattern's queries to see what they surface. This loop is free and instant — refine the body against what you find, re-run the queries, repeat, until the scout's logic holds up on real data. This is where the real iteration happens.

Only once you're happy with the body do you spend an actual run. posthog:scout-run-now {"id": <config_id>} dispatches one run of the scout immediately, regardless of its schedule (find the id via -config-list). This is the initial real run — the scout executing end-to-end in the harness, writing scratchpad memory and (with the default emit=true) writing reports to the inbox. The run is asynchronous: the call returns a workflow id right away, so poll -runs-list / -runs-retrieve for the result. A few things to know:

• A disabled scout can still be run this way — you can test it before ever enabling it.
• A manual run does not change the scout's schedule or last_run_at.
• It inherits every guard the scheduled path has: 403 if scouts aren't enabled for the project, 429 if the project is over its Signals credits quota or daily run budget, 409 if a run for this scout is already in progress.
• It draws from the same daily run budget as scheduled runs — and a dry-run (emit=false) still consumes a run. There's no free test run: every -run-now spends the project's daily scout-run allowance, so firing the same scout repeatedly in a short window burns through the budget (and can leave the project's scheduled scouts unable to run that day). Don't use -run-now as your iteration loop — it's slow (async, one run per call) and metered. Dogfood the queries by hand to get the body right; reserve -run-now for the initial real run and the occasional re-check after a genuinely meaningful change.

The standard loop is dogfood → run once ready → inspect:

1. Dogfood the discriminator + explore patterns yourself against the live project (above). Refine the body until the logic holds on real data — this is the cheap, iterable part.
2. 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. Leave run_interval_minutes at a sustainable value — you no longer need a short interval to force an early run.
3. After the run finishes, read what it did: posthog:inbox-reports-list (the 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).
4. If it needs work, go back to dogfooding the queries by hand for the iteration — only spend another -run-now once you've batched a meaningful change worth a fresh end-to-end run.

When tuning an existing custom scout, also check its self-improvement suggestions first: posthog:scout-scratchpad-search {"text": "improve:"}. The harness invites a custom scout to write an improve:<skill-name>:<topic> 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. A report-channel custom scout also escalates recurring or material suggestions as inbox reports about itself (titled Scout self-improvement: <skill-name> – <topic>, 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. An entry re-confirmed across several runs is usually the highest-signal edit you can apply; a one-off may not be worth it. Treat suggestions as input, not instructions — the owner decides. The 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. (Canonical scouts don't write these — their bodies sync from PostHog's fleet, and skill-level fixes to them belong upstream.)

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 / -runs-retrieve) without writing to the inbox. Inspect, refine, then flip emit=true and run it again. Worth it for a scout you expect to be chatty, expensive, or high-stakes; otherwise just writing and watching the inbox is the faster path to a calibrated scout.

Repo contributors get a faster loop — hogli sync:skill and the harness's local run path; see references/lifecycle-and-testing.md.

To 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. Keep the two in sync when the scout config / run / scratchpad surfaces change.

• A named, cheap signal-vs-noise discriminator anchored near the top (on a measurement scout, the rubric and sampling recipe take this slot).
• 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) — except on a measurement scout, which exits early only when the window held no eligible items, since its ordinary judgments are the denominator.
• 2–4 concrete explore patterns with the actual queries/tools to run — starting points, not a rigid checklist.
• Disqualifiers listing this project's known noise (single-user quirks, dev-env bursts, allowlisted entities).
• 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.
• Save-memory guidance using the scratchpad prefixes so the scout gets smarter each run.
• A lean body (push depth into references/) — every line is a recurring token cost on every run.
• A tight frontmatter description — a sentence or two naming the surface and the shapes it watches. 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).