/alts-brief

name: alts-brief
description: Prepare a meeting-ready alternative-investments brief for a client, household, IRA, trust, or named account before a review — pulls the alts book from iCapital or Addepar (positions, NAV vs. commitment, called and unfunded amounts, contributions/distributions/subscriptions/redemptions, lockups, and the platform's own IRR/TVPI/DPI/RVPI) and sits it beside the liquid book and IPS target from the connected portfolio system (Orion Connect, Addepar, or Envestnet), then flags cash needed for capital calls, alts % vs. target, concentration, unfunded concentration, and stale as-of data. Cites the source platform on every figure and keeps disclosures on the page. Does not recommend funds, forecast NAVs/IRRs, or simulate allocation changes. Triggers on "alts brief", "/alts-brief", "prep the [client]'s alts review", "what's going on with [client]'s PE/private investments", "how's [client] doing on their alts", or any request to review a household's alternative investment positions before a meeting.

Alts Brief

Give an advisor a clear, meeting-ready read on a household's alternative investments: what's on platform, how it's tracking against their goals, and what needs attention — sitting alongside the liquid book so the advisor can see the whole household, not just the alts sleeve in isolation.

Inputs

Required: **client/household name**. Optional: an as-of/cutoff date if the advisor wants the "recent activity" portion of the brief anchored to a specific date rather than "latest available" (default: since the last brief, or trailing 12 months if this is the first one), and a specific fund or manager to focus on if they only want part of the book.

**Identity grain:** alts are frequently held at a level *below* the household — an IRA, a trust, a single person, or one named account. Take the advisor's grain literally: "the Harrington IRA," "the Whitmore Trust," "Robert Harrington," or "the Northgate account" each mean that entity, not the whole household. Don't silently widen a named account up to its household, and don't narrow a household down to one account.

**Disambiguation rule:** confirm identity before pulling anything, the same as every other skill in this plugin — if more than one client, household, or account matches the name, show the candidates and ask which one before proceeding. Never proceed on a name match alone. When nothing is connected there is no match to confirm: take the name and grain as the advisor gave them, say so in the brief, and go.

Once identity is confirmed, **pull the alts book and the liquid/IPS picture in parallel** (Steps 1 and 2) — one missing source degrades only its own section, never the other. Before starting, tell the advisor what you're gathering and why, so a slow multi-source pull doesn't look like a silent hang. And once the client and grain are known, don't ask "should I start?" — narrate what you're doing and go; the approval gates here are the format conversion at the end and the /compliance recommendation, not permission to begin.

Data Gathering — Steps 1 and 2 run at the same time

Steps 1 and 2 read different systems and share no state. **Dispatch them as `claude-for-financial-advisors:source-extract` subagents in a single message** — one `Agent(claude-for-financial-advisors:source-extract)` call per platform the household could be on, all in the same response rather than in sequence: iCapital and Addepar for the alts book; Orion Connect, Addepar, or Envestnet for the liquid book. You don't know which of them is connected until a read tells you, and finding out is the read's job, not a step before it: each searches for its own platform's tools by name and returns data or `NOT CONNECTED`, so a platform the household isn't on costs one short return. Never run a connectivity check from this session first — not yourself, and not through a general-purpose helper — because in a session with no platform tools that check ends with no read dispatched at all, and the Convention below is triggered by a read's `NOT CONNECTED`, never by a guess made before it. Hand each the household identity as you have it, the one system that subagent is to query (iCapital or Addepar for a Step 1 read; Orion Connect, Addepar, or Envestnet for a Step 2 read), the field schema under its step heading, and the lookback window.

Each returns a filled schema block. They do not summarize, flag, or size anything against the IPS target — Steps 3 and 4 are yours, and they need the raw figures, not a subagent's read of them.

**Identity stays with you.** `claude-for-financial-advisors:source-extract` never resolves a household: if it returns `IDENTITY MISMATCH`, show the advisor the candidates, confirm, and re-dispatch. A `NOT CONNECTED` return is the Connector Placeholder Convention case — the subagent won't offer the manual fallback, because it isn't in the conversation. You do. The same goes if more than one connected tool could try to solve the same problem for this household on either read below (not necessarily two of the same kind): ask the advisor once which is the book of record, per the Ask-Once, Then Route Convention, rather than guessing, and offer to help them save the choice using the Personalization Convention. (Step 1's iCapital/Addepar handling below is a deliberate exception to this, not an oversight.) This check isn't one-time — a source the advisor mentions on the fly mid-gathering counts too, and asking again before merging it in. And if two systems were pulled anyway and return the same household at figures apart by orders of magnitude, follow the Magnitude-Conflict Convention: name the conflict, and exclude the outlier's figures from every table and total rather than quoting them as evidence.

Step 1: Alts Book — iCapital or Addepar

Alts can come from either platform, and some households have both, so the Step 1 reads go to both (see Data Gathering above): the one that returns data is the one you use, and both re