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, in the CRM (Wealthbox/Redtail/Salesforce), pulls the estate plan from the estate platform (Wealth.com: structure, signed status per document, balance sheet) plus the prior-year tax look-back and that year's tax constants, and cross-checks that against account titling and beneficiaries at the custodian, portfolio and alts platforms (Orion Connect/Addepar/CAIS/iCapital), surfacing unfunded trusts, titling mismatches and beneficiary gaps as prioritized flags. The only write is optional advisor-approved CRM follow-up tasks, shown for approval 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 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

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 — and take that status from the CRM record itself; an item the record doesn't show acted on is "no update since it was logged", never "done" inferred from a later note, and no recap describes a meeting the CRM doesn't record — 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 diving into the current comparison.

> **Connector Placeholder Convention:** if the CRM read returns `NOT CONNECTED`, say "This is where I'd pull [household]'s last meeting notes and action items from [system], but it isn't connected in this session," and put that sentence, with a "— pending [system]" marker, where the Since We Last Met content would go. Then carry on to Steps 2–4 and write the brief (Step 7) with the section in that state. Offer to connect it, or ask the advisor to summarize the last meeting manually, *after* the file is written, not before — a brief with one pending section is the deliverable, while a question with no brief behind it is a stall, and in a single exchange the advisor may never see a file at all. If they've already handed you a summary or their own notes, that is the section's source: build the recap from it and write.

## Step 2: The Estate Plan — What It Intends (the estate platform, for example Wealth.com)

Pull the household's estate plan from the estate platform (Wealth.com). What the plan intends comes from the plan as the source reports it — never from what a plan of that kind usually says:
- Plan structure: trusts (name, type — e.g., revocable living trust, ILIT — and what each is supposed to hold), and who the plan says inherits what
- Key documents (will, trust agreements, powers of attorney, healthcare directives) — and for each, **whether it is actually signed and executed, not merely on file**. Take each document's status from the document inventory as the source reports it; never infer execution status from the document's type or its presence in the file.
- Document-internal problems that keep a document from doing its job — not executed, unsigned, missing pages. These are the estate insights Wealth.com records per document; present them as observations to discuss, not as findings or a legal review, and note that they can change as documents are re-examined.
- The balance sheet: each major asset or account, how it is owned and who it pays on death, as the estate platform has it on file. That is the record as it stands, not the plan's intent: it can stand in for the custodian on Step 4's actual side, and intent comes from the plan structure above.

> **Connector Placeholder Convention:** if the estate-plan read returns `NOT CONNECTED`, say: *"This is where I'd pull [household]'s estate plan from Wealth.com, but it isn't connected in this session."* Then offer the fallback: connecting it, or the advisor can paste or upload a trust/estate summary (e.g., a trust schedule of assets, attorney letter, or their own notes on what the plan intends). Don't wait for it — write the brief with this section marked "— pending estate documents" rather than guessing at what the plan says, and fold in anything they provide afterwards as a fresh pass.

## Step 3: Prior-Year Tax Look-Back (the estate platform, for example Wealth.com)

Pull the household's most recent filed tax year and the tax law that applies to it:

- **Look-back report** — the filed year's actuals: filing status, AGI, taxable income, federal and state income tax, capital gains, dividends, and deductions. Report every effective rate together with the tax dollars and the income amount behind it, so the advisor can reproduce the arithmetic — never a bare percentage.
- **Year-specific tax constants** — the federal and state bracket tables for that year, and any other constant the report carries for it, such as a standard deduction or capital-gains breakpoints.

**This read is time-bounded**, so the dispatch tells its extractor the window as well as the schema: the household's most recent filed tax year, and that same year for the constants. If the advisor named a year, hand that year instead.

**Cite, never compute.** Every figure here is reported by the source system for the applicable tax year — attribute it to the return or report section an advisor would recognize ("the 2024 federal return shows"). Never recompute, estimate, or fill in a constant Claude wasn't given. If a constant for a future year comes back **projected** rather than published, say so explicitly wherever it appears.

The look-back report covers **filed tax returns only** — it does not exist for a trust, will, or any other estate document, so don't ask for one against those.

Keep this section's job narrow: it is context the advisor brings into the estate conversation (what the household's tax picture actually looked like), not a tax plan or a recommendation. Tax strategy is out of scope — see Out of Scope.

> **Connector Placeholder Convention:** if the tax look-back read returns `NOT CONNECTED`, say: *"This is where I'd pull [household]'s prior-year tax look-back and the year's tax constants from Wealth.com, but it isn't connected in this session."* Then offer the fallback: connecting it, or the advisor can paste or upload a prior-year return or tax summary. Don't wait for it — write the brief with this section marked "— pending tax documents" rather than estimating it, and fold in anything they provide afterwards.

## Step 4: The Accounts — What They Actually Show (the custodian, portfolio and alts platforms)

Pull the household's actual titling and beneficiary data from wherever it lives. An account's actual titling or beneficiary is what a system returned or the advisor supplied — never inferred from the account type, the plan's intent, or another account:
- **The custodian**: each account's actual registration/titling (individual, joint, IRA/Roth, trust — and if trust, which one) and named beneficiary(ies) on file. Where no custodian connector is live, take that account's titling and beneficiaries from the portfolio or alts platform below, the estate platform's balance sheet (Step 2), or the advisor — and attribute each value to whichever of them returned it. A value standing in for the custodian is reported as that platform's own, never as the custodian's record.
- **The portfolio platform** (for example Orion Connect or Addepar): consolidated titling across held-away and multi-custodian accounts, beyond what any single custodian shows
- **The alts platform** (for example CAIS or iCapital): titling and beneficiary on alternative investment positions — these are often held in a different entity or trust than the liquid book, so don't assume they match

The Convention turns on the data, not on the source list: where one of these is unavailable but another returned that account's titling and beneficiary, the brief carries the value with its source named, not a pending marker. Where **none** of them returned it and the advisor has not supplied it, follow the same **Connector Placeholder Convention** as Step 2: say where the data would come from, offer the manual fallback (paste or upload the household's account list/titling), and continue to the brief without waiting — the comparison table carries "— pending [custodian]" for that account's rows.

The custodian, the portfolio platform, and the alts platform can each report titling or a beneficiary for the same account. If two of them disagree with each other about what's actually on file for a given account — not the Step 5 comparison against what the plan intends, but the systems contradicting each other about present-day fact — that's a material conflict: stop and surface it to the advisor as a blocking question rather than picking one silently or footnoting the discrepancy. Two of them agreeing about an account is a cross-check; one of them standing in for another is not — where only one system reported, carry its name in that account's **Actual titling / beneficiary** cell alongside the value, and don't present the value as confirmed.

Cross-system titling and beneficiary mismatches are **this skill's job** — distinct from the per-document insights in Step 2, which are internal to a single document. Keep the two separate in the brief: a document that is unsigned is a Step 2 observation; an account titled against what the plan intends is a Step 5 comparison.

## Step 5: Compare

Dispatch this to the `claude-for-financial-advisors:titling-compare` subagent — `Agent(claude-for-financial-advisors:titling-compare)`, in the foreground (`run_in_background: false`) so what it returns arrives as the call's result inside this turn — handing it Step 2's plan structure as **intended** and the Step 4 output as **actual**. It returns the comparison table, mismatches assigned to the High/Medium/Low tiers by the definitions in Step 6, and — the part that is easy to lose doing this inline — the intended items with no matching account at all, which is how an unfunded trust shows up. If the dispatch errors, is refused because the concurrent-subagent limit is reached, or hasn't come back by the time you would otherwise end your turn, run the comparison yourself, by hand, as below — never end your turn with it outstanding.

It categorizes but does not order within a tier; Step 6's ranking by dollar size and consequence is yours. It also never states that a mismatch is legally deficient or suggests a fix, which is the same boundary this skill has.

The comparison it runs, and the one to run by hand if the subagent is unavailable — for each account and position, check it against what the estate plan intends:
- **Titling match?** Is the account titled the way the plan calls for (e.g., plan says "held in the Smith Family Trust," but the account is still titled individually)?
- **Beneficiary match?** Does the named beneficiary line up with the plan's intent (e.g., an ex-spouse still listed, a minor named directly with no trust/UTMA wrapper, no beneficiary on file at all where one is expected)?

## Step 6: Flags — Prioritized

Surface what needs the advisor's attention, ranked so the highest-consequence items are seen first — this is the point of the brief:

- **High** — an unfunded trust holding (or meant to hold) a meaningful share of the estate, or a beneficiary conflict that would actively misdirect an asset (an ex-spouse still on file, a minor named with no trust/UTMA wrapper). These fail silently and are the most consequential.
- **Medium** — titling mismatches that don't misdirect an asset outright but keep the plan from functioning as intended (partial trust funding, wrong account type).
- **Low** — missing beneficiary designations where a plan default/contingent structure still applies, or minor documentation gaps.

Use judgment on dollar size and consequence within each tier — a $50k titling gap and a $5M unfunded trust are both "High" by category but the advisor should see the larger one first. If a comparison can't be made because Step 2 or Step 4 data is missing for that account/trust, say so explicitly rather than omitting the item silently.

Every flagged mismatch — whatever its tier — ends by recommending that the advisor involve the household's estate attorney before advising the client on next steps, naming the attorney when a source names one. That sentence is what this skill offers instead of a fix, and it matters most on the High flags, where saying what to do is most tempting. The standing note at the top of the brief (Step 7) does not discharge it: a reader who stops at the flag needs to see the referral on the flag.

## Step 7: Output

Write a meeting-ready brief to a markdown file first — and write it whether or not every source was reachable. A section whose source was missing carries its placeholder sentence and its pending marker in place of content; a missing source is never a reason to hold the file. (An unconfirmed identity, a book-of-record question an overlapping read is waiting on, or two systems contradicting each other about present-day fact in Step 4, still is — those are the blocking questions above, and each is asked as soon as it arises, never after the file.) The questions you owe the advisor about what was missing — a manual summary of the last meeting, a document to upload — go in the chat *after* the file exists, not instead of it. The order inside the file, **Executive Summary** first:
1. **Executive Summary** — two or three sentences on the household's overall estate-funding picture, in plain English. This is the same summary the chat reply opens with, not a second one written for chat. It sits above the analysis it summarizes, and it is written from whatever the brief actually holds: a brief assembled around a source that never answered says so here rather than summarizing a picture it couldn't see. **The standing not-legal-advice note goes directly above it** — that note frames everything under it, the summary included, so nothing but the brief's own title, a prepared-on or confidentiality line, and that note may come before the Executive Summary. No content section may.
2. **Since We Last Met** — the Step 1 recap (what was discussed, what's been actioned)
3. **Document status** — key estate documents and whether each is signed/executed, with any document-internal observations from Step 2
4. **Prior-year tax look-back** — the Step 3 figures, each attributed to the return or report it came from, with rates shown alongside their tax dollars and income basis
5. **Comparison table** — one row per account or position, four columns with these headings in this order: **Account / Position**, **Intended per plan**, **Actual titling / beneficiary**, **Match?**. Keep the headings as written and put nothing between them — the advisor reads this table across households, and the same four columns in the same order is what makes it scannable at a glance. Anything extra, a value or a note, goes after Match?. A cell whose value is unknown is never blank and never guessed: an intended owner or beneficiary the plan didn't supply reads "— pending estate documents", an actual titling or beneficiary no system returned reads "— pending [system]", and **Match?** on a row with either side pending reads "can't compare — [the side that's missing]", never "Yes" or "No".
6. **Flags** — the Step 6 list, sorted by priority

**Where a source said where its answer came from, the brief keeps it**, so the advisor, or anyone reviewing the brief, can check a value against the system that gave it. A citation a read returned after a value stays beside that value, or in a numbered note under the table that the value points to, and is never moved to another value or dropped. It always names the system it came from and keeps its citation id and page, so a reader can tell which system to check the value against, and where: carry it in the form the read gave it, add the system's name where that form lacks it, and shorten nothing in it but the document's name. Each link a read returned under `sources:` goes whole beside that system's name, in one place: for a system Step 4 reads, the **Actual titling / beneficiary** cell of every row whose value it returned; for any other read (the CRM's recap, the estate plan, the tax look-back), the first line of the section that read fills, which names the system its content came from; and for a read that returned no value, its "Nothing found" sentence or its "— pending [system]" marker. Those are the brief's only places for a link, whatever the read's status: never a list of links of its own, under the table or anywhere else. When the advisor asks to see the source behind a citation a read returned, list `${CLAUDE_PLUGIN_ROOT}/providers/`, and if it holds a folder named for that system, read every file in it and follow what it says about showing a cited source. That is the advisor's request, not a read, and adds nothing to the brief. With no such folder, or nothing in it about showing a source, say you can't open the source from here, and give the citation and the link as the brief carries them.

Estate, beneficiary, and meeting-note data is confidential: the brief carries what this review needs and nothing more. **The brief itself must carry the not-legal-advice language** — it leaves this session as a file that other people may read without the surrounding conversation, so the framing has to travel with it. Include a short standing note near the top, in plain English rather than legalese: this is a summary prepared to support the advisor's review, it flags items to discuss with the household's estate attorney, and it is not legal advice or a legal review of the plan. Say the same about the document observations wherever they appear — they are points to raise, not conclusions about whether the plan is sound.

**Summary-First Convention:** the chat after the file **opens with the same Executive Summary that opens the brief** — the same sentences, not a second summary written for chat — and then closes. The comparison table and the flags stay in the file; don't walk the advisor through what they can read.

That close is one short set, and it always carries three things, with nothing between them:

- **Two to four directions to go deeper**, named plainly. **Only offer what this run can actually deliver:** a document the estate platform never returned is not an observation to go deeper into, and the Step 8 CRM follow-ups are a direction only where a CRM was actually reached — where it wasn't, they are not on the menu at all rather than offered and then withdrawn. **Where a brief was written around sources that never answered, the set is shorter rather than padded**: two directions is a floor for a run that reached something, never a quota met by naming a direction that leads nowhere. A brief with nothing to go deeper into offers the manual fallback this step already owes and stops there.
- **The format question** — would they like it converted to .docx or .pdf (don't create either unless they ask; markdown is the first-pass deliverable, and the heavy formats are materially slower, so they are produced only on request).
- **The questions you owe about what was missing**, from this step's opening paragraph.

Ask all three. A close that asks for the manual recap and drops the format question is a miss the advisor won't notice, because they don't know it was owed.

## Step 8: Write Follow-Ups Back to the CRM

Draft a CRM task for each flag the brief surfaced (description, priority, suggested owner — advisor or the household's estate attorney) and show the full draft list to the advisor before creating anything.

Only create the tasks the advisor approves (all, some, or edited), in the CRM Step 1 read from — the one the advisor named as book of record, if more than one was connected (Data Gathering). Confirm back with a short summary of what was written.

## Out of Scope

- **No legal advice or legal conclusions.** This skill flags discrepancies for the advisor (and, where appropriate, the household's estate attorney) to evaluate — it never states that a mismatch is legally deficient or recommends a specific fix.
- **No drafting.** Never draft or amend trust language, beneficiary forms, or other estate documents.
- **No tax advice or tax strategy.** The prior-year look-back is reported context, not a plan — this skill never recommends a conversion, harvest, gifting move, or filing position, and never recomputes a figure the source system reports.
- **No account writes.** This skill never retitles an account or changes a beneficiary designation — any fix happens through the advisor's normal custodian/CRM workflow. The only write this skill performs is creating advisor-approved follow-up tasks in the CRM (Step 8).

## Important Notes

- **Every CRM write pauses for advisor approval.** Never create a follow-up task the advisor hasn't seen and confirmed (Step 8).
- Never fabricate what an estate plan says, whether a document is signed, what an account's actual titling/beneficiary is, what a prior year's return reported, or what happened in a prior meeting. Missing data is "— pending [connector/documents]," not a guess (Steps 1–4 and the Step 7 comparison table).
- Recommend the advisor involve the household's estate attorney for any flagged mismatch before advising the client on next steps — Step 6 puts that sentence on each flag.
- **Lead the chat response with the brief's Executive Summary**, then offer two to four directions this run can actually deliver — the table and the flags stay in the file (Step 7).
- Treat estate, beneficiary, and meeting-note data as confidential; only include what's needed for this review (Step 7).

This list is a summary; each rule is stated in the step it governs.