Бриф по наследству и налогам

Сверяет наследственный план клиента с тем, как оформлены его счета и бенефициары, и готовит бриф с приоритетными отметками для встречи.

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Сверяет наследственный план клиента с тем, как оформлены его счета и бенефициары, и готовит бриф с приоритетными отметками для встречи.
Когда брать: Перед встречей по наследственному плану: чтобы проверить, наполнены ли трасты активами, подписаны ли документы и актуальны ли бенефициары.
Когда не брать: Не даёт юридических и налоговых советов, не пишет документы, не переоформляет счета и не меняет бенефициаров.
Пример запроса: Подготовь бриф по наследству и налогам семьи Смитов: соответствуют ли их счета наследственному плану?
Нужно подключить: Wealth.com, CRM (Wealthbox, Redtail или Salesforce)
Работает лучше с: Schwab, Orion Connect или Addepar, iCapital

Входит в плагин claude-for-financial-advisors. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Нажмите «Скачать на русском» и сохраните архив.
В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
Включите скилл переключателем.

Для терминала

Распакуйте архив и положите папку estate-and-tax-brief в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: estate-and-tax-brief
description: Готовит для домохозяйства бриф по наследственному плану и налогам, с которым можно идти на встречу. Открывается тем, что обсуждали и сделали с прошлой встречи (Wealthbox, Redtail, Salesforce), затем берёт из Wealth.com наследственный план (структура, ключевые документы и подписан ли каждый, баланс), налоговую ретроспективу за прошлый год и налоговые константы этого года и сверяет их с тем, как счета оформлены и на кого записаны бенефициары у кастодиана и в портфельных платформах (Schwab, Orion/Addepar, iCapital). Находит не наполненные активами трасты, расхождения в оформлении и пробелы по бенефициарам и выводит их в виде списка отметок по приоритету. Единственная запись — создание в CRM утверждённых советником задач (необязательно, сначала утверждение). Никогда не пишет текст траста, не даёт юридических советов, не переоформляет счёт и не меняет бенефициара. Срабатывает на «бриф по наследству», «бриф к встрече по наследственному плану», «бриф по наследству и налогам», «обзор наследственного плана для [клиент]», «проверь, как наполнен траст у [клиент]», «актуальны ли бенефициары у [клиент]» или «соответствует ли наследственный план [клиент] его счетам».
---

Бриф по наследству и налогам

Дай советнику ясное и готовое к встрече представление о том, действительно ли счета домохозяйства оформлены так, как задумано в его наследственном плане. Расхождение между «что говорят документы» и «что показывают счета» — то место, где наследственные планы тихо срываются, часто незаметно, пока исправлять поздно. Бриф начинается с того, что уже обсуждалось, чтобы встреча не топталась на старом, и замыкает цикл: утверждённые отметки превращаются в отслеживаемые задачи в CRM.

Входные данные

Обязательно: имя домохозяйства. Если его нет, спроси, прежде чем делать что-либо ещё.

Правило однозначности: подтверди домохозяйство, прежде чем что-либо вытягивать, как и в любом другом скилле этого плагина. Если имени соответствует несколько домохозяйств, покажи кандидатов и спроси, о каком речь, прежде чем продолжать.

Когда личность подтверждена, собирай данные из всех подключённых источников параллельно (шаги 1–4): один медленный или отсутствующий источник ухудшает только свой раздел брифа, а не остальные. Перед началом такой выгрузки из нескольких источников скажи советнику, что собираешься получить и зачем, чтобы долгая выгрузка не выглядела как молчаливое зависание. И когда домохозяйство известно, не спрашивай «начинать?», а рассказывай, что делаешь, и делай: подтверждения в этом скилле нужны для записей в CRM на шаге 8 и для любого преобразования формата в конце, а не для разрешения начать.

Сбор данных: шаги 1–4 идут одновременно

Четыре чтения ниже обращаются к разным системам или к разным отчётам одной системы и не делят состояния. **Запусти их как субагентов claude-for-financial-advisors:source-extract одним сообщением**: по одному вызову Agent(claude-for-financial-advisors:source-extract) на чтение, все в одном ответе. Один для CRM, один для наследственного плана в Wealth.com, один для налоговой ретроспективы в Wealth.com и по одному для каждой подключённой платформы кастодиана или портфеля из шага 4. Каждому передай личность домохозяйства в том виде, в каком она у тебя есть, единственную систему, к которой этот субагент должен обратиться, схему полей под заголовком его шага и период, если чтение ограничено по времени.

Каждый возвращает заполненный блок по схеме. Сопоставлению на шаге 5 нужны обе стороны как сырые нормализованные списки, поэтому субагентам велено ничего не интерпретировать, не сопоставлять и не отмечать: это опередило бы сопоставление чтением, которое ты не можешь проверить.

Идентификация остаётся за тобой, согласно правилу однозначности выше. claude-for-financial-advisors:source-extract никогда не определяет домохозяйство: ответ IDENTITY MISMATCH приходит с кандидатами. Покажи их советнику и запусти заново только это одно чтение, когда он подтвердит, какое домохозяйство верное. Это единственный ответ, при котором повторный запуск уместен. Ответ NOT CONNECTED — случай правила заглушки коннектора (Connector Placeholder Convention): ручной запасной вариант предлагаешь ты, а не субагент, и этот ответ никогда не повторяется повторным запуском того же извлекателя. Эти четыре чтения запускаются одним сообщением, и источник, недоступный в момент запуска, не становится доступным оттого, что то же чтение запустили ещё раз: второй запуск вернёт NOT CONNECTED снова за ту же цену. Если советник подключит этот источник позже в разговоре, это новый запрос, а не повтор. То же, если в одном из чтений ниже эту задачу для этого домохозяйства могут решить несколько подключённых инструментов (необязательно двое одного вида): один раз спроси советника, какой из них считать основным учётным (book of record), по правилу «Спроси один раз, дальше маршрутизируй» (Ask-Once, Then Route Convention), а не угадывай, и предложи помочь сохранить выбор по правилу персонализации (Personalization Convention). Это не одноразовая проверка в начале: источник, который советник упомянул по ходу сбора (заметка в CRM, внешний документ), тоже считается, и ему задаётся тот же вопрос до объединения с остальным. А если две системы всё же были запрошены и вернули одно и то же домохозяйство с цифрами, различающимися на порядки, следуй правилу конфликта порядков величины (Magnitude-Conflict Convention): назови конфликт и исключи цифры выбивающегося значения из всех таблиц и итогов, а не цитируй их как подтверждение.

Шаг 1: С прошлой встречи — контекст из CRM

Запроси в CRM домохозяйства самые свежие заметки о встречах и открытые задачи, связанные с наследственным планом (передача активов в траст, оформление счетов, назначение бенефициаров). Запрашивай на обоих уровнях: собственные заметки, задачи и события записи самого домохозяйства и записи каждого контакта-человека. В Wealthbox домохозяйство само является контактом со своим id (те же вызовы списков работают по нему), а пункты по наследству обычно привязаны к записи домохозяйства, а не к кому-то из супругов, поэтому поиск только по контактам молча их пропустит.

По каждому пункту отметь, что с ним сделано: сделано, не сделано или нет обновлений с момента записи. Отметка стоит рядом с пунктом в самом разделе, так что каждая задача несёт собственный статус. Одна строка в конце о том, что обновлений нет, этим не является: советник читает список пункт за пунктом, и «нет обновлений» — это статус, который каждый пункт получает на своей строке. Это становится открывающим разделом брифа, чтобы советник сразу видел, что изменилось (или нет), прежде чем погружаться в текущее сопоставление.

Правило заглушки коннектора (Connector Placeholder Convention): если инструментов CRM в этой сессии нет, скажи: «Здесь я бы достал последние заметки о встречах и задачи домохозяйства [домохозяйство] из [система], когда этот коннектор будет готов», и поставь это предложение с пометкой «— ожидает [система]» туда, где было бы содержание раздела «С прошлой встречи». Затем переходи к шагам 2–4 и пиши бриф (шаг 7) с разделом в таком состоянии. Проси советника пересказать прошлую встречу вручную *после* записи файла, а не до: бриф с одним раздел-заглушкой — это результат, а вопрос без брифа за ним — остановка, и за один обмен репликами советник может так и не увидеть файл. Если он уже дал резюме или свои заметки, они и есть источник раздела: построй по ним пересказ и пиши.

Шаг 2: Наследственный план — что он предусматривает (Wealth.com)

Достань из Wealth.com наследственный план домохозяйства:

Структура плана: трасты (название, тип, например отзывный траст при жизни (revocable living trust) или необратимый страховой траст (ILIT), и что каждый должен содержать)
Ключевые документы (завещание, соглашения о трасте, доверенности, медицинские распоряжения) и по каждому — действительно ли он подписан и оформлен, а не просто лежит в деле. Статус каждого документа бери из описи документов в том виде, как его сообщает источник; никогда не выводи статус оформления из типа документа или из его присутствия в деле.
Проблемы внутри документов, которые мешают документу выполнять свою задачу: не оформлен, не подписан, не хватает страниц. Это наследственные наблюдения (estate insights), которые Wealth.com записывает по каждому документу; подавай их как замечания для обсуждения, а не как выводы или юридическую проверку, и отмечай, что они могут измениться при повторном рассмотрении документов.
Баланс плана: предусмотренный владелец или бенефициар для каждого крупного актива или счёта

Правило заглушки коннектора (Connector Placeholder Convention): если коннектора Wealth.com в этой сессии нет, скажи: *«Здесь я бы достал наследственный план домохозяйства [домохозяйство] из Wealth.com, когда этот коннектор будет готов».* Затем предложи запасной вариант: советник может вставить или загрузить сводку по трасту или наследству (например, перечень активов траста, письмо юриста или собственные заметки о том, что предусматривает план). Не жди этого: пиши бриф, пометив этот раздел «— ожидает наследственных документов», а не угадывай, что говорит план, и включай всё, что советник предоставит потом, новым проходом.

Шаг 3: Налоговая ретроспектива за прошлый год (Wealth.com)

Достань последний поданный налоговый год домохозяйства и налоговое право, которое к нему применяется:

Отчёт-ретроспектива — фактические данные поданного года: статус подачи, AGI, налогооблагаемый доход, федеральный налог и налог штата на доход, прирост капитала, дивиденды и вычеты. Приводи каждую эффективную ставку вместе с суммой налога и суммой дохода, на которых она основана, чтобы советник мог воспроизвести расчёт, а не голый процент.
Налоговые константы года — ставки, стандартный вычет, пороги по приросту капитала и подобные цифры за соответствующий год, чтобы оценить, на что наткнутся следующие шаги плана.

Это чтение ограничено по времени, поэтому в запросе извлекателю указывается и окно, и схема: последний поданный налоговый год домохозяйства и этот же год для констант. Если советник назвал год, передай этот год.

Цитируй, никогда не считай. Каждая цифра здесь сообщена системой-источником за применимый налоговый год: приписывай её разделу декларации или отчёта, который советник узнает («по федеральной декларации за 2024 год»). Никогда не пересчитывай, не оценивай и не придумывай константу, которую Claude не дали. Если константа на будущий год пришла как прогнозная, а не опубликованная, прямо скажи об этом везде, где она встречается.

Отчёт-ретроспектива охватывает только поданные налоговые декларации: для траста, завещания и любого другого наследственного документа его не существует, поэтому не запрашивай его по ним.

Держи задачу раздела узкой: это контекст, который советник приносит в разговор о наследстве (как на самом деле выглядела налоговая картина домохозяйства), а не налоговый план и не рекомендация. Налоговая стратегия вне рамок, см. «Вне рамок».

Правило заглушки коннектора (Connector Placeholder Convention): если коннектора Wealth.com в этой сессии нет, скажи: *«Здесь я бы достал налоговую ретроспективу домохозяйства [домохозяйство] за прошлый год и налоговые константы этого года из Wealth.com, когда этот коннектор будет готов».* Затем предложи запасной вариант: советник может вставить или загрузить декларацию за прошлый год или налоговую сводку. Не жди этого: пиши бриф, пометив этот раздел «— ожидает налоговых документов», а не оценивай его, и включай всё, что советник предоставит потом.

Шаг 4: Счета — что они показывают на самом деле (Schwab, Orion/Addepar, iCapital)

Достань фактические данные об оформлении и бенефициарах из того места, где они лежат:

Schwab (кастодиан): фактическая регистрация или оформление каждого счёта (индивидуальный, совместный, IRA/Roth, траст, а если траст, то какой) и указанные в деле бенефициары
Orion Connect или Addepar (портфельная платформа): сводное оформление по счетам, находящимся вне кастодиана, и по счетам у нескольких кастодианов, сверх того, что показывает один Schwab
iCapital: оформление и бенефициары по позициям в альтернативных инвестициях; они часто лежат на другом юрлице или трасте, чем ликвидный портфель, поэтому не предполагай, что они совпадают

Для любой недоступной платформы следуй тому же правилу заглушки коннектора (Connector Placeholder Convention), что и на шаге 2: скажи, откуда пришли бы данные, предложи ручной запасной вариант (вставить или загрузить список счетов домохозяйства с оформлением) и переходи к брифу, не дожидаясь. В таблице сопоставления строки этого счёта несут «— ожидает [кастодиан]».

Кастодиан, портфельная платформа и платформа альтернатив могут каждая сообщать оформление или бенефициара для одного и того же счёта. Если две из них противоречат друг другу в том, что фактически записано по данному счёту (это не сопоставление шага 5 с тем, что предусматривает план, а противоречие систем друг с другом о сегодняшнем факте), это существенный конфликт: останови работу и выведи его советнику как блокирующий вопрос, а не выбирай молча одно значение и не сноси расхождение в сноску.

Расхождения в оформлении и бенефициарах между системами — задача этого скилла, отличная от замечаний по отдельным документам на шаге 2, которые относятся к одному документу. Держи эти две вещи в брифе раздельно: неподписанный документ — наблюдение шага 2; счёт, оформленный не так, как предусматривает план, — сопоставление шага 5.

Шаг 5: Сопоставь

Передай это субагенту claude-for-financial-advisors:titling-compare, то есть Agent(claude-for-financial-advisors:titling-compare), отдав ему результат шага 2 как предусмотренное и результат шага 4 как фактическое. Он вернёт таблицу сопоставления, расхождения, отнесённые к уровням «Высокий / Средний / Низкий» по определениям из шага 6, и — то, что легко потерять при работе без него — предусмотренные пункты, для которых нет подходящего счёта вообще: так проявляется не наполненный активами траст.

Он распределяет по категориям, но не упорядочивает внутри уровня: ранжирование по размеру суммы и последствиям на шаге 6 за тобой. Он также никогда не заявляет, что расхождение юридически несостоятельно, и не предлагает исправления, то есть держит ту же границу, что и этот скилл.

Сопоставление, которое он проводит и которое нужно провести вручную, если субагент недоступен: по каждому счёту и позиции проверь их на соответствие тому, что предусматривает наследственный план:

Оформление совпадает? Оформлен ли счёт так, как требует план (например, в плане сказано «на счёте семейного траста Смитов», а счёт всё ещё оформлен на частное лицо)?
Бенефициар совпадает? Соответствует ли указанный бенефициар замыслу плана (например, в деле всё ещё бывший супруг, несовершеннолетний указан напрямую без оболочки траста или UTMA, там, где бенефициар ожидается, его нет вовсе)?

Шаг 6: Отметки по приоритету

Выведи то, что требует внимания советника, расположив так, чтобы самые значимые по последствиям пункты были видны первыми: в этом смысл брифа.

Высокий — не наполненный активами траст, который содержит (или должен содержать) заметную часть имущества, либо конфликт бенефициаров, который прямо направит актив не туда (в деле всё ещё бывший супруг, несовершеннолетний указан без оболочки траста или UTMA). Такие ошибки срабатывают молча и наиболее значимы.
Средний — расхождения в оформлении, которые не направляют актив не туда напрямую, но мешают плану работать как задумано (частичное наполнение траста, неверный тип счёта).
Низкий — отсутствующие назначения бенефициаров там, где всё ещё действует структура плана по умолчанию или резервная, либо мелкие пробелы в документации.

Внутри каждого уровня опирайся на суждение о размере суммы и последствиях: пробел в оформлении на 50 тыс. $ и не наполненный активами траст на 5 млн $ оба «Высокие» по категории, но советник должен увидеть крупный первым. Если сопоставление невозможно, потому что не хватает данных шага 2 или шага 4 по этому счёту или тресту, прямо скажи об этом, а не пропускай пункт молча.

Каждое отмеченное расхождение, какого бы уровня оно ни было, заканчивается рекомендацией, чтобы советник привлёк юриста домохозяйства по наследственным вопросам, прежде чем советовать клиенту следующие шаги; назови юриста, если его называет источник. Это предложение — то, что скилл предлагает вместо исправления, и важнее всего оно на Высоких отметках, где сильнее всего хочется сказать, что делать. Постоянная пометка в начале брифа (шаг 7) его не заменяет: читатель, остановившийся на отметке, должен увидеть отсылку к юристу на самой отметке.

Шаг 7: Результат

Сначала запиши бриф, готовый к встрече, в файл markdown, и пиши его независимо от того, были ли доступны все источники. Раздел, источника которого не было, несёт вместо содержания предложение-заглушку и пометку об ожидании: недоступный источник никогда не повод задерживать файл. (Неподтверждённая личность или противоречие двух систем о сегодняшнем факте на шаге 4 — повод, и это блокирующие вопросы выше, которые задаются до выгрузки, а не после файла.) Вопросы к советнику о том, чего не хватало (ручной пересказ прошлой встречи, документ для загрузки), идут в чат *после* появления файла, а не вместо него. Порядок внутри файла:

С прошлой встречи — пересказ шага 1 (что обсуждали, что сделано)
Статус документов — ключевые наследственные документы и подписан ли каждый, с замечаниями по документам из шага 2
Налоговая ретроспектива за прошлый год — цифры шага 3, каждая с указанием декларации или отчёта, откуда она взята, а ставки показаны рядом с суммой налога и базой дохода
Таблица сопоставления — одна строка на счёт или позицию, четыре столбца с этими заголовками в этом порядке: Счёт / позиция, Предусмотрено планом, Фактическое оформление / бенефициар, Совпадает?. Сохраняй заголовки как написано и ничего не вставляй между ними: советник читает эту таблицу по разным домохозяйствам, и одни и те же четыре столбца в одном порядке делают её сканируемой с первого взгляда. Всё лишнее, значение или примечание, идёт после «Совпадает?».
Отметки — список шага 6, отсортированный по приоритету
Резюме из 2–3 предложений простым языком о том, как обстоит дело с наполнением плана активами у домохозяйства

Сам бриф обязан нести оговорку, что это не юридическая консультация: он выйдет за пределы этой сессии как файл, который другие люди могут читать без окружающего разговора, поэтому рамка должна идти вместе с ним. Вставь короткую постоянную пометку ближе к началу, простым языком, а не юридическим: это сводка, подготовленная в поддержку проверки советника, она отмечает пункты для обсуждения с юристом домохозяйства по наследственным вопросам и не является юридической консультацией или юридической проверкой плана. Скажи то же о наблюдениях по документам везде, где они встречаются: это вопросы, которые нужно поднять, а не выводы о том, надёжен ли план.

Чат после файла — одно короткое завершение, и в нём всегда две вещи: вопрос о формате — нужно ли преобразовать в .docx или .pdf (не создавай ни тот ни другой, пока не попросят; markdown — результат первого прохода, а тяжёлые форматы делаются заметно дольше, поэтому создаются только по запросу) — и вопросы о том, чего не хватало, из первого абзаца этого шага. Задай оба. Завершение, которое просит ручной пересказ и опускает вопрос о формате, — промах, который советник не заметит, потому что не знает, что вопрос был нужен.

Шаг 8: Запиши последующие задачи в CRM

Составь задачу в CRM на каждую отметку, выведенную в брифе (описание, приоритет, предлагаемый ответственный: советник или юрист домохозяйства по наследственным вопросам), и покажи советнику полный черновик списка, прежде чем что-либо создавать.

Создавай только те задачи, которые советник утвердит (все, часть или отредактированные), в той CRM, которая определена как основная учётная на шаге 1. Коротко подтверди, что было записано.

Вне рамок (пока)

Никаких юридических советов и юридических выводов. Скилл отмечает расхождения, чтобы их оценил советник (а где уместно, юрист домохозяйства по наследственным вопросам); он никогда не заявляет, что расхождение юридически несостоятельно, и не рекомендует конкретное исправление.
Никаких черновиков документов. Никогда не составляй и не изменяй текст траста, формы бенефициаров и другие наследственные документы.
Никаких налоговых советов и налоговой стратегии. Ретроспектива за прошлый год — сообщаемый контекст, а не план: скилл никогда не рекомендует конверсию, реализацию убытков (harvest), дарение или позицию при подаче и никогда не пересчитывает цифру, которую сообщает система-источник.
Никаких записей по счетам. Скилл никогда не переоформляет счёт и не меняет назначение бенефициара: любое исправление идёт через обычный процесс советника у кастодиана или в CRM. Единственная запись, которую делает скилл, — создание утверждённых советником последующих задач в CRM (шаг 8).

Важные замечания

Каждая запись в CRM ждёт утверждения советника. Никогда не создавай последующую задачу, которой советник не видел и не подтвердил.
Никогда не выдумывай, что говорит наследственный план, подписан ли документ, каково фактическое оформление или бенефициар счёта, что сообщила декларация прошлого года и что было на прошлой встрече. Отсутствующие данные — это «— ожидает [коннектор / документы]», а не догадка.
Рекомендуй советнику привлекать юриста домохозяйства по наследственным вопросам при любом отмеченном расхождении, прежде чем советовать клиенту следующие шаги: шаг 6 ставит это предложение на каждую отметку.
Считай данные о наследстве, бенефициарах и заметках о встречах конфиденциальными; включай только то, что нужно для этого разбора.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-for-financial-advisors/tree/main/skills/estate-and-tax-brief, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
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 diving into the current comparison.

> **Connector Placeholder Convention:** if the CRM's tools aren't available in this session, say "This is where I'd pull [household]'s last meeting notes and action items from [system] once that connector is built," 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. 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 (Wealth.com)

Pull the household's estate plan from Wealth.com:
- Plan structure: trusts (name, type — e.g., revocable living trust, ILIT — and what each is supposed to hold)
- 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 plan's balance sheet: intended owner/beneficiary for each major asset or account

> **Connector Placeholder Convention:** if the Wealth.com connector isn't available in this session, say: *"This is where I'd pull [household]'s estate plan from Wealth.com once that connector is built."* Then offer the fallback: 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 (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 brackets, standard deduction, capital-gains breakpoints, and similar figures for the relevant year, to size what the plan's next moves run into.

**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 Wealth.com connector isn't available in this session, say: *"This is where I'd pull [household]'s prior-year tax look-back and the year's tax constants from Wealth.com once that connector is built."* Then offer the fallback: 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 (Schwab, Orion/Addepar, iCapital)

Pull the household's actual titling and beneficiary data from wherever it lives:
- **Schwab** (custodian): each account's actual registration/titling (individual, joint, IRA/Roth, trust — and if trust, which one) and named beneficiary(ies) on file
- **Orion Connect or Addepar** (portfolio platform): consolidated titling across held-away and multi-custodian accounts beyond what Schwab alone shows
- **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

Follow the same **Connector Placeholder Convention** as Step 2 for any that isn't available: 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.

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)` — handing it the Step 2 output 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.

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, or two systems contradicting each other about present-day fact in Step 4, still is — those are the blocking questions above, and they are asked before the pull, not 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:
1. **Since We Last Met** — the Step 1 recap (what was discussed, what's been actioned)
2. **Document status** — key estate documents and whether each is signed/executed, with any document-internal observations from Step 2
3. **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
4. **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?.
5. **Flags** — the Step 6 list, sorted by priority
6. A 2-3 sentence plain-English summary of the household's estate-funding picture

**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.

The chat after the file is one short close, and it always carries two things: 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) — and the questions you owe about what was missing, from this step's opening paragraph. Ask both. 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 identified as the book of record in Step 1. Confirm back with a short summary of what was written.

## Out of Scope (for now)

- **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.
- 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.
- 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.
- Treat estate, beneficiary, and meeting-note data as confidential; only include what's needed for this review.

Источник: anthropics/claude-for-financial-advisors / claude-for-financial-advisors / estate-and-tax-brief ↗. Ссылка проверена 2026-10-10.

---
name: estate-and-tax-brief
description: Готовит для домохозяйства бриф по наследственному плану и налогам, с которым можно идти на встречу. Открывается тем, что обсуждали и сделали с прошлой встречи (Wealthbox, Redtail, Salesforce), затем берёт из Wealth.com наследственный план (структура, ключевые документы и подписан ли каждый, баланс), налоговую ретроспективу за прошлый год и налоговые константы этого года и сверяет их с тем, как счета оформлены и на кого записаны бенефициары у кастодиана и в портфельных платформах (Schwab, Orion/Addepar, iCapital). Находит не наполненные активами трасты, расхождения в оформлении и пробелы по бенефициарам и выводит их в виде списка отметок по приоритету. Единственная запись — создание в CRM утверждённых советником задач (необязательно, сначала утверждение). Никогда не пишет текст траста, не даёт юридических советов, не переоформляет счёт и не меняет бенефициара. Срабатывает на «бриф по наследству», «бриф к встрече по наследственному плану», «бриф по наследству и налогам», «обзор наследственного плана для [клиент]», «проверь, как наполнен траст у [клиент]», «актуальны ли бенефициары у [клиент]» или «соответствует ли наследственный план [клиент] его счетам».
---

# Бриф по наследству и налогам

Дай советнику ясное и готовое к встрече представление о том, действительно ли счета домохозяйства оформлены так, как задумано в его наследственном плане. Расхождение между «что говорят документы» и «что показывают счета» — то место, где наследственные планы тихо срываются, часто незаметно, пока исправлять поздно. Бриф начинается с того, что уже обсуждалось, чтобы встреча не топталась на старом, и замыкает цикл: утверждённые отметки превращаются в отслеживаемые задачи в CRM.

## Входные данные

Обязательно: **имя домохозяйства**. Если его нет, спроси, прежде чем делать что-либо ещё.

**Правило однозначности:** подтверди домохозяйство, прежде чем что-либо вытягивать, как и в любом другом скилле этого плагина. Если имени соответствует несколько домохозяйств, покажи кандидатов и спроси, о каком речь, прежде чем продолжать.

Когда личность подтверждена, **собирай данные из всех подключённых источников параллельно** (шаги 1–4): один медленный или отсутствующий источник ухудшает только свой раздел брифа, а не остальные. Перед началом такой выгрузки из нескольких источников скажи советнику, что собираешься получить и зачем, чтобы долгая выгрузка не выглядела как молчаливое зависание. И когда домохозяйство известно, не спрашивай «начинать?», а рассказывай, что делаешь, и делай: подтверждения в этом скилле нужны для записей в CRM на шаге 8 и для любого преобразования формата в конце, а не для разрешения начать.

## Сбор данных: шаги 1–4 идут одновременно

Четыре чтения ниже обращаются к разным системам или к разным отчётам одной системы и не делят состояния. **Запусти их как субагентов `claude-for-financial-advisors:source-extract` одним сообщением**: по одному вызову `Agent(claude-for-financial-advisors:source-extract)` на чтение, все в одном ответе. Один для CRM, один для наследственного плана в Wealth.com, один для налоговой ретроспективы в Wealth.com и по одному для каждой подключённой платформы кастодиана или портфеля из шага 4. Каждому передай личность домохозяйства в том виде, в каком она у тебя есть, единственную систему, к которой этот субагент должен обратиться, схему полей под заголовком его шага и период, если чтение ограничено по времени.

Каждый возвращает заполненный блок по схеме. Сопоставлению на шаге 5 нужны обе стороны как сырые нормализованные списки, поэтому субагентам велено ничего не интерпретировать, не сопоставлять и не отмечать: это опередило бы сопоставление чтением, которое ты не можешь проверить.

**Идентификация остаётся за тобой**, согласно правилу однозначности выше. `claude-for-financial-advisors:source-extract` никогда не определяет домохозяйство: ответ `IDENTITY MISMATCH` приходит с кандидатами. Покажи их советнику и запусти заново только это одно чтение, когда он подтвердит, какое домохозяйство верное. Это единственный ответ, при котором повторный запуск уместен. Ответ `NOT CONNECTED` — случай правила заглушки коннектора (Connector Placeholder Convention): ручной запасной вариант предлагаешь ты, а не субагент, и этот ответ никогда не повторяется повторным запуском того же извлекателя. Эти четыре чтения запускаются одним сообщением, и источник, недоступный в момент запуска, не становится доступным оттого, что то же чтение запустили ещё раз: второй запуск вернёт `NOT CONNECTED` снова за ту же цену. Если советник подключит этот источник позже в разговоре, это новый запрос, а не повтор. То же, если в одном из чтений ниже эту задачу для этого домохозяйства могут решить несколько подключённых инструментов (необязательно двое одного вида): один раз спроси советника, какой из них считать основным учётным (book of record), по правилу «Спроси один раз, дальше маршрутизируй» (Ask-Once, Then Route Convention), а не угадывай, и предложи помочь сохранить выбор по правилу персонализации (Personalization Convention). Это не одноразовая проверка в начале: источник, который советник упомянул по ходу сбора (заметка в CRM, внешний документ), тоже считается, и ему задаётся тот же вопрос до объединения с остальным. А если две системы всё же были запрошены и вернули одно и то же домохозяйство с цифрами, различающимися на порядки, следуй правилу конфликта порядков величины (Magnitude-Conflict Convention): назови конфликт и исключи цифры выбивающегося значения из всех таблиц и итогов, а не цитируй их как подтверждение.

## Шаг 1: С прошлой встречи — контекст из CRM

Запроси в CRM домохозяйства самые свежие заметки о встречах и открытые задачи, связанные с наследственным планом (передача активов в траст, оформление счетов, назначение бенефициаров). **Запрашивай на обоих уровнях: собственные заметки, задачи и события записи самого домохозяйства и записи каждого контакта-человека.** В Wealthbox домохозяйство само является контактом со своим id (те же вызовы списков работают по нему), а пункты по наследству обычно привязаны к записи домохозяйства, а не к кому-то из супругов, поэтому поиск только по контактам молча их пропустит.

По каждому пункту отметь, что с ним сделано: сделано, не сделано или нет обновлений с момента записи. Отметка стоит рядом с пунктом в самом разделе, так что каждая задача несёт собственный статус. Одна строка в конце о том, что обновлений нет, этим не является: советник читает список пункт за пунктом, и «нет обновлений» — это статус, который каждый пункт получает на своей строке. Это становится открывающим разделом брифа, чтобы советник сразу видел, что изменилось (или нет), прежде чем погружаться в текущее сопоставление.

> **Правило заглушки коннектора (Connector Placeholder Convention):** если инструментов CRM в этой сессии нет, скажи: «Здесь я бы достал последние заметки о встречах и задачи домохозяйства [домохозяйство] из [система], когда этот коннектор будет готов», и поставь это предложение с пометкой «— ожидает [система]» туда, где было бы содержание раздела «С прошлой встречи». Затем переходи к шагам 2–4 и пиши бриф (шаг 7) с разделом в таком состоянии. Проси советника пересказать прошлую встречу вручную *после* записи файла, а не до: бриф с одним раздел-заглушкой — это результат, а вопрос без брифа за ним — остановка, и за один обмен репликами советник может так и не увидеть файл. Если он уже дал резюме или свои заметки, они и есть источник раздела: построй по ним пересказ и пиши.

## Шаг 2: Наследственный план — что он предусматривает (Wealth.com)

Достань из Wealth.com наследственный план домохозяйства:
- Структура плана: трасты (название, тип, например отзывный траст при жизни (revocable living trust) или необратимый страховой траст (ILIT), и что каждый должен содержать)
- Ключевые документы (завещание, соглашения о трасте, доверенности, медицинские распоряжения) и по каждому — **действительно ли он подписан и оформлен, а не просто лежит в деле**. Статус каждого документа бери из описи документов в том виде, как его сообщает источник; никогда не выводи статус оформления из типа документа или из его присутствия в деле.
- Проблемы внутри документов, которые мешают документу выполнять свою задачу: не оформлен, не подписан, не хватает страниц. Это наследственные наблюдения (estate insights), которые Wealth.com записывает по каждому документу; подавай их как замечания для обсуждения, а не как выводы или юридическую проверку, и отмечай, что они могут измениться при повторном рассмотрении документов.
- Баланс плана: предусмотренный владелец или бенефициар для каждого крупного актива или счёта

> **Правило заглушки коннектора (Connector Placeholder Convention):** если коннектора Wealth.com в этой сессии нет, скажи: *«Здесь я бы достал наследственный план домохозяйства [домохозяйство] из Wealth.com, когда этот коннектор будет готов».* Затем предложи запасной вариант: советник может вставить или загрузить сводку по трасту или наследству (например, перечень активов траста, письмо юриста или собственные заметки о том, что предусматривает план). Не жди этого: пиши бриф, пометив этот раздел «— ожидает наследственных документов», а не угадывай, что говорит план, и включай всё, что советник предоставит потом, новым проходом.

## Шаг 3: Налоговая ретроспектива за прошлый год (Wealth.com)

Достань последний поданный налоговый год домохозяйства и налоговое право, которое к нему применяется:

- **Отчёт-ретроспектива** — фактические данные поданного года: статус подачи, AGI, налогооблагаемый доход, федеральный налог и налог штата на доход, прирост капитала, дивиденды и вычеты. Приводи каждую эффективную ставку вместе с суммой налога и суммой дохода, на которых она основана, чтобы советник мог воспроизвести расчёт, а не голый процент.
- **Налоговые константы года** — ставки, стандартный вычет, пороги по приросту капитала и подобные цифры за соответствующий год, чтобы оценить, на что наткнутся следующие шаги плана.

**Это чтение ограничено по времени**, поэтому в запросе извлекателю указывается и окно, и схема: последний поданный налоговый год домохозяйства и этот же год для констант. Если советник назвал год, передай этот год.

**Цитируй, никогда не считай.** Каждая цифра здесь сообщена системой-источником за применимый налоговый год: приписывай её разделу декларации или отчёта, который советник узнает («по федеральной декларации за 2024 год»). Никогда не пересчитывай, не оценивай и не придумывай константу, которую Claude не дали. Если константа на будущий год пришла как **прогнозная**, а не опубликованная, прямо скажи об этом везде, где она встречается.

Отчёт-ретроспектива охватывает **только поданные налоговые декларации**: для траста, завещания и любого другого наследственного документа его не существует, поэтому не запрашивай его по ним.

Держи задачу раздела узкой: это контекст, который советник приносит в разговор о наследстве (как на самом деле выглядела налоговая картина домохозяйства), а не налоговый план и не рекомендация. Налоговая стратегия вне рамок, см. «Вне рамок».

> **Правило заглушки коннектора (Connector Placeholder Convention):** если коннектора Wealth.com в этой сессии нет, скажи: *«Здесь я бы достал налоговую ретроспективу домохозяйства [домохозяйство] за прошлый год и налоговые константы этого года из Wealth.com, когда этот коннектор будет готов».* Затем предложи запасной вариант: советник может вставить или загрузить декларацию за прошлый год или налоговую сводку. Не жди этого: пиши бриф, пометив этот раздел «— ожидает налоговых документов», а не оценивай его, и включай всё, что советник предоставит потом.

## Шаг 4: Счета — что они показывают на самом деле (Schwab, Orion/Addepar, iCapital)

Достань фактические данные об оформлении и бенефициарах из того места, где они лежат:
- **Schwab** (кастодиан): фактическая регистрация или оформление каждого счёта (индивидуальный, совместный, IRA/Roth, траст, а если траст, то какой) и указанные в деле бенефициары
- **Orion Connect или Addepar** (портфельная платформа): сводное оформление по счетам, находящимся вне кастодиана, и по счетам у нескольких кастодианов, сверх того, что показывает один Schwab
- **iCapital**: оформление и бенефициары по позициям в альтернативных инвестициях; они часто лежат на другом юрлице или трасте, чем ликвидный портфель, поэтому не предполагай, что они совпадают

Для любой недоступной платформы следуй тому же **правилу заглушки коннектора (Connector Placeholder Convention)**, что и на шаге 2: скажи, откуда пришли бы данные, предложи ручной запасной вариант (вставить или загрузить список счетов домохозяйства с оформлением) и переходи к брифу, не дожидаясь. В таблице сопоставления строки этого счёта несут «— ожидает [кастодиан]».

Кастодиан, портфельная платформа и платформа альтернатив могут каждая сообщать оформление или бенефициара для одного и того же счёта. Если две из них противоречат друг другу в том, что фактически записано по данному счёту (это не сопоставление шага 5 с тем, что предусматривает план, а противоречие систем друг с другом о сегодняшнем факте), это существенный конфликт: останови работу и выведи его советнику как блокирующий вопрос, а не выбирай молча одно значение и не сноси расхождение в сноску.

Расхождения в оформлении и бенефициарах между системами — **задача этого скилла**, отличная от замечаний по отдельным документам на шаге 2, которые относятся к одному документу. Держи эти две вещи в брифе раздельно: неподписанный документ — наблюдение шага 2; счёт, оформленный не так, как предусматривает план, — сопоставление шага 5.

## Шаг 5: Сопоставь

Передай это субагенту `claude-for-financial-advisors:titling-compare`, то есть `Agent(claude-for-financial-advisors:titling-compare)`, отдав ему результат шага 2 как **предусмотренное** и результат шага 4 как **фактическое**. Он вернёт таблицу сопоставления, расхождения, отнесённые к уровням «Высокий / Средний / Низкий» по определениям из шага 6, и — то, что легко потерять при работе без него — предусмотренные пункты, для которых нет подходящего счёта вообще: так проявляется не наполненный активами траст.

Он распределяет по категориям, но не упорядочивает внутри уровня: ранжирование по размеру суммы и последствиям на шаге 6 за тобой. Он также никогда не заявляет, что расхождение юридически несостоятельно, и не предлагает исправления, то есть держит ту же границу, что и этот скилл.

Сопоставление, которое он проводит и которое нужно провести вручную, если субагент недоступен: по каждому счёту и позиции проверь их на соответствие тому, что предусматривает наследственный план:
- **Оформление совпадает?** Оформлен ли счёт так, как требует план (например, в плане сказано «на счёте семейного траста Смитов», а счёт всё ещё оформлен на частное лицо)?
- **Бенефициар совпадает?** Соответствует ли указанный бенефициар замыслу плана (например, в деле всё ещё бывший супруг, несовершеннолетний указан напрямую без оболочки траста или UTMA, там, где бенефициар ожидается, его нет вовсе)?

## Шаг 6: Отметки по приоритету

Выведи то, что требует внимания советника, расположив так, чтобы самые значимые по последствиям пункты были видны первыми: в этом смысл брифа.

- **Высокий** — не наполненный активами траст, который содержит (или должен содержать) заметную часть имущества, либо конфликт бенефициаров, который прямо направит актив не туда (в деле всё ещё бывший супруг, несовершеннолетний указан без оболочки траста или UTMA). Такие ошибки срабатывают молча и наиболее значимы.
- **Средний** — расхождения в оформлении, которые не направляют актив не туда напрямую, но мешают плану работать как задумано (частичное наполнение траста, неверный тип счёта).
- **Низкий** — отсутствующие назначения бенефициаров там, где всё ещё действует структура плана по умолчанию или резервная, либо мелкие пробелы в документации.

Внутри каждого уровня опирайся на суждение о размере суммы и последствиях: пробел в оформлении на 50 тыс. $ и не наполненный активами траст на 5 млн $ оба «Высокие» по категории, но советник должен увидеть крупный первым. Если сопоставление невозможно, потому что не хватает данных шага 2 или шага 4 по этому счёту или тресту, прямо скажи об этом, а не пропускай пункт молча.

Каждое отмеченное расхождение, какого бы уровня оно ни было, заканчивается рекомендацией, чтобы советник привлёк юриста домохозяйства по наследственным вопросам, прежде чем советовать клиенту следующие шаги; назови юриста, если его называет источник. Это предложение — то, что скилл предлагает вместо исправления, и важнее всего оно на Высоких отметках, где сильнее всего хочется сказать, что делать. Постоянная пометка в начале брифа (шаг 7) его не заменяет: читатель, остановившийся на отметке, должен увидеть отсылку к юристу на самой отметке.

## Шаг 7: Результат

Сначала запиши бриф, готовый к встрече, в файл markdown, и пиши его независимо от того, были ли доступны все источники. Раздел, источника которого не было, несёт вместо содержания предложение-заглушку и пометку об ожидании: недоступный источник никогда не повод задерживать файл. (Неподтверждённая личность или противоречие двух систем о сегодняшнем факте на шаге 4 — повод, и это блокирующие вопросы выше, которые задаются до выгрузки, а не после файла.) Вопросы к советнику о том, чего не хватало (ручной пересказ прошлой встречи, документ для загрузки), идут в чат *после* появления файла, а не вместо него. Порядок внутри файла:
1. **С прошлой встречи** — пересказ шага 1 (что обсуждали, что сделано)
2. **Статус документов** — ключевые наследственные документы и подписан ли каждый, с замечаниями по документам из шага 2
3. **Налоговая ретроспектива за прошлый год** — цифры шага 3, каждая с указанием декларации или отчёта, откуда она взята, а ставки показаны рядом с суммой налога и базой дохода
4. **Таблица сопоставления** — одна строка на счёт или позицию, четыре столбца с этими заголовками в этом порядке: **Счёт / позиция**, **Предусмотрено планом**, **Фактическое оформление / бенефициар**, **Совпадает?**. Сохраняй заголовки как написано и ничего не вставляй между ними: советник читает эту таблицу по разным домохозяйствам, и одни и те же четыре столбца в одном порядке делают её сканируемой с первого взгляда. Всё лишнее, значение или примечание, идёт после «Совпадает?».
5. **Отметки** — список шага 6, отсортированный по приоритету
6. Резюме из 2–3 предложений простым языком о том, как обстоит дело с наполнением плана активами у домохозяйства

**Сам бриф обязан нести оговорку, что это не юридическая консультация**: он выйдет за пределы этой сессии как файл, который другие люди могут читать без окружающего разговора, поэтому рамка должна идти вместе с ним. Вставь короткую постоянную пометку ближе к началу, простым языком, а не юридическим: это сводка, подготовленная в поддержку проверки советника, она отмечает пункты для обсуждения с юристом домохозяйства по наследственным вопросам и не является юридической консультацией или юридической проверкой плана. Скажи то же о наблюдениях по документам везде, где они встречаются: это вопросы, которые нужно поднять, а не выводы о том, надёжен ли план.

Чат после файла — одно короткое завершение, и в нём всегда две вещи: вопрос о формате — нужно ли преобразовать в .docx или .pdf (не создавай ни тот ни другой, пока не попросят; markdown — результат первого прохода, а тяжёлые форматы делаются заметно дольше, поэтому создаются только по запросу) — и вопросы о том, чего не хватало, из первого абзаца этого шага. Задай оба. Завершение, которое просит ручной пересказ и опускает вопрос о формате, — промах, который советник не заметит, потому что не знает, что вопрос был нужен.

## Шаг 8: Запиши последующие задачи в CRM

Составь задачу в CRM на каждую отметку, выведенную в брифе (описание, приоритет, предлагаемый ответственный: советник или юрист домохозяйства по наследственным вопросам), и покажи советнику полный черновик списка, прежде чем что-либо создавать.

Создавай только те задачи, которые советник утвердит (все, часть или отредактированные), в той CRM, которая определена как основная учётная на шаге 1. Коротко подтверди, что было записано.

## Вне рамок (пока)

- **Никаких юридических советов и юридических выводов.** Скилл отмечает расхождения, чтобы их оценил советник (а где уместно, юрист домохозяйства по наследственным вопросам); он никогда не заявляет, что расхождение юридически несостоятельно, и не рекомендует конкретное исправление.
- **Никаких черновиков документов.** Никогда не составляй и не изменяй текст траста, формы бенефициаров и другие наследственные документы.
- **Никаких налоговых советов и налоговой стратегии.** Ретроспектива за прошлый год — сообщаемый контекст, а не план: скилл никогда не рекомендует конверсию, реализацию убытков (harvest), дарение или позицию при подаче и никогда не пересчитывает цифру, которую сообщает система-источник.
- **Никаких записей по счетам.** Скилл никогда не переоформляет счёт и не меняет назначение бенефициара: любое исправление идёт через обычный процесс советника у кастодиана или в CRM. Единственная запись, которую делает скилл, — создание утверждённых советником последующих задач в CRM (шаг 8).

## Важные замечания

- **Каждая запись в CRM ждёт утверждения советника.** Никогда не создавай последующую задачу, которой советник не видел и не подтвердил.
- Никогда не выдумывай, что говорит наследственный план, подписан ли документ, каково фактическое оформление или бенефициар счёта, что сообщила декларация прошлого года и что было на прошлой встрече. Отсутствующие данные — это «— ожидает [коннектор / документы]», а не догадка.
- Рекомендуй советнику привлекать юриста домохозяйства по наследственным вопросам при любом отмеченном расхождении, прежде чем советовать клиенту следующие шаги: шаг 6 ставит это предложение на каждую отметку.
- Считай данные о наследстве, бенефициарах и заметках о встречах конфиденциальными; включай только то, что нужно для этого разбора.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-for-financial-advisors/tree/main/skills/estate-and-tax-brief, лицензия Apache-2.0. Изменения: перевод на русский язык.

Бриф по наследству и налогам

Как включить

Текст

Бриф по наследству и налогам

Входные данные

Сбор данных: шаги 1–4 идут одновременно

Шаг 1: С прошлой встречи — контекст из CRM

Шаг 2: Наследственный план — что он предусматривает (Wealth.com)

Шаг 3: Налоговая ретроспектива за прошлый год (Wealth.com)

Шаг 4: Счета — что они показывают на самом деле (Schwab, Orion/Addepar, iCapital)

Шаг 5: Сопоставь

Шаг 6: Отметки по приоритету

Шаг 7: Результат

Шаг 8: Запиши последующие задачи в CRM

Вне рамок (пока)

Важные замечания

Похожие