/estate-and-tax-brief

name: estate-and-tax-brief
description: Prepare a meeting-ready estate and tax brief for a household — opens with what was discussed and actioned since the last meeting (Wealthbox/Redtail/Salesforce), pulls the estate plan from Wealth.com (structure, key documents and whether each is signed, balance sheet) plus the prior-year tax look-back and that year's tax constants, and cross-checks it against how accounts are titled and beneficiaried at the custodian and portfolio platforms (Schwab, Orion/Addepar, iCapital) — surfacing unfunded trusts, titling mismatches, and beneficiary gaps as a prioritized flags list. The only write is creating advisor-approved follow-up tasks in the CRM (optional, approved first). Never drafts trust language, gives legal advice, retitles an account, or changes a beneficiary. Triggers on "estate brief", "estate meeting brief", "estate and tax brief", "estate plan review for [client]", "check [client]'s trust funding", "are [client]'s beneficiaries up to date", or "does [client]'s estate plan match their accounts".

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: one for the CRM, one for the Wealth.com estate plan, one for the Wealth.com tax look-back, and one for each connected custodian/portfolio platform in Step 4. Hand each the household identity as you have it, the one system that subagent is to query, the field schema under its step heading, and the window where the read is time-bounded.

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.

**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 `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. The same goes if more than one connected tool could try to solve the same problem for this household on one of the reads 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. 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

Query the household's CRM for the household's most recent meeting notes and open action items related to the estate plan (trust funding, titling, beneficiary designations). **Query at both grains: the household record's own notes, tasks, and events, and each person contact's.** In Wealthbox a household is itself a contact with its own id — the same list calls run against it — and estate items are routinely linked to the household record rather than either spouse, so a contact-only lookup silently misses them.

For each one, note whether it's been acted on: done, not done, or no update since it was logged — beside the item, in the section itself, so every action item carries its own status. One line at the end saying no updates are available is not that: the advisor reads the list item by item, and "no update" is a status each item gets on its own line. This becomes the opening section of the brief, so the advisor sees what's changed (or hasn't) before