/prioritizing-my-inbox

name: prioritizing-my-inbox
description: >
  Build a personal, ranked shortlist of the PostHog Inbox reports the current user is most
  likely to care about right now. Combines the user's activity summary (what they work on and
  keep an eye on), the inbox ranking model's open, action and fix probabilities and lifts,
  suggested-reviewer routing, ownership, pull request state and recency, then returns the top N
  (25 by default) ordered from most to least relevant. Use when the user says "let's look at my
  inbox", "what's in my inbox for me?", "my top 10 inbox reports", "what should I look at today?",
  or asks to re-rank, focus, or filter that list. For browsing, filtering, drilling into, or
  acting on a single report, use `inbox-exploration`.

Prioritizing my inbox

The inbox on an active project holds hundreds or thousands of open reports. The default list order puts the user's suggested reports first, then sorts by status and update time. That order is not a personal ranking. This skill builds one: a short, ranked list of the reports this person would pick first, with a reason for each.

Three inputs decide the rank:

1. **Who the person is right now.** `activity-summary-get` returns their current themes, the objects they own and watch, and the products they work in. 2. **What the model predicts.** Each report row carries `ranking.predictions` with a probability and a lift for `open`, `action` and `fix`. 3. **What the report needs from them.** Suggested reviewer, claims they answer for, `pending_input` status, an approved pull request waiting to merge.

The output is a ranked list, not a dump. Use your judgment on top of the score: the score finds candidates, you decide the order.

Parse the request

• **N**: "top 10", "my top 5", "25 things". Default to 25. Above 50, warn that the tail gets thin and ask whether they want a filter instead.
• **Focus**: a theme, product, or keyword ("only anomaly stuff", "error tracking"). It becomes an extra candidate pool and a boost, not a hard filter, unless they say "only".
• **Exclusions**: "skip digests", "not the scout fleet ones", "nothing with a PR yet".
• **Window**: "this week", "today", "since Monday". Default to reports created or updated in the last 14 days.
• **Mode**: "things I can fix", "things waiting on me", "just new ones". Each maps to a pool or boost below.

Step 1: Load the person

activity-summary-get
{}

From the response, build an **interest profile**:

• **Themes** with `strength` and `last_seen`. A theme seen in the last 3 days with `strength: high` counts most.
• **Specific terms** from `computed.owned` and `computed.watched`: skill names, flag keys, saved query names, insight and dashboard names. These match reports far better than generic theme words.
• **Products** from `computed.products.works_in` and `computed.pages`. They map to `source_product` and to report topics.
• **Recently asked about** lines in `profile`. A report the person asked about this week is a strong candidate.

Generic words make bad search terms. On a busy project, `search: "ranking"` can match hundreds of reports because summaries mention ranking in passing. Prefer terms like an owned skill name (`anomaly-metrics`), a flag key, or a distinctive phrase from a theme label.

If the call returns `status: not_ready` or a 404, there is no summary for this person. Say so in one line and continue with the other signals. The ranking then leans on suggested-reviewer routing, claims, and the model. Offer to let the person name two or three topics they care about, and use those as the interest profile.

Step 2: Gather candidates

Report rows are large (often 3 to 4 KB each, mostly the summary), so pull several small pools rather than one big page. Keep `limit` at 20 or below per call. Pass `exclude` with ids you already hold to keep later pools fresh. `exclude` takes at most 100 ids and the API rejects a longer list, so send the 100 you most want to skip (the strongest candidates so far) and dedupe the rest locally. Pools overlap; dedupe by `id` and remember which pools each report came from.

| Pool | Call | Why | | ----------------------- | --------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | For you | `view: "for_you"`, `sort: "recommended"`, `created_after: <window>` | Routed to them, waiting on them, or claimed by them | | Recently updated | `view: "for_you"`, `ordering: "-updated_at"`, no `created_after` | Older reports with new activity, such as a new PR approval or question | | Mine | `assignee: "mine"` | Work they or their agents already own | | Likely action | `view: "actionable"`, `ordering: "-ranking_action"`, `created_after: <window>` | What the model thinks someone will act on | | New and likely opened | `created_after: <last 3 to 7 days>`, `ordering: "-ranking_open"` | Fresh reports worth a look | | Theme searches | `search: "<specific term>"`, `created_after: <window>`, one call per top theme (3 to 5 calls, `limit` 10 to 15) | Personal relevance the routing misses | | Needs my input (option) | `view: "needs_input"`, `scope: "for_me"`, `created_after: <window>` | Decisio