anthropics/claude-for-financial-advisors/pre-meeting

Pre Meeting

Build a financial review prep document an advisor can read in 10 minutes and walk into the meeting confident.

Inputs

Required: household name and/or email address, and the timeframe the review covers (quarterly, annual, or ad hoc). If either is missing, ask for both before doing anything else — default the timeframe to quarterly if the advisor doesn't care which.

Optional (ask only if ambiguous): meeting date/time, anything specific the advisor wants to cover.

Take the advisor's grain literally. A household and a single account are both valid subjects. "The Harrington IRA" means that account; "the Harringtons" means the household. Don't silently widen a named account to its household, or narrow a household to one account.

Data Gathering

Follow the Connector Placeholder Convention (the plugin's conventions are defined in the onboarding skill): before assuming a system below isn't connected, look for its tools the way the next paragraph says — don't guess at a tool-name prefix like mcp__orion__*, since real connector tool names use opaque prefixes. If they're there, use them. If they aren't, say "This is where I'd pull [data] from [system], but it isn't connected in this session. You can connect it from your connector settings," then offer the manual fallback (paste, upload an export, or skip) and keep going. Apply this to every source below, not just the first one that's missing. If more than one connected tool could answer the same source below for this household — two CRMs, two portfolio platforms, or any pairing that holds the same fact — follow the Ask-Once, Then Route Convention in its fixed order: identify the household in one system (source 1's disambiguation rule — in the CRM, or in one of the overlapping systems if no CRM is connected), then ask the advisor once which is the book of record — one question naming the systems for every source that overlaps — before an overlapping source's read goes out, then dispatch that source's read to the system they named, and only that one. Reads for sources that don't overlap go out as usual. Never read the second system before they answer, and never guess. A name that doesn't resolve in the first system is not a reason to search the second: ask then, and put the name in the same question ("I couldn't find the Hendersons in Wealthbox — is Redtail their book of record, or do they go by another name?"). The question comes when that first search returns, whatever it returned — a match, several candidates (they go in that same question), nothing at all, or an error you can't read — before any other call to either overlapping system. "It isn't in this one, so let me check the other" is exactly the search this rule forbids: which system holds the household is the advisor's to tell you, not yours to find out by searching. When they answer, offer to save the choice so they aren't asked again next session — the offer opens the reply that takes their answer, before your first read to the system they named, even when their answer also hands you a different name to search: they paste "For the [household] household, treat [system] as the book of record for [data type]. Don't ask me to choose again for this household." into Settings → General → Instructions for Claude — Claude can't write those settings, so never offer to save it yourself or say you have. Two routes below are defined, not asked about: the CRM's household record is the book of record and the meeting-intelligence tool only colors it (source 4), and the held-away alts check reads an alts platform only when it isn't already this doc's portfolio source (source 2). This gathering pass touches several systems in sequence, so the check isn't a one-time thing at the top: re-run it whenever a later source could answer something an earlier one already did, and if two sources you did pull disagree on a material fact, stop and surface it to the advisor as a blocking question before the brief is finalized rather than presenting both. If the disagreement is by orders of magnitude for the same household, 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.

Look for the tools before you trust the registry, or the advisor. Your own tools are the check that decides: a system whose tools are in your tool list, or come back from a ToolSearch by the system's own name, is connected and callable — use them. Where the session offers ToolSearch, a system's tools can be held back until it loads them, so search by name for every source below whose tools aren't already in your list; where it offers none, nothing is held back, and your tool list is every tool you have. An advisor saying a system isn't connected, or that none is, doesn't decide it either, since advisors have usually forgotten what they connected during onboarding: look for every source below this way before you name any of them as not connected, and when you do, say it as what you found, not as what they told you. ListConnectors can answer "No installed connectors found" even in a session with several live, working connectors, and in some clients it renders a user-facing card rather than returning data at all. So it explains a gap, it never establishes one, and an empty result means unknown, never "nothing is connected". When it does return entries, read enabledInChat, not connected: connected: true with enabledInChat: false is authenticated but switched off for this chat, so tell the advisor they can enable it here rather than reporting it as unconnected; a missing or null connected is unknown, not disconnected.

Once identity is confirmed, pull from all connected sources in parallel — one slow or missing source degrades only its own section of the doc, not the rest. Before starting this multi-source pull, tell the advisor what you're about to gather and why, so it doesn't look like a silent hang — and in the same breath name the sources you won't be pulling because you looked for their tools and found none (above), each in the line above, which offers to connect it. Advisors don't notice a gap on their own. The offer costs nothing if they say no, and it never blocks: make it, then carry on with the best pass the connected systems allow. If the advisor has already said they don't have a given provider, don't raise it again, in that line or anywhere else, and don't leave "connect this" language anywhere in the document. And once the household and timeframe are known, don't ask "should I start?" — narrate what you're doing and go. Questions can still come before the document is written — a missing household or timeframe (Inputs), which household is theirs (source 1), which system is the book of record, a conflict between two sources, and source 7's data questions — but each asks for a fact only the advisor holds, never for permission to run the pull you've just described. It asks the advisor to agree to two things only: source 7's save in the analytics platform, once per conversation, in one line, and a report run on a portfolio system that only runs reports (source 2), as that system's rules say.

Dispatch the parallel pull as one `claude-for-financial-advisors:source-extract` subagent per source, all in a single message — the Agent tool, Agent(claude-for-financial-advisors:source-extract), one call per source in the same response so they run concurrently rather than one after another — except a source whose systems overlap, whose read waits on the book-of-record answer above and goes out once the advisor has named the system — each in the foreground (run_in_background: false) so every block comes back as its call's result inside this turn. Hand each read its system's tools by name. The check above is yours, never the read's: take each system's tool names from your own tool list, or from the ToolSearch by its name when they aren't there, and hand the read every name that came back for its system exactly as written — the full name, never a prefix you guessed and never the system's name in a tool's place — because, of its system's tools, a read calls only those you name, by exactly the names you give; tool search, which it may use to load them, is not one of them. Asking a system's assistant is a read. A question put to a system's own assistant reads that system, even where the system keeps the question in the advisor's own history, so it is never a reason to leave the system unread. A dispatch hands its read every tool you found for its system, never a shorter list and never a note to avoid one, and a read you do inline works from the same list: which of them a read calls is for the read's own instructions and the system's provider file to decide. Each dispatch hands over the household identity as you have it, the one system that subagent is to query, the tool names you found for it, the field schema for that source (what its heading below says to pull), and the window the timeframe implies — or, where a source reads current state and has no meaningful review window, a plain statement of that instead of a window. Each returns a filled schema block. Two reasons this is a subagent rather than a tool call you make yourself: the raw payloads — email threads, full holdings tables, an estate look-back — stay out of your context so you assemble the doc from six compact blocks instead of six raw dumps, and the extraction work for all six happens at once rather than sequentially in your own reasoning.

You still own identity. The subagents are instructed never to resolve it: a claude-for-financial-advisors:source-extract that finds several candidates or a mismatch returns IDENTITY MISMATCH with what it saw and stops. Handle that the way the disambiguation rule below says — show the advisor the candidates, confirm, re-dispatch. Verify the returned blocks agree on the household before assembling anything from them. Fanning the reads out does not move that responsibility; it stays with you.