authoring-scouts
Authoring Signals 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.
Where that output lands is a separate, per-scout config decision: the report goes to the Signals inbox, and the same report can be delivered to a Slack channel or DM at the same time (output_destinations under Run posture) — so don't rule a scout out of a job because the user wants the result in Slack.
(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 an LLMSkill that holds a SignalScoutConfig.
The harness loads the body verbatim as the agent's system prompt, and progressively reads any bundled reference files on demand.
The config row is what makes a skill a scout. Any valid skill name works, so the signals-scout- prefix is optional.
The prefix controls one thing: the coordinator globs signals-scout-* to auto-register a config for a skill that has none.
A skill with any other name needs its config created alongside it, which is what scout-create does.