Explorer la Boîte de réception

La Boîte de réception est l'endroit où PostHog surface les rapports de signaux — des clusters d'observations connexes (signaux) agrégés en un seul problème ou tendance (par ex. « Le taux d'erreur a augmenté de 3× sur /checkout »). Les rapports proviennent de plusieurs produits sources : suivi des erreurs, session replay, web analytics, expériences, et intégrations comme Linear, GitHub et Zendesk.

La Boîte de réception fait partie de PostHog Code, la surface agentic de PostHog pour les équipes d'ingénierie.

Ne présumez pas que le projet de l'utilisateur a des rapports, ou que des sources de signaux sont configurées — de nombreux projets n'ont pas la Boîte de réception configurée. Exécutez toujours le workflow de vérification de configuration ci-dessous avant de répondre à la question réelle de l'utilisateur.

Quand utiliser ce skill

« Qu'y a-t-il dans ma boîte de réception ? » / « Par quoi devrais-je commencer ? »
« Affiche-moi les rapports actionnables » / « Qu'a PostHog signalé récemment ? »
« Y a-t-il des rapports sur <sujet / domaine produit> ? »
« Quelles sources de signaux sont configurées pour ce projet ? »
L'utilisateur colle un ID ou une URL de rapport et veut du contexte

Pour une investigation plus approfondie, déléguez à d'autres skills et outils :

Skill signals — requête document_embeddings via HogQL pour le texte de signal brut, recherche sémantique sur les signaux, ou pour inspecter tous les signaux qui ont contribué à un rapport.
Outils MCP spécifiques au produit PostHog — quand un rapport pointe vers une erreur spécifique, une ligne de log, une session, une personne, ou une plage horaire, utilisez l'outil domaine correspondant pour extraire du contexte enrichi :
- Suivi des erreurs : query-error-tracking-issues, error-tracking-issues-retrieve pour les rapports issus du suivi des erreurs
- Logs : query-logs, logs-count-ranges pour trouver l'activité log autour du problème
- Session replays : query-session-recordings-list, session-recording-get pour trouver les enregistrements des utilisateurs affectés
- Personnes / activité : persons-retrieve, activity-log-list pour inspecter le comportement d'un utilisateur spécifique
- Tendances / SQL : query-trends, execute-sql pour des requêtes de vérification ad-hoc

Un rapport de signal vous dit ce que PostHog a clusterisé. Les outils spécifiques au produit vous disent le détail sous-jacent — associez-les quand l'utilisateur veut approfondir.

Outils disponibles

Outil	Objectif
`inbox-reports-list`	Liste paginée des rapports avec filtres (statut, recherche, etc.)
`inbox-reports-retrieve`	Détail complet pour un rapport unique
`inbox-source-configs-list`	Sources de signaux configurées (quels produits alimentent la boîte)
`inbox-source-configs-retrieve`	Enregistrement complet pour une config source unique
`posthog:execute-sql` (signals skill)	Accès HogQL aux signaux sous-jacents (lisez d'abord le skill `signals`)

Les quatre outils inbox-* sont en lecture seule. Les écritures (pause du traitement, modification des configs sources, gestion de l'autonomie par utilisateur) ne sont intentionnellement pas exposées via MCP aujourd'hui.

Terminologie

Ce que signifie chaque statut de rapport (à peu près dans l'ordre d'importance pour un agent de triage) :

ready — jugement terminé, évaluation actionnable disponible
pending_input — en attente d'input utilisateur pour continuer
in_progress — actuellement en cours de synthèse / jugement
candidate / potential — signaux accumulés mais pas encore promus à un vrai rapport
failed — traitement en erreur
suppressed — masqué manuellement ; non surfacé par défaut

Par défaut, inbox-reports-list exclut les rapports suppressed et ordonne les résultats par -is_suggested_reviewer,status,-updated_at — d'abord les rapports suggérés de l'utilisateur, puis par statut, puis les plus récemment mis à jour. Consultez le schéma d'input de l'outil pour les mécaniques de filtre.

Workflow : gérer une boîte de réception vide ou non configurée (lisez d'abord)

Exécutez cette vérification chaque fois qu'un utilisateur demande quelque chose sur la boîte de réception pour la première fois dans une session, ou chaque fois que inbox-reports-list retourne count: 0. Le diagnostic décide quoi dire ensuite.

Étape 1 — Regarder les configs sources

inbox-source-configs-list
{ "limit": 50 }

Trois cas significatifs :

Cas A — aucune config source du tout (count: 0)

L'utilisateur n'a pas intégré Inbox / signaux. Ne prétendez pas que la boîte a des données. Dites à l'utilisateur clairement que Inbox a besoin que les sources de signaux soient d'abord configurées, et que la façon recommandée de le faire est d'installer PostHog Code sur https://posthog.com/code. Exemple de réponse :

Votre projet n'a aucune source de signaux configurée pour l'instant, donc la Boîte de réception est vide. La Boîte de réception surface les problèmes et tendances que PostHog clusterise automatiquement depuis des sources comme le suivi des erreurs, le session replay, GitHub, Linear et Zendesk. Le moyen le plus rapide de configurer cela est d'installer PostHog Code — une fois connecté, les signaux commenceront à arriver et les rapports apparaîtront dans votre boîte de réception au cours du prochain jour environ.

Arrêtez-vous là sauf si l'utilisateur veut discuter de la configuration. N'exécutez pas d'autres outils de boîte de réception — ils seront tous vides.

Cas B — des configs sources existent mais toutes sont enabled: false

Les sources ont été configurées à un moment donné mais sont actuellement désactivées. Dites à l'utilisateur qu'aucun signal ne circule actuellement et pointez-les vers les paramètres de signaux du projet pour réactiver. Ne cherchez pas à trouver des rapports — tout ce qui reste est obsolète.

Cas C — au moins une config source est enabled: true

La configuration semble saine. Si inbox-reports-list retourne toujours rien, c'est probablement « il faut attendre » — les signaux circulent mais rien ne s'est encore clusterisé en rapport. Dites à l'utilisateur cela brièvement, listez quelles sources sont actives (par ex. « vous avez GitHub et le suivi des erreurs activés »), et proposez de vérifier plus tard ou de passer au skill signals pour regarder le volume de signaux bruts.

Si une config source a status: "failed", surfacez cela dans votre réponse — cette source ne produit pas de signaux en ce moment, ce qui peut expliquer une boîte de réception peu remplie.

Étape 2 — Seulement ensuite continuer avec la question réelle de l'utilisateur

Si l'Étape 1 a trouvé une configuration saine et au moins un rapport existe, continuez avec les workflows de triage / drill / filtre ci-dessous.

Workflow : trier ce qui est actionnable

Quand l'utilisateur demande « sur quoi devrais-je travailler ? » ou « qu'est-ce qui est actionnable ? » :

Étape 1 — Extraire la queue ready/in-progress

inbox-reports-list
{
  "status": "ready,in_progress,pending_input",
  "limit": 20
}

Si count: 0 revient, passez au workflow vide/non configuré ci-dessus avant de dire « votre boîte de réception est vide » — la bonne réponse dépend de si les sources sont configurées.

Étape 2 — Synthétiser par source et actionnabilité

Pour chaque rapport, la réponse inclut :

id, title, summary
status, priority, actionability (note : null pour les rapports toujours en pending_input / candidate — le jugement n'a pas encore été exécuté)
signal_count, total_weight — la quantité de preuve sous-jacente qui a entraîné le rapport
source_products — quel(s) produit(s) les signaux sous-jacents provenaient
is_suggested_reviewer — si l'utilisateur actuel est un reviewer suggéré
implementation_pr_url — si une PR a été ouverte contre ce rapport
_posthogUrl — lien profond cliquable vers le rapport ; incluez toujours ceci dans votre réponse

Groupez les résultats pour que l'utilisateur puisse scanner rapidement :

## Boîte de réception — 8 rapports actionnables

🔴 Priorité haute (3)
- Le taux d'erreur de checkout a augmenté de 3× — error_tracking, 47 signaux
  <_posthogUrl>
- Session replays sur /pricing montrent des rage clicks répétés — session_replay, 12 signaux
  <_posthogUrl>
…

🟠 Priorité moyenne (4)
…

🟡 Suggéré pour vous (1)
…

Étape 3 — Offrir le drill-down

Terminez par un hand-off clair : « Veux-tu que je creuse les erreurs de checkout ? » → appelez inbox-reports-retrieve pour le rapport complet, puis optionnellement passez au skill signals pour regarder le texte de signal sous-jacent.

Workflow : creuser un rapport spécifique

Quand l'utilisateur colle une URL de Boîte de réception ou un ID de rapport :

inbox-reports-retrieve
{ "id": "<report_uuid>" }

Retourne l'enregistrement complet incluant signals_at_run et artefact_count. Combinez ceci avec le skill signals si l'utilisateur veut voir le contenu de signal réel :

Utilisez inbox-reports-retrieve pour obtenir les métadonnées du rapport + id
Utilisez l'Exemple 2 du skill signals (récupérer tous les signaux pour un rapport spécifique) — passez l'ID de rapport comme metadata.report_id dans la requête HogQL

Les deux couches se complètent : les outils inbox-* vous donnent la vue curée/jugée, et le skill signals vous laisse inspecter les observations brutes qui l'ont produite.

Workflow : filtrer par sujet ou source

« Y a-t-il des rapports sur <sujet> ? » — commencez par search :

inbox-reports-list
{
  "search": "checkout",
  "status": "ready,in_progress,pending_input",
  "limit": 20
}

search fait correspondre le titre et le résumé. Si l'utilisateur pose une question sur un domaine produit plutôt qu'un mot-clé, utilisez source_product :

inbox-reports-list
{
  "source_product": "session_replay,error_tracking",
  "limit": 20
}

Si la recherche par mot-clé ne retourne rien de significatif, passez au skill signals — la recherche sémantique sur le texte de signal via embedText() attrapera les rapports que le filtre de mot-clé a manqués.

Workflow : passer en revue les sources configurées

Quand l'utilisateur demande « quelles sources de signaux sont configurées ? » ou « est-ce que <produit> est connecté ? » :

inbox-source-configs-list
{ "limit": 50 }

Chaque entrée retourne id, source_product, source_type, enabled, status, plus timestamps. Pour les détails complets (incluant le JSON config par source — filtres d'enregistrement, IDs d'évaluation, etc.) :

inbox-source-configs-retrieve
{ "id": "<source_config_uuid>" }

Les credentials d'intégration vivent dans un modèle Integration séparé — ils ne sont pas dans le blob config, donc c'est safe de résumer le contenu à l'utilisateur.

Le champ status reflète l'import de données ou le workflow sous-jacent :

running / completed — alimentant les signaux normalement
failed — la source ne produit pas actuellement de signaux ; signalez ceci à l'utilisateur

Conseils

Vérifiez la configuration avant d'assumer que la boîte de réception est vide. Si inbox-reports-list retourne count: 0, appelez d'abord inbox-source-configs-list — aucune source signifie que l'utilisateur doit installer PostHog Code pour commencer à recevoir des signaux ; des sources mais pas de rapports signifie que les signaux circulent mais rien ne s'est encore clusterisé
Surfacez toujours _posthogUrl pour que l'utilisateur puisse cliquer dans le rapport
L'ordre par défaut priorise déjà les rapports suggérés de l'utilisateur — ne réordonnez que si demandé
priority et actionability sont null pour les rapports toujours en statut pending_input ou candidate ; c'est attendu, pas un bug — le jugement n'a pas encore été exécuté
Les rapports suppressed sont exclus par défaut ; passez status: "suppressed" explicitement si l'utilisateur veut voir les éléments masqués
N'essayez pas d'écrire dans la boîte de réception via MCP — les endpoints destroy / state changes / reingest ne sont intentionnellement pas exposés. Si l'utilisateur veut agir sur un rapport, pointez-le vers le lien profond _posthogUrl
Pour « quels types de signaux existent ? » ou « qu'est-ce qui s'est passé récemment sur toutes les sources ? », plongez dans le skill signals — la couche rapport cache les observations individuelles ; vous avez besoin de HogQL sur document_embeddings pour les voir
Les configs source n'ont pas de liens profonds par enregistrement — ils se trouvent derrière les paramètres du projet, donc inbox-source-configs-retrieve ne retourne pas _posthogUrl. Ne les confondez pas avec les rapports

inbox-exploration