signals-scout-tasks

Detects failing task runs and recurring user demand in PostHog Tasks via SQL analysis.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill signals-scout-tasks
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: signals-scout-tasks
Source: https://github.com/PostHog/posthog-foss/tree/main/products/signals/skills/signals-scout-tasks
Command: npx skills add https://github.com/PostHog/posthog-foss --skill signals-scout-tasks

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Teams running agent-driven tasks in PostHog lack visibility into whether that work actually lands: failure clusters hide in raw run counts, retry storms masquerade as systemic defects, and recurring user requests go unnoticed. This Skill continuously scouts the tasks system tables to surface delivery-health problems and demand patterns as actionable reports.

Core Features & Use Cases

  • Delivery health monitoring (Lens A): Clusters failed task runs by repository and error-message class, then applies a failed-runs-per-distinct-task ratio to distinguish systemic defects from retry storms, total repository breakage, and silent non-completion (aging backlogs, cancellation spikes).
  • Demand analysis (Lens B, gated weekly): Samples human-origin task titles through visibility-enforcing MCP tools to find recurring requests across distinct creators, writing findings to scratchpad memory rather than reports to protect private task content.
  • SQL cookbook: Ships a references/queries.md cookbook of ten parameterized ClickHouse-style queries using cityHash64 fingerprints so attacker-controlled strings never reach SQL predicates.
  • Use Case: A repository's agent runs fail at 100% across three distinct tasks with clone-authentication errors; the scout files one report naming the error class, rate, volume, and a cited run id, routed to the reviewer who owned prior reports on that repo.

Quick Start

Ask the Signals agent to run the tasks scout against this project and report any failure clusters or recurring demand themes it finds.

Frequently Asked Questions about signals-scout-tasks

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect failing agent task runs in PostHog?

Query system.task_runs joined to system.tasks, filtering status = 'failed' and grouping by repository or error-message prefix. The skill's cookbook queries compute failure rates over run volume and a failed-runs-per-task ratio to separate systemic defects from retry storms.

How to tell a systemic task failure from a retry storm?

Divide failed runs by distinct failed tasks within a cluster. A ratio near 1 across many tasks indicates a systemic defect in a shared code path, while a high ratio over one or two tasks indicates a single stuck task retrying, which should not be filed as a fleet problem.

Can I read PostHog task titles and descriptions with SQL?

No. The system.tasks table enforces only team scoping, not task_visibility_q, so personal-channel tasks would leak into team-visible output. Task text must be read through the tasks-list and tasks-retrieve MCP tools, which enforce visibility server-side.

Why must the signals_scout origin be excluded from task queries?

Rows with origin_product signals_scout or scout_suggestions are the scout fleet's own run containers, not project work, and the internal flag does not filter them. On active projects they can outnumber all real origins, skewing every failure and demand measurement.

What are the limitations of task failure monitoring via system tables?

The system.tasks table hard-filters internal tasks, so Loop firings and parts of the signals pipeline never appear, meaning findings cover only the non-internal slice. The stage column is also unpopulated and must never be used for detection.