> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Usage Insights (/insight)
> Type /insight in any AI SRE session to automatically analyze your last 30 days of sessions and produce a read-only coach's monthly retrospective — what's working first, then the frictions worth eliminating, and finally higher-leverage next steps to try.
**Private beta**: AI SRE is currently in private beta. Pro or higher accounts can apply for free beta access through the [AI SRE private beta application form](https://c9xudyniiq.feishu.cn/share/base/form/shrcn0ngCfdoygiaHnAT80BfZiH); after approval, Flashduty will add your account to the whitelist. Features and the UI may change during the beta.
## Overview
***
Type `/insight` in the input box of any AI SRE session and AI SRE will look back at **your** last 30 days of sessions to produce a single-page operational insight report. The report uses a parchment-style HTML layout and renders directly in the session as a chat card, which you can preview and download.
It is a **coach's read on the month**, not a problem list. It leads with **what's working** — where AI SRE genuinely pulled its weight this month; then covers the **frictions worth eliminating now** — the patterns that repeatedly drain your time, such as pasting the same database connection string across multiple sessions, an agent missing a runbook it should already know, or it repeatedly querying the wrong data source; and finally offers **2–3 higher-leverage next steps** — shifts in *how* you work with AI SRE that are worth trying.
`/insight` is **read-only**. It only analyzes and presents; it will **not** automatically modify any knowledge, skill, or MCP configuration. Every suggestion is copyable text — whether to act on it is entirely up to you. See [How to Act on Suggestions](#how-to-act-on-suggestions).
`/insight` is a built-in AI SRE skill: it automatically exports your past sessions, computes quantitative metrics, analyzes the session content section by section, and renders a consolidated report. The entire process is transparent to you — all you need to do is type `/insight`.
## How to Generate
***
Type `/insight` in the input box of any AI SRE session and send it. No parameters are required.
The scope depends on whether the current session is bound to a team (see the table below). AI SRE will state the analysis scope and time window (default: last 30 days) at the beginning of the report.
AI SRE exports sessions, computes metrics, analyzes the content, and then renders the parchment-style report as a chat card, accompanied by a 2–3 sentence spoken summary. You can preview or download the full report from the card.
### Analysis Scope
`/insight` always uses the **account** as the security boundary — it only sees sessions readable by the current `app_key` and never crosses that boundary. Within that boundary, the specific scope depends on whether the session is bound to a team:
| Session state | Analysis scope | Notes |
| ------------------------------------------------------------- | ---------------------- | ------------------------------------------------------------------------------- |
| Bound to a team (e.g. a war room / a team selected in the UI) | **That team** | The report focuses on that single team's sessions over the last 30 days |
| Not bound to a team | **The entire account** | Analyzes your own sessions plus sessions belonging to teams you are a member of |
If your session is not bound to a team but you only want to see a specific team's data, name that team (by name or ID) when you type `/insight`. AI SRE will ask you to confirm before narrowing the scope to that team.
### How the Report Is Produced
Understanding how the report is put together helps you see where the numbers come from:
AI SRE first lists the sessions within scope for the last 30 days (up to 200 by default), covering **all four entry kinds** — web, IM, API, and scheduled; IM is a primary AI SRE entry point, so IM-originated sessions are analyzed alongside web. After exporting their full records, it keeps the sessions with **real signal**: **≥ 2 user-message turns OR ≥ 3 tool calls** (either one qualifies — `INSIGHT_MIN_MSGS` / `INSIGHT_MIN_CALLS`). The tool-call arm matters: it lets autonomous runs kicked off by an alert or a schedule — which may have zero human turns yet a dozen tool calls of real investigation — into the report, instead of being silently dropped by a user-turns-only filter. The quantitative overview also renders an **entry mix** line (`entry_mix`) showing where these sessions came from.
The report's quantitative overview — session count, your turn count, tool call count, average turns, daily activity, tool and skill distribution, entry mix, model distribution, and outcome distribution — is computed deterministically across all sessions by program logic, not estimated by the model, so it is reliable and always present even when no friction is found.
AI SRE reads the session records in sections, distilling "session topics," "wins," and "friction findings" from each, then consolidates everything: topics are aggregated into a narrative overview, the most representative wins are surfaced, and findings are deduplicated, clustered, and ranked by importance into friction cards. Every conclusion carries a **verbatim quote** as its evidence; session IDs are used internally only — to count how often a friction recurs — and are **never shown** in the report. The report contains only the distilled topics and findings — it does not copy your full raw session content verbatim.
## Report Contents
***
The report has **six parts** from top to bottom. Regardless of whether any friction is found, the quantitative overview is always present.
### 1. At a glance
A **2–4 sentence** coaching synthesis at the very top of the report, written **last** after everything else, reducing the whole month to the gist: volume and top theme, the one thing working best, and the one friction worth fixing first.
### 2. Overview (quantitative)
Computed deterministically by program logic, not estimated by the model; the model only transcribes the numbers into the report. Includes:
| Metric | Description |
| -------------------- | --------------------------------------------------------------------------------------------- |
| Sessions | Number of sessions included in this analysis (`sessions`) |
| Your turns | Total number of messages you sent across those sessions (`your turns`) |
| Tool calls | Total number of tool calls initiated by the agent (`tool calls`) |
| Avg turns | Average number of turns per session (`avg turns / session`, one decimal place) |
| Activity | Per-day session activity bar chart, with start and end dates labeled |
| Tool distribution | Ranking of tools the agent relied on most (top \~6) |
| Skill distribution | Ranking of skills invoked during sessions; shows "No skills invoked" if none were called |
| Entry mix | Where the sessions came from, formatted as `web (60) · IM (25) · scheduled (5)` (`entry_mix`) |
| Model distribution | How many sessions used each model, formatted as `model name (N sessions)` |
| Outcome distribution | Count of completed / incomplete / errored sessions (zero values omitted) |
### 3. Narrative
A **2–4 sentence** second-person summary of what you were mainly working on this month — the most common domains, recurring entities (the same incident analyzed more than once, a cluster or host that kept appearing), and the overall shape of the month's work. This part is aggregated from the topics surfaced across your sessions.
### 4. What's working
The top \~3 concrete, evidence-backed things AI SRE did **well** — cross-source validation, correct noise triage, a clean root-cause analysis. This part balances the report and is never skipped when there are real wins; each carries a verbatim quote as its evidence.
### 5. Frictions
Friction cards ranked **from highest to lowest importance**, up to approximately 8 cards. Each card includes:
* A **rank** and a **friction type label** (one of five types; see the next section);
* A **frequency badge** showing how many distinct sessions this friction consumed your time in (deduplicated evidence session count);
* A one-line title and a second-person explanation;
* **Evidence**: a single **verbatim quote** from the transcript (the most telling user or agent line); session IDs are used internally only — to count recurrence — and are **not shown**;
* **A copyable recommendation**: text you can paste directly, whose first line is the destination (`Add this to knowledge//…`), so the target file travels with the paste.
### 6. Next steps
About **2–3** forward-looking, grounded suggestions. These are **strategic** (a shift in *how* you work with AI SRE, higher-leverage), distinct from the tactical, file-level fixes in the friction cards; each names the exact observation it's grounded in (a stat from the overview or a friction cluster) and maps to a real AI SRE capability.
Every friction and win must be grounded in at least one real session and carry a verbatim quote as evidence — the report never fabricates sessions, facts, or runbook gaps. If no rankable friction is found, the frictions part displays an empty-state message while the rest of the report still renders — in that case, "the overview itself is the report."
## Friction Types
***
`/insight` recognizes exactly five friction types, each corresponding to a clear, adjustable "dial." Listed in default importance order:
| Friction type | What it looks like in sessions | Recommended destination |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ |
| `repeated_context` (repeated context) | **Strongest signal.** A long-lived fact you provided in **≥ 2 different sessions** (database connection string, team ownership of a service, dashboard URL, escalation path, cluster name, etc.) | Write it into DUTY.md / `services.md` so it auto-loads in every future session |
| `missing_runbook` (missing runbook) | The agent had to improvise a multi-step investigation that you clearly expected it to already know | Add a runbook: `runbooks/.md` in the knowledge base |
| `wrong_data_source` (wrong data source) | The agent queried the wrong data source / cluster / namespace and you corrected it | Fix the correct data source in `observability.md` / `clusters.md` |
| `hallucinated_entity` (hallucinated entity) | The agent referenced a service / host / metric / change that does not exist and you denied it | Add the real entity list to `services.md` |
| `stale_knowledge` (stale knowledge) | A fact from the knowledge / DUTY.md was outdated or wrong and you corrected it on the spot | Update that outdated file |
`repeated_context` is ranked first because it is **the most persistent** — the same fact being provided repeatedly across multiple sessions means persisting it into the knowledge base once will benefit every future session. When its evidence count ties with other friction types, it still ranks higher.
## How to Act on Suggestions
***
The report is **read-only**: it surfaces problems and provides copyable fix text, but **never** automatically applies any changes. During the beta, all suggestions are copy-paste style — you confirm them, then manually apply them in the corresponding resource.
Friction cards are already ranked by importance. Start with the top-ranked cards that have high frequency badge numbers — those are the patterns consuming your time most repeatedly.
Each card's "Copyable suggestion" contains text you can paste directly, and its first line (`Add this to knowledge//…`) is the destination — telling you which file it belongs in, and traveling with the paste.
Based on the friction type, paste and save in the appropriate resource: repeated context and hallucinated entities go into the knowledge base's `services.md` or DUTY.md; a missing runbook means adding a new runbook to the knowledge base; a wrong data source gets pinned in `observability.md` / `clusters.md`; stale knowledge means updating the outdated file directly. These are all standard edits under [Knowledges](/en/ai-sre/knowledge).
`/insight` will never perform any writes on your behalf — it does not invoke any sync or install actions, and does not modify knowledges, skills, or MCP. If you later want AI SRE to "add this runbook," that is an **independent** natural-language instruction and is outside the scope of `/insight`.
`/insight` runs on demand, one report at a time — it does not "continuously watch" or generate reports on a schedule. The recommended approach is to run it again after accumulating a few more incident investigations, to see which frictions have been resolved and which new ones have emerged.
## Related Pages
***
Learn about session creation, team binding, and war rooms — these determine the analysis scope of `/insight`.
Most suggestions from the report land in the knowledge base's DUTY.md / `services.md` / runbooks. This page explains how to edit them.
Get a high-level understanding of AI SRE's capabilities and how it works.