Update to Intelligo

{
  "name": "intelligo-profile-summary",
  "description": "High-level factual summary of one Intelligo profile — background check, credit check, and social media analysis, with executive summary, red/yellow flags, and key findings. Summarizes one profile (person or company), not a project; if the query is ambiguous it searches profiles and projects, and hands a project off to the project-summary skill. Use whenever the user wants a summary, recap, key takeaways, risk read, red flags, or major risks on a person or company in due diligence — even without saying \"Intelligo.\" Offers four selectable views (executive summary, flag count, flags + findings, per-tab breakdown) and asks which when unspecified. Triggers: \"summarize X\", \"red flags on X\", \"what did we find on X\", \"how many flags on X\", \"exec summary on X\", \"break X down by tab\". Do NOT use for web research, monitoring, action items, or project-level summaries.",
  "included_files": [
    {
      "relative_path": "references/profile-resolution.md",
      "size_in_bytes": 7582
    }
  ],
  "skill_md_contents": "---\nname: intelligo-profile-summary\ndescription: >-\n  High-level factual summary of one Intelligo profile — background check, credit check, and\n  social media analysis, with executive summary, red/yellow flags, and key findings. Summarizes one\n  profile (person or company), not a project; if the query is ambiguous it searches profiles and\n  projects, and hands a project off to the project-summary skill. Use whenever the user wants a\n  summary, recap, key takeaways, risk read, red flags, or major risks on a person or company in due\n  diligence — even without saying \"Intelligo.\" Offers four selectable views (executive summary, flag\n  count, flags + findings, per-tab breakdown) and asks which when unspecified. Triggers: \"summarize\n  X\", \"red flags on X\", \"what did we find on X\", \"how many flags on X\", \"exec summary on X\", \"break X\n  down by tab\". Do NOT use for web research, monitoring, action items, or project-level summaries.\n---\n\n# Intelligo Profile Summary\n\nTurn an Intelligo **profile** into a high-level, factual summary the user can read in under a minute.\n\n## Data model (overview)\n\nHierarchy: `Project → Profile → Report → Card → Flag`. Sources link to Cards. Linked Notes attach to Cards. This hierarchy is **conceptual** — `Get_report_content` returns Report, Cards, and Flags together in one response (see Connector tools).\n\n**Profile** is the DD subject (Person or Company shape — see tool specs for field-level detail).\n\n**Report** belongs to a profile, carries a product type (background check, credit check, social media analysis), a status, and a format (card-based for BG checks, PDF for credit / social media). Multiple reports of the same product type can exist on a profile, distinguished by creation time; the skill picks among them by status (see Step 2).\n\n**Card** is a finding item inside a card-based report. Each card has a type (which determines its content fields — professional, education, news, legal, etc.). Cards do **not** have a reliable generic description field — the skill renders type-specific fields instead.\n\n**Flag** is a separate object linked from a Card. Surfacing a flag means showing flag.name + flag.description alongside the card it points to.\n\n### Report status — what's summarizable\n\n| Status | Usable? |\n|---|---|\n| Pending consent | No — falls back to older complete report if exists, otherwise skip |\n| In progress | No — same fallback as Pending consent |\n| Preliminary | Yes, with prominent caveat (not human-verified) |\n| Ready | Yes, normal |\n| Reviewed | Yes, normal (equivalent to Ready for summary purposes) |\n\n### Report format — what the skill can do\n\n| Product | Format | Skill can read content? |\n|---|---|---|\n| Background Check | Card-based | Yes — iterates cards, renders by type |\n| Credit Check | PDF | Connector returns metadata only (flag counts, optional exec summary, link). The document text is readable **only when the PDF is uploaded/available** — see PDF content access below |\n| Social Media Analysis | PDF | Same as Credit Check |\n\n#### PDF content access\n\n`Get_report_content` returns only the PDF's metadata (URL, flag counts, optional exec summary) — never the document text. But the skill **can** read and summarize a PDF when the file itself is available to it (the user uploaded the report into the conversation, or it's otherwise readable):\n\n1. **PDF content available** → read it and answer or summarize normally, exactly like any other source. Don't limit yourself to metadata.\n2. **Not available, and the user wants PDF detail** → ask the user to upload the report PDF.\n3. **Still unavailable** → do **not** continue with the PDF: never guess or fabricate its content. Fall back to the connector metadata (flag counts + link) and tell the user the content isn't available.\n\nThe skill never invents PDF content.\n\n### Summary-text source — one rule, all formats\n\n1. If the report carries an analyst-written executive summary → use it (verbatim or near-verbatim; light editing for length OK).\n2. Else, card-based → synthesize a short overview from the cards and flags.\n3. Else, PDF → if the PDF content is available, summarize from it; otherwise surface flag counts + link (see PDF content access).\n\nThe skill does **not** branch on the BG-check level. Background checks carry a free-form variant label (e.g. \"A3 Advantage - Level 3\", \"Now\", \"AML\", \"Go\") — the skill displays it verbatim in the section header but doesn't change behavior based on it.\n\n### In/out of scope\n\n- **In scope:** Profile (for ID only), Reports (DD products, most recent per product), Cards, Flags, Linked Notes (inline with their finding).\n- **Out of scope:** Monitoring (separate product), all Action items (Refresh, Reviewed, Add Monitoring, Upgrade, Flag Action Item), Comments.\n- **No opinions:** no investment recommendations, no risk verdicts, no singling out / ranking (\"the most material is X\", \"focus on Y\"). Severity ordering (red → yellow → other) is the only allowed prioritization signal.\n\n## Connector tools\n\nThe connector exposes **three tools**: `Get_profiles`, `Get_projects`, and `Get_report_content`. Field-level names are owned by engineering and live in the connector's own docs; this section specifies what each tool gives the skill.\n\nThe data hierarchy — Project → Profile → Report → Card → Flag — is a **concept**, not a tool layout: `Get_report_content` returns **Report + Cards + Flags together** in a single call.\n\n### `Get_profiles` — resolve a name; returns profile detail + report list\n\nGiven a query (a name, partial name, or company name), return the matching profile candidates. This one tool covers both resolving the profile and learning which reports exist on it — there is no separate profile-detail call. Each candidate carries:\n\n- Enough identifying metadata to disambiguate persons from companies and display in a picker. `references/profile-resolution.md` lists which fields to surface per case (Sr/Jr, duplicates, subsidiaries, common name).\n- The profile's full identifying fields (person or company shape). The skill surfaces only the minimum needed to confirm the subject (Bucket 1); extended fields — emails, social media handles, full addresses, related key people — are present but not surfaced unless a finding references them.\n- The profile's **report list** — every report attached, with the metadata Step 2 needs: a **report id** (to pass to `Get_report_content`), product type, status, and creation time. Multiple reports of the same product type can appear, distinguished by creation time; the skill picks among them by status (see the status taxonomy in the data model).\n\n### `Get_projects` — resolve a name to a project\n\nSame search shape as `Get_profiles`, but for projects (investments). Called in parallel with `Get_profiles` in Step 1 because the user's query might name a project, not a profile.\n\nEach candidate project includes a short preview of the profiles attached to it (typically the first several, not all). The skill uses this preview both for disambiguation (e.g. \"Acme Series B — 3 profiles under it: Acme Holdings, Jane Doe, John Smith\") and as a fallback path: if the user picks the project but the project-summary skill isn't available, the skill can offer to summarize one of the listed profiles instead.\n\n### `Get_report_content` — one report id → that report, with cards + flags merged\n\nTakes a **single report id** (from the report list `Get_profiles` returned) and returns that one report's content. **Call it once per report** the skill decided to summarize — fetch in parallel across reports where possible. The shape depends on the product's format:\n\n**Card-based reports (background checks):** the report's optional analyst-written executive summary, plus its findings as a list of cards, plus the flags raised — all in one response. Each card has a type (which determines its content fields), a title, optional verification state, and optionally a linked note (analyst-added context). Each flag has a severity (red or yellow), a name, a description (the analyst's reason for flagging), and a link to its card. Report, Card, and Flag remain distinct concepts but arrive merged here.\n\n**PDF reports (credit check, social media analysis):** a stable URL to the PDF document, optional filename, flag counts, and rarely an executive summary. This tool returns only the metadata around the PDF, not its text — but the skill can read the document itself when the PDF is uploaded/available (see PDF content access).\n\n### Concepts the skill relies on\n\nA few specifics the skill encodes as logic and that need to map cleanly to whatever the connector returns (these all arrive inside `Get_report_content`'s card payload):\n\n- **Verification state on cards.** The skill renders three states differently: confirmed against a source, explicitly unverified by an analyst (no source supports it), and no analyst position. The connector exposes this however it likes (a tri-state field, two booleans, etc.) — the skill expects to be able to distinguish all three.\n- **Collaborators on profiles and projects.** Returned for authorization/visibility purposes. The skill does not surface this in summaries unless the user explicitly asks about access.\n- **Linked notes on cards.** Optional analyst-added context attached to a card. The skill renders these inline with their finding when they add information beyond what the flag already conveys.\n\n### Behavior if a tool is missing or returns nothing\n\n- `Get_profiles` unavailable → ask the user for more details (company, project, jurisdiction, role); without resolution the skill can't proceed.\n- `Get_projects` unavailable → skip the project-collision check; proceed with profile search only.\n- `Get_profiles` returns a profile but no report list → if the user gave enough data to refine search, ask for more specifics; if only a name, stop.\n- `Get_report_content` unavailable or empty → stop and tell the user the connector isn't returning report content.\n\nNever invent content the connector didn't return.\n\n## Step 1 — Resolve to a Profile\n\n**Read `references/profile-resolution.md` first.** That reference defines the resolution logic: searching profiles + projects in parallel, disambiguating multiple matches, recognizing edge cases (Sr/Jr, duplicates, subsidiaries, common names), the combining-with-warning behavior, and the rule about reusing an already-resolved profile from earlier in the conversation. It's shared across future Intelligo skills.\n\nThis skill's specific decisions after resolution:\n\n1. **User picks a profile** → proceed to Step 2.\n2. **User picks a project** → hand off to the project-summary skill if available. If unavailable, list the profiles under the project (returned alongside each project in the search results) and offer to summarize one instead.\n\n## Step 2 — Pick the right report per product\n\n`Get_profiles` already returned the profile's full metadata and its report list during Step 1 resolution. From that list:\n\n1. Filter out any monitoring entries.\n2. Group remaining entries by product type.\n3. For each product group, sort by creation time newest first, then walk the list with the **status-aware selection rules** below.\n4. Silently skip products with no entries (e.g. credit check wasn't run).\n\nIf no product yields a summarizable report, tell the user plainly what's available and what isn't, then stop.\n\n### Status-aware selection (per product)\n\nWalk the product's reports newest-first by creation time:\n\n| Latest status | Action |\n|---|---|\n| Ready or Reviewed | Use it. |\n| Preliminary | Use it. Add a preliminary caveat alert (see Bucket 2 in Step 3). |\n| In progress | Use an older Ready or Reviewed report from the same product group if one exists, with a fallback caveat alert. If none exists, skip this product and tell the user. |\n| Pending consent | Same logic as In progress. |\n\nIf any product fell back to an older report or was skipped entirely, surface it in both the profile-level intro line AND the product section — the user should see the warning in both places.\n\nIf the user explicitly asked for a different version (in-progress, preliminary, an older one), override the default and use the one they asked for. Status caveats still apply.\n\nFor each selected report, call `Get_report_content` with its report id to fetch the full content (cards + flags merged). Fetch in parallel across reports where possible.\n\n### Narrowing to a single product\n\nIf the user named a single product (\"just the background check\"), apply the same selection rules only for that product.\n\n## Step 3 — Choose a summary view, then write\n\nThe skill offers **four independent summary views**. They're self-contained, but the user can ask for one or several — deliver exactly what their request calls for, combining views in a single response when needed, with no extra prompting once the need is clear. Two buckets always render (profile ID + alerts); the chosen view(s) fill the body. After delivering, the skill offers to go deeper into anything not yet shown.\n\n### The four views\n\n| View | Returns | Products |\n|---|---|---|\n| **Executive summary** | The analyst exec-summary text (verbatim / light edit) **plus the red/yellow flags** (BG → flag lines: severity, name, description; PDF → flag counts). No exec summary? BG → a 2–3 sentence overview synthesized from cards; PDF → if the PDF is available, summarize from it, else note the summary lives in the PDF + link. Omits non-flagged cards. | All |\n| **Flag count** | Red / yellow flag counts per product (a fast risk gauge); optionally broken down per report tab/category on request (BG only). No names, no descriptions. | All |\n| **Flags + findings** | The full per-finding list (the detailed view). BG → iterates cards; PDF → if available, summarize findings from the document, else flag counts + PDF link. | All |\n| **Per-tab summary** | A 1–2 sentence synthesis per card category/tab present (Professional, Legal, News, Education, Regulatory, etc.). Organized by category, not by flag. | BG only; PDFs have no tabs — if available, a short summary from the document, else counts + link |\n\n### Picking the view\n\n- **Phrasing names a level → use it, don't ask:**\n  - \"exec summary\", \"the gist\", \"tl;dr\", \"high level\", \"key takeaways\", \"what should I know about X\", \"most important info\" → Executive summary\n  - \"how many flags\", \"flag count\", \"how many red/yellow flags\", \"risk gauge\", \"do we have any risk on X\", \"anything concerning?\" → Flag count (\"…by tab/section/category\" → Flag count with the per-tab breakdown)\n  - \"findings\", \"what did we find\", \"key findings\", \"show me / all the red flags on X\" (scope to red-flagged items), \"just the yellow flags\" → Flags + findings\n  - \"by category\", \"by section\", \"per tab\", \"break it down by area\" → Per-tab summary\n- **Risk-oriented phrasing** (\"any risk\", \"red flags\", \"what should I worry about\") maps to whichever view above fits — but the skill stays factual: it reports what was flagged and never gives a risk verdict or investment opinion (see \"No opinions\" in the data model). Severity order (red → yellow) is the only allowed prioritization.\n- **Phrasing names several levels, or asks for \"everything\" / \"the full picture\" / \"all of it\" → deliver those views together in one response, don't ask.** Render them in canonical order: Executive summary → Flag count → Flags + findings → Per-tab summary. \"Everything\" means all four.\n- **Just \"summarize X\" with no level → ask**, after resolving the profile and checking what's available. The user may pick one or more:\n\n  > \"Which level(s) do you want for [Name]? (pick any — I can combine them)\n  > 1. **Executive summary** — the analyst's headline read\n  > 2. **Flag count** — just how many red / yellow flags\n  > 3. **Flags + findings** — the full flagged-finding list\n  > 4. **Per-tab breakdown** — short summary by category (Professional, Legal, News…)\"\n- **A single product was named** (\"just the background check\") → the chosen view(s) apply within that product only.\n\n### Always shown in every view: profile ID + alerts\n\nBuckets 1 and 2 render regardless of the chosen view — the user must confirm the subject and see caveats at any depth.\n\n### Bucket 1 — Profile identification\n\nThe minimum needed to confirm the right profile — name + a few identifying fields per type. Anything beyond this (addresses, emails, social media, related key people, etc.) stays out of this bucket and only surfaces if a finding directly references it.\n\n- **Persons:** name, current Position @ Company, date of birth (use what the connector returns — full date, year only, or whatever's available; omit silently if unknown), jurisdiction, project name.\n- **Companies:** name, company type, HQ City + Country, jurisdiction, project name. When HQ location and jurisdiction are the same, show one — don't repeat (e.g. a Delaware US company HQ'd in Delaware shows \"Delaware US\" once, not twice). When they differ (e.g. Delaware corp HQ'd in NYC), show both.\n\n### Bucket 2 — Alerts (only if applicable)\n\nCaveats the user needs to see *before* reading the summary. Each on its own line, prefixed `⚠`. Omit the bucket entirely if no alerts apply. Examples:\n\n- ⚠ Preliminary report — not human-verified. Data may change in the final version.\n- ⚠ The most recent background check is still in progress. This summary is from the previous report (Feb 2026).\n- ⚠ Combined output across N profiles — see warning at the top.\n\nThe combining warning has its full text specified in `references/profile-resolution.md`. Use that exact warning when the user explicitly asked to combine profiles.\n\n### Bucket 3 — View body\n\nThe body is the chosen view. Every view renders one section per product that exists on the profile (BG, Credit, Social) — silently skip products that weren't run. Length is short by default (the user is time-constrained) but **not capped**: extend when the content is genuinely substantial.\n\n**Executive summary view.** Per product, the analyst exec-summary text (verbatim or lightly edited for length), **followed by the report's flags** — for a BG check, the red/yellow flag lines (severity · name — description, using the finding-line format but only the flagged items); for a PDF, the flag counts. If a product has no exec summary: BG → synthesize a 2–3 sentence overview from its cards and flags; PDF → if the PDF content is available, write a short summary from it, otherwise state the summary is only in the PDF and give the link (see PDF content access). Omits non-flagged cards and per-card type detail (that's the Flags + findings view).\n\n**Flag count view.** Per product, the red / yellow counts only — e.g. \"Background Check: 2 red, 3 yellow.\" No flag names or descriptions. If a product has zero flags, say so (\"no flags\"). Available for all products, including PDFs (counts come from metadata). **Optional per-tab breakdown:** when the user asks (e.g. \"flag count by tab\", \"how many flags in each section\"), break the counts down per report tab/category for a BG check — \"Background Check — 5 total · Professional 1 red · Legal 1 red, 2 yellow · News 1 yellow.\" Default is the per-product total; the breakdown applies only on request and only to card-based reports (PDFs have no tabs, so they stay at the product total).\n\n**Flags + findings view.** The detailed view. Per product: BG checks render the full per-finding list (see \"Rendering a finding line,\" \"Ordering,\" and \"Findings filter\" below). PDF products: if the PDF content is available, summarize its findings from the document; otherwise show flag counts + the PDF link (see PDF content access). If the user scopes to a severity (\"all the red flags\", \"only the yellow flags\"), render just that tier and omit the rest; if that tier is empty, say so plainly.\n\n**Per-tab summary view (BG check only).** Group the BG check's cards by category/tab (Professional, Legal, News, Education, Regulatory, etc.). For each category that has content, write a 1–2 sentence synthesis of what's there, noting whether it carries flags (e.g. \"Legal — one red-flagged item, a 2019 civil judgment; rest clean.\"). Organize by category, not by severity. Skip categories with no cards. PDF products have no tabs to break down — if their content is available, give a short summary from the document, otherwise fall back to flag counts + PDF link.\n\n### Output skeletons\n\nEvery view opens with the ID line + any alerts:\n\n```\n**[Profile Name]**\n[Persons: Position @ Company, b. [DOB as returned] · [Jurisdiction] · Project: <project name>]\n[Companies: Company Type · HQ City, Country · [Jurisdiction] · Project: <project name>]\n\n[⚠ Alert lines, each on its own line — only if applicable.]\n```\n\n**Executive summary view**\n```\n### Background Check — [variant label verbatim, e.g. \"A3 Advantage - Level 3\"]\n[Exec summary, or synthesized 2–3 sentence overview.]\nFlags:\n- 🔴 RED · [flag name] — [flag description].\n- 🟡 YELLOW · [flag name] — [flag description].\n\n### Credit Check\n[Exec summary if present; else summarize from the PDF if it's available; else: \"Summary is in the PDF — (link).\"]\nFlag counts: N red, M yellow.\n```\n\n**Flag count view**\n```\nBackground Check — 2 red, 3 yellow\nCredit Check — 0 red, 1 yellow\nSocial Media Analysis — no flags\n```\nPer-tab breakdown (on request, BG only):\n```\nBackground Check — 5 total\n- Professional — 1 red\n- Legal — 1 red, 2 yellow\n- News — 1 yellow\nCredit Check — 0 red, 1 yellow   (PDF, no tabs)\n```\n\n**Flags + findings view**\n```\n### Background Check — [variant label verbatim]\n[Exec summary if present, else synthesized short overview.]\n\nFindings:\n- 🔴 RED · [flag name] — [flag description]. Card: [card title]. [Type-specific context if it adds value.]\n- 🟡 YELLOW · [flag name] — [flag description]. Card: [card title]. [Type-specific context.]\n- [card title] — [type-specific content for non-flagged material cards]. [Verified: yes/no if set.]\n\n### Credit Check\n[Exec summary if present.]\nFlag counts: N red, M yellow.\nFull report: [filename or \"Credit Check PDF\"] (link)\n\n### Social Media Analysis\n[Same structure as Credit Check.]\n```\n\n**Per-tab summary view (BG only)**\n```\n### Background Check — [variant label verbatim]\n- **Professional** — [1–2 sentence synthesis]. [flags noted if any]\n- **Legal** — [1–2 sentence synthesis]. [flags noted if any]\n- **News** — [1–2 sentence synthesis].\n- [other categories present…]\n\n(Credit / Social have no tabs — show flag counts + PDF link instead.)\n```\n\nEvery view closes with a one-line \"go deeper\" offer (see below).\n\n### Rendering a finding line\n\nThese rules apply to the **Flags + findings view** (and the flag-noting in the Per-tab view). Order is **always: flag first, card second.** The flag is the headline (severity + reason for flagging); the card is supporting context. Card titles can be cryptic and there's no reliable generic description on a card, so the flag is what carries substance.\n\n1. `🔴 RED ·` or `🟡 YELLOW ·` — severity prefix. **The icon color must match the flag's severity: 🔴 for red flags, 🟡 for yellow flags. Never use a red icon for a yellow flag or vice versa.**\n2. [flag name] — [flag description] — what and why.\n3. Card: [card title] — the underlying card.\n4. **Type-specific context** — when the title alone doesn't carry the substance, add the type-specific fields that genuinely help the user understand the finding. Use judgment: pick the fields that identify and contextualize the item without padding. The exact set varies by card type and by what's populated. Some patterns:\n   - Professional cards → position, company, dates\n   - Education cards → degree, institution\n   - News cards → article date, short summary text\n   - Legal cards → case type, jurisdiction\n   - Other types: surface whatever type-specific fields are populated and add information beyond the title; otherwise stop at the title.\n5. If a linked note is attached AND adds something beyond the flag/card content → append the note inline. Skip if redundant.\n6. If the card has an explicit verification state → append \"Verified: yes\" or \"Verified: no — no source confirms this.\" Skip if absent (no analyst position).\n\nNon-flagged material cards use the same type-specific rendering, just without the flag prefix.\n\n### Ordering within a finding list\n\n1. 🔴 RED-flagged cards first\n2. 🟡 YELLOW-flagged cards next\n3. Non-flagged material cards last\n\nWithin each tier, preserve the order Intelligo returned. The connector's order reflects Intelligo's classification — keep it.\n\n### Findings filter — what stays out of the list\n\nThese items belong to the data model but stay out of the rendered findings list. Listed here so it's clear they're intentionally excluded, not missed:\n\n- Routine clean sections. (A clean section gets one line *only if* its cleanliness is itself notable, e.g. \"No adverse legal records found.\")\n- Findings that aren't material.\n- Same finding appearing in multiple reports → mention it under the section carrying the higher-severity flag, with a short cross-reference noting it also appears in the other report. One full description per finding, even when the finding shows up in multiple places.\n- Profile metadata beyond what's on the ID line.\n- Redundant linked notes.\n- Fabricated detail. If a report doesn't say it, don't infer it.\n\n### Offer to go deeper\n\nAfter delivering, close with a one-line offer naming only the views **not already shown** (skip anything already included in this response):\n\n- After **Executive summary** or **Flag count** → \"Want the full flags + findings, or a per-tab breakdown?\"\n- After **Per-tab summary** → \"Want the full flags + findings for any category?\"\n- After **Flags + findings** (or when all four views were already delivered) → \"Want me to drill into any specific finding?\"\n\n## Examples\n\n**Example 1 — plain \"summarize\" with no level → ask which view:**\n> User: \"Summarize what we have on Sarah Levin.\"\n> [Profile resolved → BG Check (card-based, latest), Credit Check (PDF, latest), Social Media (PDF, latest); monitoring filtered out]\n> Since no level was specified, ask: \"Which level of summary do you want for Sarah Levin? 1. Executive summary · 2. Flag count · 3. Flags + findings · 4. Per-tab breakdown.\"\n> The user picks; the skill renders only that view, then offers to go deeper.\n\n**Example 1a — Executive summary view:**\n> User: \"Give me the exec summary on Sarah Levin.\" (or picks 1 above)\n> Per product, render the analyst's exec summary text, then the red/yellow flags (BG → flag lines; PDF → flag counts). Non-flagged cards are omitted. Close: \"Want the full flags + findings, or a per-tab breakdown?\"\n\n**Example 1b — Flag count view:**\n> User: \"How many flags on Sarah Levin?\"\n> ID line + alerts, then: \"Background Check — 2 red, 3 yellow · Credit Check — 0 red, 1 yellow · Social Media — no flags.\" No descriptions. Close: \"Want the full flags + findings, or a per-tab breakdown?\"\n\n**Example 1c — Flags + findings view (the detailed default lens):**\n> User: \"What did we find on Sarah Levin?\" (or picks 3)\n> BG Check iterates cards as findings; Credit/Social show flag counts + PDF link (or a summary from the document if the PDF is uploaded). Close: \"Want me to drill into any specific finding?\"\n\n**Example 1d — Per-tab summary view:**\n> User: \"Break Sarah Levin's background check down by category.\"\n> One line per category present: \"Professional — 12 yrs at two PE firms, no gaps. · Legal — one red-flagged item, a 2019 civil judgment; rest clean. · News — minor coverage, nothing adverse.\" Credit/Social fall back to counts + link. Close: \"Want the full flags + findings for any category?\"\n\n**Example 1e — combined views in one response (no extra prompting):**\n> User: \"Give me the exec summary and the flag count for Sarah Levin.\" (or \"give me everything\")\n> Deliver both (or all four for \"everything\") in a single response, in canonical order: ID line + alerts, then Executive summary, then Flag count. No picker. Close by offering only what wasn't shown.\n\n**Example 2 — partial coverage, silent skip:**\n> User: \"What did we find on Acme Holdings?\"\n> [Profile fetched → BG Check only]\n> Summarize BG Check. The summary stays focused on what exists; products that weren't run are silently absent from the output.\n\n**Example 3 — narrowing to one product:**\n> User: \"Just give me the background check on Sarah Levin.\"\n> Restrict to the background check product only.\n\n**Example 4 — no DD reports, only monitoring:**\n> User: \"Summarize what we have on Marcus Webb.\"\n> [Profile fetched → only monitoring]\n> \"This profile has no due-diligence reports to summarize — only monitoring, which isn't covered by this flow.\"\n\n**Example 5 — alternate-vocabulary triggers:**\n> User A: \"Summarize the candidate Sarah Levin.\"\n> User B: \"What did we find on the entity Acme Holdings?\"\n> User C: \"Give me a recap on the investment subject.\"\n> All three trigger the same way. The skill resolves to the right Profile and produces the standard summary. User B's \"the entity\" can be echoed back as \"the entity\" or \"the company.\"\n\n**Example 6 — mixed profile + project results:**\n> User: \"Summarize Acme.\"\n> [Profile search → Acme Holdings (company); project search → Acme Series B (project, 3 profiles)]\n> \"I found a few matches for 'Acme':\n>\n> **Profiles** (subjects)\n> 1. **Acme Holdings** — Corp, Delaware US, project: Acme Series B\n>\n> **Projects** (investments)\n> 2. **Acme Series B** — 3 profiles under it (Acme Holdings, Jane Doe — CEO, John Smith — CFO)\n>\n> Which one?\"\n\n**Example 7 — user picks a project:**\n> User: \"Summarize the Acme investment.\" (or picks the project from Example 6's list)\n> If project-summary skill is available → hand off.\n> If not → \"The Acme investment is a project (Acme Series B, 3 profiles). The project-summary flow isn't available right now. Want me to summarize one of the profiles instead? They are: Acme Holdings, Jane Doe, John Smith.\"\n\n**Example 8 — disambiguation across profiles (Sr/Jr, duplicates, subsidiaries, common names):**\n> See `references/profile-resolution.md` for the full edge-case handling.\n\n**Example 9 — preliminary report:**\n> [BG Check latest status = Preliminary]\n> BG Check section opens with: `⚠ Preliminary report — not human-verified. Data may change in the final version.`\n> Profile-level intro mentions: \"Background check is preliminary.\"\n\n**Example 10 — in-progress with older fallback:**\n> [BG Check latest = In progress; previous = Reviewed (Feb 2026)]\n> Use the Feb 2026 report. Alert: `⚠ The most recent background check is still in progress. This summary is from the previous report (Feb 2026).`\n\n**Example 11 — pending consent, no fallback:**\n> [BG Check latest = Pending consent, no older versions. No other products.]\n> \"Marcus Webb's background check is pending the subject's consent — no completed prior version exists. There's nothing to summarize yet.\"\n\n**Example 12 — user asks about PDF content:**\n> User: \"What did the credit check say about her bankruptcy history?\"\n> If the credit-check PDF has been uploaded / is readable → answer from its content directly and summarize the relevant section.\n> If not → \"The credit check is a PDF and I don't have its content yet — only the flag counts and the link. Upload the report PDF and I'll summarize the bankruptcy section, or open it yourself: [PDF link].\"\n> If the user can't provide it → don't guess at the content; stop at the flag counts + link. The skill never invents PDF content.\n\n**Example 13 — follow-up about a finding goes to a different skill:**\n> Earlier: skill resolved and summarized Sarah Levin's profile.\n> User (now): \"Tell me more about that bankruptcy finding.\"\n> This is no longer a summary request — it's a drill-down on a specific finding, handled by a separate skill. The shared `references/profile-resolution.md` rule about reusing an already-resolved profile applies there too, so the user doesn't have to re-identify Sarah Levin.\n> Contrast: \"Now summarize Marcus Webb\" names a new profile → this skill fires again with fresh resolution.\n\n**Example 14 — \"all the red flags\":**\n> User: \"I want to see all the red flags for Sarah Levin.\"\n> Flags + findings view, scoped to red-flagged items only (omit yellow and non-flagged cards), each as a standard finding line. If there are no red flags, say so plainly. Close: \"Want the yellow flags too, or the full findings?\"\n\n**Example 15 — \"most important info\" / \"key takeaways\":**\n> User: \"What's the most important information I should know about Sarah Levin?\" — or \"What are the key takeaways from this report?\"\n> Executive summary view — the analyst's headline read plus the red/yellow flags. No verdict or ranking beyond severity order.\n\n**Example 16 — \"do we have any risk\" (factual, no verdict):**\n> User: \"Do we have any risk on Sarah Levin?\"\n> Answer with the flag gauge, factually: the red/yellow counts, and name the red flags if any — e.g. \"The background check carries 2 red and 3 yellow flags; the reds are [flag], [flag].\" Do **not** give a risk verdict or investment opinion (see \"No opinions\"). Offer to go deeper: \"Want the full flags + findings?\"\n\n"
}