anthropics/claude-for-financial-advisors/alts-brief

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: never proceed on a name match alone, 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 building anything on it. This skill reads no CRM, so the matching happens in the reads: dispatch them on the name and grain as the advisor gave them, and a read that finds several candidates or a different household returns IDENTITY MISMATCH with what it saw — that is when you show the candidates and ask. Never call a platform's tools yourself to check the name first: that call is a read, and reads are dispatched (Data Gathering below). Where no read matched the name — nothing connected, or nothing found — say in the brief that the name and grain are as the advisor gave them.

Once you have the name and grain, 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` reads, one per platform, in a single message: one Agent(claude-for-financial-advisors:source-extract) call per read, all in the same response, each in the foreground (run_in_background: false) so every block comes back as its call's result inside this turn: iCapital, Addepar and CAIS for the alts book (Step 1), Orion Connect and Envestnet for the liquid book (Step 2), with Step 2's fields added to Addepar's read because it serves both steps. The five go out every time, whatever you expect a platform to hold — with one exception: when your tool search finds tools for more than one of the liquid-book platforms, their Step 2 reads wait on the book-of-record question below, and every other read still goes in the first message. Writing each dispatch is where you look for its platform's tools: take their names from your own tool list, or, where they aren't there, from a ToolSearch by the platform's own name, and put every name you found into that dispatch exactly as written — the full name, never a prefix you guessed and never the platform's name in a tool's place — because a read calls only the tools you name, by exactly the names you give. Asking a platform's assistant is a read. A question put to a platform's own assistant reads that platform, even where the platform keeps the question in the advisor's own history, so it is never a reason to leave the platform unread. A dispatch hands its read every tool you found for its platform, never a shorter list and never a note to avoid one, and a read you finish inline works from the same list: which of them a read calls is for the read's own instructions and the platform's provider file to decide. Where you found none — not in your list, nothing from the search, or no ToolSearch offered in this session — that dispatch says so in their place, and names no status for the read to return: the read's own contract decides that, and the brief reports what it returned. That search decides what each read is handed, never whether it is dispatched — only the advisor's book-of-record answer below holds a read back — and it never stands in for a read's return: what the brief says about a platform comes from its read (below). Make it yourself, never through a general-purpose helper. Hand each the household identity as you have it, the one system that subagent is to query, the tool names you found for it or that you found none, the field schema under its step heading, and the window its step states for that read.

An alts platform the advisor asks you to read beyond those five gets its own read the same way: one more source-extract dispatch in that same message, handed Step 1's schema and the tool names you found for it, and never read by you instead. Everything below about a read covers it, and Step 6's Sources line names it.

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. A platform's part of the brief is written from its read's block — its figures, each with any qualifier the source states on it (an estimate, "approximately", a range, positions valued as of different dates), its NOTHING FOUND line and its "— pending" cells alike — or from your own inline read where Finish every read below sends you there. There is no third source: a platform with neither has not been read, and your own tool search is not a read.

Finish every read in this turn. A read whose dispatch errors, is refused because the concurrent-subagent limit is reached, returns CANNOT CALL, or hasn't come back by the time you would otherwise end your turn is yours to do inline — the same platform, the tools you found for it, the same schema — and its result goes into the brief exactly as a returned block would. Those four cases are the only times you call a platform's tools yourself before the brief is written, and each is something a dispatch did, so a platform you haven't dispatched has nothing to finish: never read one inline in place of its dispatch, ahead of it, or to check the name. A read you finish inline follows the plugin's provider file for its platform where there is one, as its dispatched read would: before your first call, list ${CLAUDE_PLUGIN_ROOT}/providers/, and if it holds a folder named for that platform, read every file in it and follow it for the whole read. When a read you finish inline is of a source that answers in prose, read it as its dispatched read would. Ask one question naming every field. If the answer leaves fields out and returned a session or conversation id, ask once more on that id, naming only those fields; with no id, ask nothing more. Never ask in a new conversation, never two questions at once in one conversation, and never a second follow-up, so a field still unstated is not available. Fill a field only from a figure the source labels as that field. For a field it does not hold, quote its own words, and never turn them into a figure. Where the provider file differs from these rules on how to word a question, how many calls a conversation takes, or a reply an answer needs, follow the provider file; it never changes which household you read. Never end your turn with a read outstanding: a slower brief is the fallback, a half-built one never is. An IDENTITY MISMATCH is not outstanding — it is the question below — nor is a Step 2 read waiting on the book-of-record question below, which hasn't been dispatched; and no failure here is fixed by dispatching the same read again.