inbox-exploration

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Exploring the Inbox

探索Inbox

The Inbox is where PostHog surfaces signal reports — clusters of related observations (signals) that have been aggregated into a single issue or trend (e.g. "Error rate spiked 3× on /checkout"). Reports come from multiple source products: error tracking, session replay, web analytics, experiments, and integrations like Linear, GitHub, and Zendesk.

Inbox is part of PostHog Code, PostHog's agentic surface for engineering teams.

Don't assume the user's project has reports, or that any signal sources are configured — plenty of projects don't have Inbox set up. Always run the setup-check workflow below before answering the user's actual question.

Inbox是PostHog展示信号报告的地方——信号报告是将相关观测结果（信号）聚合而成的单个问题或趋势（例如“/checkout页面错误率飙升3倍”）。报告来自多个源产品：错误追踪、session replay、网站分析、实验，以及Linear、GitHub、Zendesk等集成工具。

Inbox是PostHog Code的一部分，PostHog Code是面向工程团队的智能交互界面。

不要假设用户的项目已有报告或已配置任何信号源——很多项目尚未设置Inbox。在回答用户实际问题之前，务必先运行下方的设置检查流程。

When to use this skill

何时使用本技能

"What's in my inbox?" / "What should I look at first?"
"Show me actionable reports" / "What's PostHog flagged recently?"
"Are there any reports about <topic / product area>?"
"What signal sources are configured for this project?"
The user pastes a report ID or URL and wants context

For deeper investigation, hand off to other skills and tools:

signals
skill — query
```
document_embeddings
```
via HogQL for raw signal text, semantic search across signals, or to inspect every signal that contributed to a report.
PostHog's product-specific MCP tools — when a report points at a specific error, log line, session, person, or time range, reach for the matching domain tool to pull richer context:
- Error tracking:
```
query-error-tracking-issues
```
  ,
```
error-tracking-issues-retrieve
```
  for error-tracking-sourced reports
- Logs:
```
query-logs
```
  ,
```
logs-count-ranges
```
  to find log activity around the issue
- Session replays:
```
query-session-recordings-list
```
  ,
```
session-recording-get
```
  to find recordings of affected users
- Persons / activity:
```
persons-retrieve
```
  ,
```
activity-log-list
```
  to inspect a specific user's behavior
- Trends / SQL:
```
query-trends
```
  ,
```
execute-sql
```
  for ad-hoc verification queries

A signal report tells you what PostHog clustered. The product-specific tools tell you the underlying detail — pair them when the user wants to dig in.

“我的收件箱里有什么？” / “我应该先关注什么？”
“给我展示可执行的报告” / “PostHog最近标记了什么？”
“有没有关于<主题/产品领域>的报告？”
“此项目配置了哪些信号源？”
用户粘贴报告ID或URL并想要了解相关上下文

如需深入调查，请切换至其他技能和工具：

signals
技能——通过HogQL查询
```
document_embeddings
```
以获取原始信号文本、对信号进行语义搜索，或查看构成某份报告的所有信号。
PostHog的产品专属MCP工具——当报告指向特定错误、日志行、会话、用户或时间范围时，使用对应领域的工具获取更丰富的上下文：
- 错误追踪：针对来自错误追踪源的报告，使用
```
query-error-tracking-issues
```
  、
```
error-tracking-issues-retrieve
```
- 日志：使用
```
query-logs
```
  、
```
logs-count-ranges
```
  查找问题相关的日志活动
- 会话重放：使用
```
query-session-recordings-list
```
  、
```
session-recording-get
```
  查找受影响用户的会话记录
- 用户/活动：使用
```
persons-retrieve
```
  、
```
activity-log-list
```
  查看特定用户的行为
- 趋势/SQL：使用
```
query-trends
```
  、
```
execute-sql
```
  进行临时验证查询

信号报告会告诉你PostHog聚合了什么内容。产品专属工具则会提供底层细节——当用户想要深入挖掘时，需将两者结合使用。

Available tools

可用工具

Tool	Purpose
`inbox-reports-list`	Paginated list of reports with filters (status, search, etc.)
`inbox-reports-retrieve`	Full detail for a single report
`inbox-source-configs-list`	Configured signal sources (which products feed the inbox)
`inbox-source-configs-retrieve`	Full record for a single source config
`posthog:execute-sql` (signals skill)	HogQL access to underlying signals (read the `signals` skill first)

All four

inbox-*

tools are read-only. Writes (pause processing, change source configs, manage per-user autonomy) are intentionally not exposed via MCP today.

工具	用途
`inbox-reports-list`	带筛选条件（状态、搜索等）的分页报告列表
`inbox-reports-retrieve`	单份报告的完整详情
`inbox-source-configs-list`	已配置的信号源（哪些产品向收件箱提供数据）
`inbox-source-configs-retrieve`	单个源配置的完整记录
`posthog:execute-sql` （signals技能）	通过HogQL访问底层信号（请先阅读 `signals` 技能文档）

所有四个

inbox-*

工具均为只读模式。目前MCP未开放写入操作（暂停处理、修改源配置、管理用户自主权限）。

Terminology

术语说明

What each report status means (in roughly the order a triage agent should care about):

```
ready
```
— judgment finished, actionable assessment available
```
pending_input
```
— waiting on user input to proceed
```
in_progress
```
— actively being summarized / judged
```
candidate
```
/
```
potential
```
— accumulated signals but not yet promoted to a real report
```
failed
```
— processing errored
```
suppressed
```
— manually hidden; not surfaced by default

By default

inbox-reports-list

excludes

suppressed

reports and orders results by

-is_suggested_reviewer,status,-updated_at

— the user's own suggested reports first, then by status, then most recently updated. Refer to the tool's input schema for filter mechanics.

各报告状态的含义（按分类代理应关注的大致顺序排列）：

```
ready
```
——判断完成，可获取可执行评估结果
```
pending_input
```
——等待用户输入以继续处理
```
in_progress
```
——正在进行总结/判断
```
candidate
```
/
```
potential
```
——已积累信号但尚未升级为正式报告
```
failed
```
——处理过程出错
```
suppressed
```
——手动隐藏；默认不会展示

默认情况下，

inbox-reports-list

会排除

suppressed

报告，并按

-is_suggested_reviewer,status,-updated_at

排序——先显示用户自己的推荐报告，再按状态排序，最后按最近更新时间排序。请参考工具的输入模式了解筛选机制。

Workflow: handling an empty or unconfigured inbox (read first)

流程：处理空收件箱或未配置收件箱（请先阅读）

Run this check whenever a user asks about the inbox for the first time in a session, or any time

inbox-reports-list

returns

count: 0

. The diagnosis decides what to say next.

每当用户在会话中首次询问收件箱相关问题，或

inbox-reports-list

count: 0

时，运行此检查。诊断结果将决定后续回复内容。

Step 1 — Look at source configs

步骤1 — 查看源配置

json

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

Three meaningful cases:

Case A — no source configs at all (
count: 0
)

The user hasn't onboarded to Inbox / signals. Don't pretend the inbox has data. Tell the user plainly that Inbox needs signal sources to be set up first, and that the recommended way to do this is to install PostHog Code at https://posthog.com/code. Example response:

Your project doesn't have any signal sources configured yet, so the Inbox is empty. Inbox surfaces issues and trends that PostHog automatically clusters from sources like error tracking, session replay, GitHub, Linear, and Zendesk. The fastest way to set this up is to install PostHog Code — once it's connected, signals will start flowing in and reports will appear in your inbox over the next day or so.

Stop here unless the user wants to discuss setup. Don't run further inbox tools — they'll all be empty.

Case B — source configs exist but all are
enabled: false

Sources have been set up at some point but are currently turned off. Tell the user no signals are flowing right now and point them at the project's signals settings to re-enable. Don't go fishing for reports — anything still there is stale.

Case C — at least one source config is
enabled: true

Setup looks healthy. If

inbox-reports-list

still returns nothing, it's most likely "give it time" — signals are flowing but nothing has clustered into a report yet. Tell the user that, briefly list which sources are active (e.g. "you have GitHub and error tracking enabled"), and offer to check back later or to drop into the

signals

skill to look at raw signal volume.

If any source config has

status: "failed"

, surface that as part of your reply — that source isn't producing signals right now, which may explain a thin inbox.

json

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

存在三种有意义的情况：

情况A — 完全没有源配置（
count: 0
）

用户尚未接入Inbox/信号功能。不要假设施件箱中有数据。直接告知用户，Inbox需要先设置信号源，推荐的方式是在https://posthog.com/code安装PostHog Code。示例回复：

你的项目尚未配置任何信号源，因此收件箱为空。Inbox会展示PostHog自动从错误追踪、会话重放、GitHub、Linear、Zendesk等源聚合而来的问题和趋势。最快的设置方式是安装PostHog Code——连接完成后，信号将开始流入，报告将在次日左右出现在你的收件箱中。

除非用户想要讨论设置问题，否则到此为止。不要运行更多收件箱工具——它们都会返回空结果。

情况B — 存在源配置但全部为
enabled: false

源曾被设置过，但目前处于关闭状态。告知用户当前没有信号流入，并引导用户前往项目的信号设置页面重新启用。无需尝试查找报告——现有报告均已过期。

情况C — 至少有一个源配置为
enabled: true

设置看起来正常。如果

inbox-reports-list

仍返回空结果，最可能的原因是“需要等待一段时间”——信号正在流入，但尚未聚合成报告。告知用户这一点，简要列出哪些源处于激活状态（例如“你已启用GitHub和错误追踪”），并主动提出稍后再次检查，或切换至

signals

技能查看原始信号量。

如果任何源配置的

status: "failed"

，请在回复中指出这一点——该源当前无法生成信号，这可能是收件箱内容稀少的原因。

Step 2 — Only then proceed to the user's actual question

步骤2 — 之后再处理用户的实际问题

If Step 1 found a healthy setup and at least one report exists, continue with the triage / drill / filter workflows below.

如果步骤1发现设置正常且至少存在一份报告，请继续执行下方的分类/深入/筛选流程。

Workflow: triage what's actionable

流程：分类可执行内容

When the user asks "what should I look at?" or "what's actionable?":

当用户询问“我应该关注什么？”或“哪些内容是可执行的？”时：

Step 1 — Pull the ready/in-progress queue

步骤1 — 获取就绪/处理中的队列

json

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

count: 0

comes back, jump to the empty/unconfigured workflow above before saying "your inbox is empty" — the right reply depends on whether sources are configured.

json

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

如果返回

count: 0

，请先执行上方的空收件箱/未配置流程，再告知用户“你的收件箱为空”——正确回复取决于源是否已配置。

Step 2 — Summarize by source and actionability

步骤2 — 按源和可执行性汇总

For each report, the response includes:

```
id
```
,
```
title
```
,
```
summary
```
```
status
```
,
```
priority
```
,
```
actionability
```
(note:
```
null
```
for reports still in
```
pending_input
```
/
```
candidate
```
— judgment hasn't run yet)
```
signal_count
```
,
```
total_weight
```
— how much underlying evidence drove the report
```
source_products
```
— which product(s) the underlying signals came from
```
is_suggested_reviewer
```
— whether the current user is a suggested reviewer
```
implementation_pr_url
```
— if a PR has been opened against this report
```
_posthogUrl
```
— clickable deep-link to the report; always include this in your response

Group the results so the user can scan quickly:

text

undefined

每份报告的回复包含：

```
id
```
、
```
title
```
、
```
summary
```
```
status
```
、
```
priority
```
、
```
actionability
```
（注意：对于处于
```
pending_input
```
/
```
candidate
```
状态的报告，该字段为
```
null
```
——尚未完成判断）
```
signal_count
```
、
```
total_weight
```
——生成报告的底层证据数量
```
source_products
```
——底层信号来自哪些产品
```
is_suggested_reviewer
```
——当前用户是否为推荐审核人
```
implementation_pr_url
```
——是否已针对此报告提交PR
```
_posthogUrl
```
——指向报告的可点击深层链接；回复中务必包含此链接

对结果进行分组，方便用户快速浏览：

text

undefined

Inbox — 8 actionable reports

收件箱 — 8份可执行报告

🔴 High priority (3)

Checkout error rate spiked 3× — error_tracking, 47 signals <_posthogUrl>
Session replays on /pricing show repeated rage clicks — session_replay, 12 signals <_posthogUrl> …

🟠 Medium priority (4) …

🟡 Suggested for you (1) …

undefined

🔴 高优先级（3份）

结账页面错误率飙升3倍 — error_tracking，47个信号 <_posthogUrl>
/pricing页面会话重放显示多次愤怒点击 — session_replay，12个信号 <_posthogUrl> …

🟠 中优先级（4份） …

🟡 为你推荐（1份） …

undefined

Step 3 — Offer the drill-down

步骤3 — 提供深入查看选项

End with a clear hand-off: "Want me to dig into the checkout errors?" → call

inbox-reports-retrieve

for the full report, then optionally hop to the

signals

skill to look at the underlying signal text.

结尾给出明确引导：“需要我深入查看结账错误的详情吗？” → 调用

inbox-reports-retrieve

获取完整报告，然后可选择切换至

signals

技能查看底层信号文本。

Workflow: drill into a specific report

流程：深入查看特定报告

When the user pastes an Inbox URL or report ID:

json

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

Returns the full record including

signals_at_run

and

artefact_count

. Combine this with the

signals

skill if the user wants to see the actual signal contents:

Use
```
inbox-reports-retrieve
```
to get the report metadata +
```
id
```
Use the
```
signals
```
skill's Example 2 (fetch all signals for a specific report) — pass the report ID as
```
metadata.report_id
```
in the HogQL query

The two layers complement each other: the

inbox-*

tools give you the curated/judged view, and the

signals

skill lets you inspect the raw observations that produced it.

当用户粘贴Inbox URL或报告ID时：

json

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

返回完整记录，包括

signals_at_run

和

artefact_count

。如果用户想要查看实际信号内容，请结合

signals

技能使用：

使用
```
inbox-reports-retrieve
```
获取报告元数据+
```
id
```
使用
```
signals
```
技能的示例2（获取特定报告的所有信号）——在HogQL查询中传入报告ID作为
```
metadata.report_id
```

这两个层面相辅相成：

inbox-*

工具提供经过整理/判断的视图，

signals

技能则允许你查看生成报告的原始观测结果。

Workflow: filter by topic or source

流程：按主题或源筛选

"Are there any reports about <topic>?" — start with

search

json

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

search

matches title and summary. If the user is asking about a product area rather than a keyword, use

source_product

json

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

If the keyword search returns nothing meaningful, hand off to the

signals

skill — semantic search over signal text via

embedText()

will catch reports the keyword filter missed.

“有没有关于<主题>的报告？”——先使用

search

：

json

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

search

会匹配标题和摘要。如果用户询问的是产品领域而非关键词，请使用

source_product

：

json

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

如果关键词搜索未返回有效结果，请切换至

signals

技能——通过

embedText()

对信号文本进行语义搜索，会捕获关键词筛选遗漏的报告。

Workflow: review configured sources

流程：查看已配置的源

When the user asks "which signal sources are set up?" or "is <product> hooked up?":

json

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

Each entry returns

id

source_product

source_type

enabled

status

, plus timestamps. For full details (including the per-source

config

JSON — recording filters, evaluation IDs, etc.):

json

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

Integration credentials live in a separate

Integration

model — they are not in the

config

blob, so it's safe to summarize the contents back to the user.

The

status

field reflects the underlying data import or workflow:

```
running
```
/
```
completed
```
— feeding signals normally
```
failed
```
— the source isn't currently producing signals; flag this to the user

当用户询问“已设置哪些信号源？”或“<产品>是否已连接？”时：

json

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

每条记录返回

id

、

source_product

、

source_type

、

enabled

、

status

以及时间戳。如需完整详情（包括每个源的

config

JSON——记录筛选器、评估ID等）：

json

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

集成凭据存储在单独的

Integration

模型中——它们不在

config

数据块中，因此可以安全地向用户汇总内容。

status

字段反映底层数据导入或工作流的状态：

```
running
```
/
```
completed
```
——正常提供信号
```
failed
```
——当前无法生成信号；请向用户指出这一点

Tips

提示

Check setup before assuming the inbox is empty. If
```
inbox-reports-list
```
returns
```
count: 0
```
, call
```
inbox-source-configs-list
```
first — no sources means the user needs to install PostHog Code to start receiving signals; sources-but-no-reports means signals are flowing but nothing has clustered yet
Always surface
_posthogUrl
so the user can click through to the report
The default ordering already prioritizes the user's suggested reports — don't reorder unless asked
```
priority
```
and
```
actionability
```
are
```
null
```
for reports still in
```
pending_input
```
or
```
candidate
```
status; this is expected, not a bug — judgment hasn't run yet
```
suppressed
```
reports are excluded by default; pass
```
status: "suppressed"
```
explicitly if the user wants to see hidden items
Don't try to write to the inbox via MCP — destroy / state changes / reingest endpoints are intentionally not exposed. If the user wants to act on a report, point them at the
```
_posthogUrl
```
deep-link
For "what kinds of signals exist?" or "what's been happening recently across all sources?", drop into the
```
signals
```
skill — the report layer hides individual observations; you need HogQL on
```
document_embeddings
```
to see them
Source configs don't have per-record deep-links — they live behind project settings, so
```
inbox-source-configs-retrieve
```
returns no
```
_posthogUrl
```
. Don't confuse them with reports

**在假设收件箱为空之前先检查设置。**如果
```
inbox-reports-list
```
返回
```
count: 0
```
，请先调用
```
inbox-source-configs-list
```
——没有源意味着用户需要安装PostHog Code才能开始接收信号；有源但无报告意味着信号正在流入，但尚未聚合成报告
务必展示
_posthogUrl
，方便用户点击查看报告
默认排序已优先显示用户的推荐报告——除非用户要求，否则不要重新排序
对于处于
```
pending_input
```
或
```
candidate
```
状态的报告，
```
priority
```
和
```
actionability
```
为
```
null
```
；这是正常现象，并非bug——尚未完成判断
默认会排除
```
suppressed
```
报告；如果用户想要查看隐藏内容，请显式传入
```
status: "suppressed"
```
不要尝试通过MCP写入收件箱——销毁/状态更改/重新导入端点目前未开放。如果用户想要对报告执行操作，请引导他们使用
```
_posthogUrl
```
深层链接
对于“存在哪些类型的信号？”或“最近所有源的情况如何？”这类问题，请切换至
```
signals
```
技能——报告层会隐藏单个观测结果；你需要通过HogQL查询
```
document_embeddings
```
才能查看它们
源配置没有单条记录的深层链接——它们位于项目设置页面后方，因此
```
inbox-source-configs-retrieve
```
不会返回
```
_posthogUrl
```
。不要将它们与报告混淆