Update to Flowlines

{
  "description": "Investigate a specific problem in Flowlines - a signal, a user complaint, a failed session, or a suspicious pattern - from the aggregate down to the exact turn, over the Flowlines MCP server, while handling end-user data with care. Use when the user asks why something went wrong, wants to look into a signal or a user's sessions, or needs evidence for a bug report.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 230
    }
  ],
  "name": "flowlines-investigate-session",
  "skill_md_contents": "---\nname: flowlines-investigate-session\ndescription: Investigate a specific problem in Flowlines - a signal, a user complaint, a failed session, or a suspicious pattern - from the aggregate down to the exact turn, over the Flowlines MCP server, while handling end-user data with care. Use when the user asks why something went wrong, wants to look into a signal or a user's sessions, or needs evidence for a bug report.\n---\n\n# Flowlines session investigation\n\nGo from a symptom to a verifiable cause with the smallest exposure of end-user content. Aggregates first, then the session, then only the turns that matter.\n\n## Conventions for every Flowlines tool call\n\n- Every tool takes `reason` and `user_intent`. Keep `user_intent` identical across the conversation, for example \"Find out why the billing agent fails on refund requests\".\n- Start with `get_workspace` once, then `get_context` for the namespace. Read pinned notes first: the problem may already be a known artifact.\n- Flowlines data is real production conversations. Quote the minimum, mask names, emails, phone numbers, addresses, identifiers, and payment details, and never copy a transcript into a note, ticket, or report.\n- End with `report_outcome` as the last tool call.\n\n## Starting points\n\nPick the entry that matches what the user has:\n\n- **A signal.** `list_signals` to find it, then `get_signal` for evidence and affected sessions and users.\n- **A user.** `get_user_activity` for the timeline, outcomes, agents, intents, signals, and representative sessions. Prefer this over listing that user's sessions.\n- **A session id.** `get_session` directly.\n- **A description.** `search` with `types` narrowed to `session` or `turn`, a time window, and the agent, then `fetch` the locators worth opening.\n- **A pattern.** `aggregate_sessions` grouped by `intent`, `agent`, or `day` with `failure_rate` and `failure_count`, ordered by the metric, to find where the problem concentrates before opening anything.\n\n## Steps\n\n1. Scope the problem with aggregates. Establish how many sessions, users, and days are affected and whether it is growing. `get_metric_definition` for any rate you quote.\n2. Choose at most five representative sessions: the earliest, the most recent, and the ones the signal or user activity points at. `list_sessions` with `outcome`, `user_feedback`, `intent_family`, `from`, and `to` narrows the pick.\n3. `get_session` for each. Read the analysis and the turn tree before any content: the session summary, outcome, and findings often name the failing turn.\n4. `get_turn` only for the turns the analysis points at. Compare the user's request, the tool calls, and the assistant reply on that turn. Look for the usual causes: wrong intent classification, a tool error surfaced as a normal reply, missing context, a policy refusal, a loop, or a truncated response.\n5. Check whether the cause is upstream of the agent: an ingestion gap (turns missing, timestamps out of order), an unmapped user identity, or an evaluator artifact. Pinned notes and `list_agent_attributes` help here.\n6. Confirm the cause on a second session before calling it a cause. One session is an anecdote.\n7. Estimate blast radius with one more `aggregate_sessions` filtered to the intent or agent, and check `list_signals` for a signal that already tracks it.\n8. If the finding is durable and verified, `save_note` with the finding, the evidence in aggregate terms, and how future analysis should account for it. Never include personal data in the note.\n9. `report_outcome`.\n\n## Output shape\n\n```\nSymptom: what was reported, in one line\nScope: sessions, users, agents, first and last occurrence, trend\nCause: the mechanism, with the turn-level evidence (masked, minimal quotes)\nConfirmed on: session ids used as evidence\nBlast radius: share of sessions for the intent or agent in the window\nRelated signals and notes\nRecommended fix or next check\nOpen questions (also sent as unmet_needs)\n```\n\n## Handling content\n\n- Reference sessions and turns by id and index, not by pasting them.\n- When a quote is unavoidable, keep it to the fragment that proves the point and replace identifiers with placeholders such as `<email>`.\n- Do not reproduce prompts, system instructions, or tool payloads in full.\n- If the user asks for a full transcript, point them to the session in the Flowlines app rather than reproducing it here.\n"
}