anthropics/claude-for-financial-advisors/estate-and-tax-brief

Estate & Tax Brief

Give an advisor a clear, meeting-ready read on whether a household's accounts are actually set up the way its estate plan intends — the mismatch between "what the documents say" and "what the accounts show" is where estate plans quietly fail, often unnoticed until it's too late to fix. Opens with what's already been discussed so the meeting doesn't retread old ground, and closes the loop by turning approved flags into tracked CRM follow-ups.

Inputs

Required: household name. If not provided, ask before doing anything else.

Disambiguation rule: confirm the household before pulling anything, the same as every other skill in this plugin — if more than one household matches the name, show the candidates and ask which one before proceeding.

Once identity is confirmed, pull from all connected sources in parallel (Steps 1-4) — one slow or missing source degrades only its own section of the brief, not the rest. Before starting this multi-source pull, tell the advisor what you're about to gather and why, so a slow pull doesn't look like a silent hang. And once the household is known, don't ask "should I start?" — narrate what you're doing and go; the approval gates in this skill are the CRM writes in Step 8 and any format conversion at the end, not permission to begin.

Data Gathering — Steps 1 through 4 run at the same time

The four reads below hit different systems, or different reports on one system, and share no state. Dispatch them as `claude-for-financial-advisors:source-extract` subagents in a single message — an Agent(claude-for-financial-advisors:source-extract) call per read, all in the same response and each in the foreground (run_in_background: false), so every block comes back as its call's result inside this turn: one for the CRM, one for the estate plan and one for the tax look-back — both from the estate platform (Wealth.com) — and one for each connected custodian, portfolio or alts platform in Step 4. Look for the tools before you trust the registry. ToolSearch by the system's own name is where you look when a system's tools aren't in your own list: the names that come back are the ones you hand its read. 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. Find each system's tools yourself, and hand the names down: if they are in your own tool list, take their names from there; if they aren't, take every name that ToolSearch by the system's own name returns for it. Hand each read those names exactly as written — the full name, never a prefix you guessed and never the system's name in a tool's place — because a read calls only the tools you name, by exactly the names you give; for a system you found no tools for, its dispatch says so instead of naming any. 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 finish 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. That search decides what each read is handed, and which Step 4 platforms get a read at all; it never decides whether the CRM, estate-plan and tax reads go out — those three are dispatched whatever it found (one that overlaps waits on the book-of-record question below, then goes out), and each of their sections is written from its read's return, never from the search. Hand each 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 under its step heading, and the window where the read is time-bounded.

The dispatch holds whatever is connected, one system included. Running the reads at once is the lesser reason for it. The greater is that every read comes back the same way: a block from one system, with a status that means one thing and its fields as that system returned them, uninterpreted, and every section of the brief is written from such a block by the rules below, whichever systems answered. So a system that is the only one connected, or that holds every read, is never one you read yourself. Find the household in it with a name search, nothing that returns plan, tax, account or meeting data, then dispatch its reads, one per read, in the same message as the CRM, estate-plan and tax reads it doesn't serve. Those three go out whether or not you found tools for their systems: a section whose system you found no tools for is written from its read's NOT CONNECTED, never from your search, while a Step 4 platform gets a read only where you found its tools. Where one system serves two reads, as the estate platform serves the estate plan and the tax look-back, hand each of them the whole list you found for that system, not the part that read seems to need: which of them a read calls is the read's to decide. The reads you make yourself are only the ones the next paragraph gives you.

Each returns a filled schema block. Step 5's comparison needs both sides as raw normalized lists, so the subagents are told not to interpret, match, or flag anything — that would pre-empt the comparison with a read you can't audit. 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 system, the tools you found for it, the same schema and window — and its result goes into the brief exactly as a returned block would. A read you finish inline follows the plugin's provider file for its system 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 system, read every file in it and follow it for the whole 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 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.

Identity stays with you, per the disambiguation rule above. claude-for-financial-advisors:source-extract never resolves a household: an IDENTITY MISMATCH return comes back with candidates — put them to the advisor, and re-dispatch that one read only once they confirm which household is correct. That is the only return a re-dispatch is right for. A NOTHING FOUND return is not a mismatch and is never re-dispatched: the system was reached, searched, and holds nothing for this household, so its section says "Nothing found in [system] for [household] — searched [what the read reports it searched]" — never the placeholder sentence, which says the system couldn't be reached, or a "— pending" marker, which says the data is still to come, and never a candidate question, which says it found someone else. A PARTIAL return is used as far as it goes and is never re-dispatched: the fields it filled go in as returned, and each field it did not carries a "— pending [system]" marker with the reason the read gives — never re-read to fill it, because a read stops at PARTIAL only where going on would take a write, which no read in this skill makes, or where every call it made returned an error, which a second read would only meet again. A read where some calls were answered and others returned an error comes back OK: its filled fields go in as returned and are never marked pending, and a field it marks "— not available ([system] returned an error: …)" is "— pending [system]" in the brief, with the error quoted, because an error says nothing about what the system holds. A NOT CONNECTED return is the Connector Placeholder Convention case — you make the manual-fallback offer, not the subagent — and it is never retried by re-dispatching the same extractor: these four reads fire in one message, and a source that wasn't reachable when they fired doesn't become reachable by firing the same read again, so a second dispatch returns NOT CONNECTED again at the same cost. If the advisor connects that source later in the conversation, that's a fresh request rather than a retry. Asking which system to trust is yours too, under the Ask-Once, Then Route Convention. Step 4 is a defined route, not a question: it reads every custodian, portfolio and alts platform whose tools you found and cross-checks their titling, and two of them contradicting each other is Step 4's blocking conflict. The other reads are not: if your tool search found tools for more than one CRM — or more than one system for any other read below — the order is fixed: identify the household in one of them (a name search, nothing that returns notes, tasks or plan data), then ask the advisor once which is the book of record for this household, then dispatch that read to that system only. The CRM they name is also the one Step 8 writes to. 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 Vasquez household 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. The reads that don't overlap still go out in the first message; only the overlapping one waits on the answer. 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. This isn't a one-time check at the start — a source the advisor mentions mid-gathering (a CRM note, an outside document) counts too, and gets the same question before it's merged 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: Since We Last Met — CRM Context