Подготовка к встрече с клиентом

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

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

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

Что делает: Собирает данные из CRM, портфеля, почты и заметок и готовит документ с повесткой, тезисами и действиями для обзорной встречи.
Когда брать: Перед квартальной, годовой или разовой обзорной встречей финансового советника с клиентом.
Когда не брать: Если нужно исполнить сделку, отправить документ клиенту или дать юридический совет: скилл этого не делает.
Пример запроса: Подготовь меня к квартальной встрече с семьёй Ивановых завтра.
Нужно подключить: CRM, данные по портфелю клиента
Работает лучше с: почта, заметки со встреч (Zocks), план MoneyGuide, Wealth.com

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

Как включить

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

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

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

Текст

---
name: pre-meeting
description: Готовит финансовому советнику полный документ для подготовки к обзорной встрече с клиентом за любой период, который охватывает обзор (квартальный, годовой, разовый). По названию домохозяйства или электронной почте и периоду собирает контекст из CRM (Salesforce/Redtail/Wealthbox), данные портфеля (Orion/Addepar/Envestnet-Tamarac), статус наследственного и налогового планирования (Wealth.com), заметки со встреч (Zocks или CRM), недавнюю переписку (Gmail/Outlook) и срез финансового плана домохозяйства (MoneyGuide), а затем собирает готовый к встрече документ с повесткой, тезисами и списком действий. Срабатывает на фразы «подготовка ко встрече», «/pre-meeting», «подготовь меня к [клиенту]», «подготовка к квартальному обзору», «подготовь меня к встрече с [клиентом]», «завтра встреча с клиентом».
---

Подготовка ко встрече

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

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

Обязательно: название домохозяйства (household) и/или адрес электронной почты и период, который охватывает обзор (квартальный, годовой или разовый). Если чего-то из этого нет, до всего остального спроси оба пункта; если советнику всё равно, считай период квартальным.

Необязательно (спрашивай только при неоднозначности): дата и время встречи, что советник хочет обсудить в первую очередь.

Сбор данных

Следуй соглашению о подстановках для коннекторов (Connector Placeholder Convention): прежде чем считать, что какая-то из систем ниже не подключена, проверь ListConnectors (загрузи через ToolSearch, если он пока недоступен). Не угадывай префикс имени инструмента вроде mcp__orion__*: у настоящих инструментов коннекторов префиксы непрозрачные. Если система подключена, найди её настоящие инструменты через ToolSearch (по названию системы). Если не подключена, скажи: «Здесь я бы обратился к [системе], чтобы получить [данные], когда этот коннектор будет готов», затем предложи ручную замену (вставить текст, загрузить выгрузку или пропустить) и продолжай. Применяй это к каждому источнику ниже, а не только к первому отсутствующему. Если по этому домохозяйству одну и ту же задачу могут решать несколько подключённых инструментов (необязательно двух одного вида), один раз спроси советника, какой из них главный источник данных, по соглашению «Спроси один раз, затем направляй» (Ask-Once, Then Route Convention), а не угадывай, и предложи помочь сохранить этот выбор по соглашению о персонализации (Personalization Convention). Сбор данных затрагивает несколько систем подряд, поэтому проверка не разовая в начале: повторяй её каждый раз, когда более поздний источник может ответить на то, на что уже отвечал более ранний. Если два полученных источника расходятся по существенному факту, остановись и подними это перед советником как блокирующий вопрос до завершения брифа, а не показывай оба варианта. Если расхождение для одного и того же домохозяйства составляет порядки величины, следуй соглашению о конфликте порядков величин (Magnitude-Conflict Convention): назови конфликт и исключи цифры выбивающегося источника из всех таблиц и итогов, а не приводи их как доказательства.

Сначала ищи инструменты, а не верь реестру. Решает проверка через ToolSearch по названию самой системы: если её инструменты нашлись, система подключена и доступна, пользуйся ими. ListConnectors может ответить «No installed connectors found» даже в сессии с несколькими живыми рабочими коннекторами, а в некоторых клиентах он вообще показывает карточку для пользователя, а не возвращает данные. Поэтому он объясняет пробел, но никогда его не устанавливает, а пустой результат означает неизвестно, а не «ничего не подключено». Если он всё же вернул записи, смотри на enabledInChat, а не на connected: connected: true при enabledInChat: false значит, что вход выполнен, но в этом чате система отключена, поэтому скажи советнику, что её можно включить здесь, а не сообщай, что она не подключена; отсутствующее или null значение connected означает «неизвестно», а не «отключено».

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

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

Личность по-прежнему на тебе. Субагентам велено никогда её не определять: если claude-for-financial-advisors:source-extract находит несколько кандидатов или несоответствие, он возвращает IDENTITY MISMATCH с тем, что увидел, и останавливается. Обработай это так, как сказано в правиле разведения совпадений ниже: покажи советнику кандидатов, получи подтверждение, запусти заново. Перед сборкой чего-либо проверь, что возвращённые блоки совпадают по домохозяйству. Параллельное чтение не снимает эту ответственность: она остаётся на тебе.

Субагент, который вернул NOT CONNECTED, — случай соглашения о подстановках для коннекторов. Ручную замену он сам не предложит: он не участвует в разговоре с советником. Это предложение делаешь ты.

1. CRM: Salesforce (или Redtail/Wealthbox)

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

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

Получи запись домохозяйства:

Поля типа заметок/инсайтов (свободные заметки, комментарии) из записи CRM
Члены домохозяйства, ключевые даты (дни рождения, возраст обязательных минимальных выплат RMD, право на Medicare в 65 лет, точки принятия решений по Social Security)
Открытые задачи/действия (структурированный список задач) — на обоих уровнях: собственные пункты записи домохозяйства и пункты каждого контакта-человека. Домохозяйство в CRM часто само является записью со своим идентификатором (в Wealthbox это контакт), а задачи, привязанные к домохозяйству, не видны при поиске только по контактам
История обслуживания: недавние обращения, жалобы, данные рекомендации

2. Портфель: Orion / Addepar / Envestnet-Tamarac

Получи данные по домохозяйству и по каждому счёту: рыночную стоимость, результативность относительно бенчмарка, структуру относительно целевой и отклонение (drift), реализованную и нереализованную прибыль, доходы и комиссии, остатки денежных средств и крупные потоки за период обзора.

Особенности Orion Connect: пять недавно выпущенных инструментов (oc_search_accounts, oc_get_current_value, oc_list_household_accounts, oc_get_household_address, oc_lookup_account_owner) — только справочные запросы личности и активов под управлением (AUM) без права записи: личность домохозяйства/счёта, текущая стоимость, почтовый адрес. Они не возвращают активы, результативность относительно бенчмарка, структуру/отклонение, прибыль, комиссии и потоки; не выводи ничего из этого по цифре текущей стоимости. Используй эти пять для определения личности домохозяйства/счёта и AUM без подтверждения: это быстрые чтения, а не запуск отчётов.

Для активов, результативности, отклонения, прибыли, комиссий или потоков используй существующую цепочку отчётов Orion: oc_search_households → oc_list_reports → oc_get_report_parameters → oc_generate_report. Эта цепочка запускает задание в Orion Connect, а не читает готовое, поэтому перед созданием отчёта получи подтверждение советника, примерно расскажи, что в нём будет, и пока он выполняется, показывай текст о ходе и статусе, а не молчаливое ожидание. Шаг генерации возвращает ссылку на готовый отчёт, а не его содержимое: передай советнику ссылку, скажи, что это, и скажи, что она истекает через 24 часа (уникальный адрес для каждого запуска); не открывай её, чтобы достать цифры, и не считай, что получение ссылки равно прочтению данных. Если советник вернётся с истёкшей ссылкой, создай отчёт заново (с тем же шагом предварительного подтверждения), а не разбирайся с адресом. Если цепочка отчётов не работает или не возвращает данных за период, прямо понизь результат: назови имеющуюся цифру AUM и пометь результативность/отклонение/комиссии/потоки «— ожидается отчёт Orion», а не подавай AUM как полную картину портфеля.

Если коннектор показывает статус сверки (например, getAccount у Envestnet/Tamarac возвращает reconciliationStatus / lastReconciliationDate), получи его и покажи: отметь устаревшие или несверенные данные, прежде чем приводить остатки, построенные на них.

Лёгкая проверка альтернативных вложений (alts), которые клиент держит вне фирмы (held-away): если подключён iCapital или Addepar и он ещё не является источником портфеля для этого документа (Addepar как источник уже охватывает альтернативные вложения через сквозной учёт), сделай одну дешёвую проверку экспозиции. query_positions в iCapital по account_name разрешается на сервере, но возвращает пустые названия счетов и фондов, поэтому сообщай только число позиций, найденных по имени, а не самостоятельно просуммированную сумму в долларах. search_entities в Addepar плюс один get_exposure по классу активов возвращает вычисленные платформой стоимость и долю по каждой группе: приводи эти строки как возвращены, не складывай их в собственный «итог по альтернативным вложениям». Найдены позиции → одна строка в шаблоне со ссылкой на платформу и отсылкой к /alts-brief за подробностями (никаких обращений за капиталом, периодов блокировки и результативности здесь). Альтернативные вложения необязательны, поэтому отсутствие не считается пробелом: если платформы альтернативных вложений не подключены или совпадений нет → вообще опусти строку, без «ожидается». Единственная строка, которую пишут без позиций: платформа подключена, но проверка не удалась → «— альтернативные вложения не проверялись; запусти /alts-brief, если у этого домохозяйства есть альтернативные инвестиции».

3. Наследство и налоги: Wealth.com

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

4. Заметки со встреч: Zocks (или заметки CRM как запасной вариант)

У Zocks нет точки доступа «подготовка»: MCP Zocks предоставляет только «атомарные» чтения (контакты, встречи, ИИ-результаты по каждой встрече, инсайты), а не готовый бриф, который создаёт интерфейс самого продукта. Собери картину сам:

Разверни запросы, затем убери дубли. Определи контакты домохозяйства, составь список их прошлых встреч, затем получи ИИ-результаты/сводки по каждой встрече. Извлечения по отдельным встречам повторяют почти одни и те же сведения о домохозяйстве и финансах, а у давнего домохозяйства может вернуться несколько десятков результатов и сводок. Сведи их в одну актуальную картину, а не перечисляй каждую копию.
Приоритет по порядку: отдавай предпочтение ИИ-результатам и сводкам Zocks перед исходной расшифровкой; используй расшифровку только когда нужны слова самого клиента дословно (например, прямая цитата), а не как источник по умолчанию. Если Zocks не подключён или подключён, но не возвращает контактов и встреч по этому домохозяйству, возьми то, что CRM записала по прошлым встречам: обычно как раз последнее, а не отсутствие коннектора. Только если недоступно ни то ни другое, переходи дальше к ручной вставке или загрузке.
По умолчанию начинай со сводки. Не выгружай каждую выдачу ai_results_* по каждой встрече: по умолчанию получи сводки по последним 1–2 встречам. Полный разворот извлечений по большему числу встреч считай более глубоким и медленным проходом и спроси советника, прежде чем тратить на него дополнительное время.
Домохозяйство — это отношения, а не запись. В Zocks нет объекта «домохозяйство»: это «люди, которые обычно приходят на встречи вместе». Считай запись домохозяйства в CRM главным источником данных, а Zocks используй только для красок; сверяй то, что говорит извлечение по встрече, с CRM и не считай извлечение по одной встрече авторитетным.
Один пункт — одна строка. Когда действие из Zocks и задача CRM описывают одно и то же (например, анализ конвертации в Roth, упомянутый на встрече и отслеживаемый как задача CRM), объедини их в одну строку со статусом из CRM; не перечисляй дважды только потому, что в Zocks пункт значится нерешённым, а в CRM решённым.
Ссылайся на встречу по дате (и по идентификатору встречи, если инструмент его возвращает) для всего, что взято из Zocks, и никогда не приписывай CRM или планировщику факт, которого MCP Zocks сам не вернул: его инструменты отдают только собственные данные Zocks о встречах, а не данные систем, с которыми Zocks интегрируется.
Инсайты уровня фирмы показывай отдельно, когда у коннектора есть инструмент инсайтов: актуальные темы по всей фирме, настроения, возможности для рекомендаций. Это не то же самое, что «что изменилось у этого домохозяйства», и это относится к «Тезисам для разговора» (см. ниже), а не вливается в «С нашей последней встречи». Инсайт или оценка настроения по конкретному домохозяйству из того же инструмента, привязанные именно к этому клиенту, — это «Сигнал об отношениях», а не тренд фирмы: направляй его туда.
Сигналы об отношениях бери из инсайтов и заметок, а не из полей задач. Заполняй раздел «Сигналы об отношениях» сначала ИИ-результатами/сводками и инсайтами Zocks (insights_query_insights, если коннектор его предоставляет), затем свободными полями заметок CRM (заметки со встреч, «notes»/«comments» в записи контакта или домохозяйства), и никогда не из структурированных полей задач/действий CRM. Поля задач отслеживают, что должно быть сделано, а не что верно об отношениях, и используются у RIA непоследовательно; CRM с пустым списком задач всё равно может иметь богатое поле заметок. Этот раздел должен заполняться из того, что доступно: Zocks или заметки CRM; он не ждёт обоих и никогда не блокируется из-за того, что список задач пуст или не ведётся. Если недоступны и Zocks, и заметки CRM, пометь раздел «— ожидается коннектор Zocks / CRM» по соглашению о подстановках для коннекторов, а не опускай его. Указывай источник каждого сигнала так же, как выше: дату (и идентификатор встречи, если возвращён) для всего, что из Zocks, и название поля (например, «по полю заметок CRM») для всего, что из CRM. Сигнал без источника в документ не попадает.
Предлагаемую повестку по-прежнему пишет этот скилл сам по собранным данным: никогда не считай сгенерированную Zocks повестку/подготовку или его подсказки по умолчанию заменой этого раздела.

5. Почта: Gmail / Outlook (для большинства пользователей доступна сегодня)

Найди переписку с адресом электронной почты домохозяйства за окно, зависящее от выбранного периода: примерно последние 3–4 месяца для квартального обзора, около 12 месяцев для годового или то, что подходит для разового. Извлеки:

Открытые запросы или вопросы, на которые клиент ждёт ответа
Обязательства, которые взял на себя советник («Я пришлю вам анализ Roth»)
Упомянутые жизненные события (смена работы, новый внук, покупка дома, здоровье, наследство)
Тон и настроение: всё, что говорит о тревоге или недовольстве

6. Срез плана: MoneyGuide

У этого источника нет окна обзора. Он читает план домохозяйства в том виде, какой он сейчас, поэтому при запуске передай этот факт вместо окна: не оставляй пустое место и не передавай период обзора, который подразумевал бы ретроспективу, которой у этого источника нет.

Определение личности остаётся внутри этого запроса, как и в любом другом источнике, который определяет её в своей системе: субагент ищет в MoneyGuide по фамилии (домохозяйства хранятся с фамилии вперёд, и поиск совпадает с началом названия) и возвращает IDENTITY MISMATCH с тем, что увидел, если совпадений несколько или нет вовсе.

Получи:

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

Приводи каждую цифру точно так, как её вернул MoneyGuide: вывод — это текст, уже округлённый, поэтому никогда не пересчитывай, не выводи заново и не округляй его повторно и никогда не заполняй пробел собственной цифрой.

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

Сборка документа для подготовки

Используй templates/pre-meeting-template.md в папке этого скилла как каркас документа. Заполняй каждый раздел; где данных нет, помечай «— ожидается [коннектор]», а не оставляй пустоту молча.

Разделы документа по порядку:

Сводка по клиенту (Client Snapshot) — домохозяйство, AUM, срок сотрудничества, профиль риска
Сигналы об отношениях (Relationship Signals) — тревоги и настроения клиента, жизненные события, предстоящие личные даты (дни рождения, годовщины, вехи), проактивные темы для разговора, и у каждого сигнала указан источник
С нашей последней встречи (Since We Last Met) — открытые действия с прошлой встречи с исполнителем и статусом (помечай «неизвестно — ожидается CRM», пока собственный список задач CRM не подтвердит выполнение; никогда не выводи «выполнено» из источника заметок со встреч, который не сообщает о завершении), заметная переписка
Обзор портфеля (Portfolio Review) — таблица результативности относительно бенчмарка, главные источники вклада и отставания, таблица отклонений структуры, денежная позиция
Возможности планирования (Planning Opportunities) — проактивные пункты: ребалансировка, реализация убытков в налоговых целях (tax-loss harvesting), окно конвертации в Roth, планирование RMD/QCD, пополнение 529, проверка бенефициаров, пробелы в страховании
Предлагаемая повестка (Proposed Agenda) — повестка на 30–45 минут с распределением времени
Тезисы для разговора и ожидаемые вопросы (Talking Points & Anticipated Questions) — 3–5 тезисов простым языком (о портфеле и рынке; личные темы живут в «Сигналах об отношениях»); инсайты и тренды уровня фирмы, если есть; вероятные вопросы клиента (особенно о слабой результативности и рынках) с предлагаемой подачей
Черновик действий (Action Items Draft) — заранее подготовленные следующие шаги, которые нужно подтвердить на встрече

Этот скилл никогда не вычисляет и не выдумывает вероятность выполнения плана, статус финансирования или результат Монте-Карло: чистая стоимость активов, вероятность успеха и цели из MoneyGuide попадают в «Возможности планирования» как фон, в точности как были возвращены, а не как отдельный раздел плана.

Результат

Сначала запиши документ для подготовки как файл markdown. Вверху — сводка примерно на страницу, за ней подтверждающие таблицы.
Пиши понятным клиенту языком: советник может показывать части документа с экрана.
Записав файл markdown, спроси советника, нужно ли превратить его в .docx или .pdf (через скилл docx); не создавай ни один из форматов, если он не попросит. Также спроси, нужен ли документ длиннее или короче, и при необходимости доработай.
Закончи ответ в чате сводкой из 2–3 предложений «если прочитаете только одно» о ситуации клиента.

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

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

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

Слабая результативность идёт первой, а не прячется. Если портфель отстал от бенчмарка, поставь это в тезисы для разговора с честным объяснением: советники теряют доверие, когда уходят от этой темы.
Никогда не выдумывай цифры результативности, вероятности плана и сведения о клиенте. Если источник недоступен и советник не может дать данные, покажи раздел как ожидающий.
Отмечай содержимое, чувствительное к требованиям соответствия: если документ для подготовки будет показан клиенту, порекомендуй пропустить выдержки, предназначенные клиенту, через /compliance.
Следи за триггерными вехами в данных: 50 лет (дополнительные взносы catch-up), 59½ (вывод без штрафа), 62–70 (Social Security), 65 (Medicare), 73 (RMD).
Относись ко всем данным клиента как к конфиденциальным; включай только то, что нужно для этой встречи.

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

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

---
name: pre-meeting
description: Prepare a complete client review meeting prep document for a financial advisor, for whatever timeframe the review covers (quarterly, annual, ad hoc). Given a household name or email and a timeframe, pulls CRM context (Salesforce/Redtail/Wealthbox), portfolio data (Orion/Addepar/Envestnet-Tamarac), estate & tax status (Wealth.com), meeting notes (Zocks or CRM), recent correspondence (Gmail/Outlook), and the household's plan snapshot (MoneyGuide), then assembles a meeting-ready prep doc with agenda, talking points, and action items. Triggers on "pre meeting", "/pre-meeting", "prep for [client]", "quarterly review prep", "get me ready for my meeting with [client]", or "client meeting tomorrow".
---

# Pre Meeting

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

## Inputs

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

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

## Data Gathering

Follow the **Connector Placeholder Convention**: before assuming a system below isn't connected, check `ListConnectors` (load via `ToolSearch` if it isn't already available) — don't guess at a tool-name prefix like `mcp__orion__*`, since real connector tool names use opaque prefixes. If it's connected, use `ToolSearch` (by system name) to find its actual tools. If it's not connected, say "This is where I'd make a call out to [system] to pull [data] once that connector is built," then offer the manual fallback (paste, upload an export, or skip) and keep going. Apply this to every source below, not just the first one that's missing — and if more than one connected tool could try to solve the same problem for this household (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 gathering pass touches several systems in sequence, so the check isn't a one-time thing at the top: re-run it whenever a later source could answer something an earlier one already did, and if two sources you did pull disagree on a material fact, stop and surface it to the advisor as a blocking question before the brief is finalized rather than presenting both. If the disagreement is by orders of magnitude for the same household, follow the Magnitude-Conflict Convention: name the conflict, and exclude the outlier's figures from every table and total rather than quoting them as evidence.

**Look for the tools before you trust the registry.** `ToolSearch` by the system's own name is the check that decides: if its tools come back, that system is connected and callable — use them. `ListConnectors` can answer "No installed connectors found" even in a session with several live, working connectors, and in some clients it renders a user-facing card rather than returning data at all. So it explains a gap, it never establishes one, and an empty result means **unknown**, never "nothing is connected". When it does return entries, read `enabledInChat`, not `connected`: `connected: true` with `enabledInChat: false` is authenticated but switched off for this chat, so tell the advisor they can enable it here rather than reporting it as unconnected; a missing or `null` `connected` is unknown, not disconnected.

Once identity is confirmed, **pull from all connected sources in parallel** — one slow or missing source degrades only its own section of the doc, not the rest. Before starting this multi-source pull, tell the advisor what you're about to gather and why, so it doesn't look like a silent hang. And once the household and timeframe are known, don't ask "should I start?" — narrate what you're doing and go; approval gates in this skill apply only to format conversions and length changes at the end, not to starting the work.

**Dispatch the parallel pull as one `claude-for-financial-advisors:source-extract` subagent per source, all in a single message** — the Agent tool, `Agent(claude-for-financial-advisors:source-extract)`, one call per source in the same response so they run concurrently rather than one after another. Each dispatch hands over the household identity as you have it, the one system that subagent is to query, the field schema for that source (the bullet list under its heading below), and the window the timeframe implies — or, where a source reads current state and has no meaningful review window, a plain statement of that instead of a window. Each returns a filled schema block. Two reasons this is a subagent rather than a tool call you make yourself: the raw payloads — email threads, full holdings tables, an estate look-back — stay out of your context so you assemble the doc from six compact blocks instead of six raw dumps, and the extraction work for all six happens at once rather than sequentially in your own reasoning.

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

A subagent that returns `NOT CONNECTED` is the Connector Placeholder Convention case. It won't offer the manual fallback itself — it isn't in the conversation with the advisor. You make that offer.

### 1. CRM — Salesforce (or Redtail/Wealthbox)
**Disambiguation rule:** query the CRM by name AND confirm identity before pulling anything. If multiple contacts match the name, show the advisor the candidates (name + masked email + account) and ask which household is theirs — common names will return coincidental matches, and pulling the wrong client's data into a prep doc is a privacy incident. Never proceed on a name match alone. When one candidate is a clearly better match (exact email match, most recent activity), pre-select it as the default choice in that prompt — the advisor still has to confirm it, never skip that step outright.

A recognizable or public-figure name that matches a connected CRM record is a household like any other — treat it accordingly and do not refuse, hedge, or ask for extra justification because the name is well-known. This is guidance for how you proceed, not content for the document: the prep doc itself should read exactly like any other household's, with no note, disclaimer, or aside about the name being recognizable.

Pull the household record:
- Notes/insight-type fields (freeform notes, comments) from the CRM record
- Household members, key dates (birthdays, RMD age, Medicare eligibility at 65, Social Security decision points)
- Open tasks/action items (structured task list) — **at both grains: the household record's own items and each person contact's.** A CRM household is often itself a record with its own id (Wealthbox's is a contact), and household-linked tasks are invisible to contact-only lookups
- Service history — recent requests, complaints, referrals given

### 2. Portfolio — Orion / Addepar / Envestnet-Tamarac
Pull household and per-account data: market values, performance vs. benchmark, allocation vs. target and drift, realized/unrealized gains, income and fees, cash balances and large flows for the review period.

**Orion Connect specifics:** its five newly-shipped tools (`oc_search_accounts`, `oc_get_current_value`, `oc_list_household_accounts`, `oc_get_household_address`, `oc_lookup_account_owner`) are read-only identity/AUM lookups only — household/account identity, current value, mailing address. They do **not** return holdings, performance vs. benchmark, allocation/drift, gains, fees, or flows; don't infer any of those from a current-value number. Use these five for household/account identity and AUM with no confirmation needed — they're fast reads, not report runs.

For holdings, performance, drift, gains, fees, or flows, fall back to Orion's existing report chain: `oc_search_households` → `oc_list_reports` → `oc_get_report_parameters` → `oc_generate_report`. That chain runs a job in Orion Connect rather than reading one, so confirm with the advisor before generating a report, say roughly what it will contain, and show progress/status copy while it runs rather than a silent wait. The generate step returns a **link to the finished report**, not the report's contents — hand the advisor the link, say what it is, and say it **expires after 24 hours** (a unique per-run URL); don't fetch it to extract figures from, and don't treat having produced a link as having read the data. If the advisor comes back to an expired link, regenerate the report (with the same confirm-first step) rather than troubleshooting the URL. If the report chain isn't live or doesn't return data for the period, degrade explicitly — state the AUM figure you do have and mark performance/drift/fees/flows "— pending Orion report," rather than presenting AUM as if it were the full portfolio picture.

Where the connector exposes reconciliation status (e.g. Envestnet/Tamarac's `getAccount` returning `reconciliationStatus` / `lastReconciliationDate`), pull and surface it — flag stale or unreconciled data before quoting balances built on it.

**Held-away alts check (lightweight):** if iCapital or Addepar is connected and isn't already this doc's portfolio source (Addepar-as-source already covers alts via lookthrough), run one cheap exposure check there — iCapital's `query_positions` by `account_name` resolves server-side but returns null account/fund names, so report a name-matched position count only, never a self-summed dollar total; Addepar's `search_entities` + one `get_exposure` by asset class returns platform-computed value/% per bucket — quote those rows as returned, don't re-aggregate them into an "alts total" of your own. Positions found → one line in the template, cited to the platform, pointing to `/alts-brief` for detail (no capital calls, lockups, or performance here). Alts are optional, so absence isn't a gap: no alts platform connected, or zero matches → **omit the line entirely, no "pending"**. The one line written without positions: platform connected but the check failed → "— alts coverage not checked; run /alts-brief if this household holds alternative investments".

### 3. Estate & Tax — Wealth.com
Pull an estate/tax look-back report: what changed since the last review (documents, titling, beneficiaries) and year-specific tax constants relevant to the household (contribution limits, RMD factors, and similar figures). Always cite these as reported by Wealth.com for the applicable tax year — never recompute or estimate a constant Claude wasn't given.

### 4. Meeting Notes — Zocks (or CRM notes as fallback)
There is no Zocks "prep" endpoint — Zocks' MCP only exposes atomized reads (contacts, meetings, per-meeting AI results, insights), not the finished brief its own product UI generates. Build the picture yourself:

- **Fan out, then dedupe.** Resolve the household's contacts, list their past meetings, then pull AI results/summaries per meeting. Per-meeting extractions repeat near-duplicate household/financial detail across meetings, and a long-standing household can return dozens of results and summaries — collapse those into one current picture instead of listing each copy.
- **Precedence, in order:** prefer Zocks' AI results/summaries over the raw transcript; use the transcript only when you need the client's own words verbatim (e.g., a direct quote), not as the default source; if Zocks isn't connected, or is connected but returns no contact/meetings for this household, fall back to whatever the CRM has logged from prior meetings — the common case is the latter, not a missing connector; only fall back further to a manual paste/upload if neither is available.
- **Default to summary-first.** Don't dump every `ai_results_*` payload for every meeting — pull summaries for the last 1-2 meetings by default. Treat a full extraction fan-out across more meetings as a deeper, slower pass and ask the advisor before spending that extra latency.
- **Household is a relationship, not a record.** Zocks has no household object — it's "the people who usually meet together." Treat the CRM's household record as the book of record and use Zocks only to color it; reconcile what a meeting extraction says against the CRM rather than treating any single meeting's extraction as authoritative.
- **One item, one row.** When a Zocks action item and a CRM task describe the same underlying thing (e.g. a Roth conversion analysis mentioned in a meeting and tracked as a CRM task), merge them into a single line using the CRM's status — never list it twice just because it showed up unresolved in Zocks and resolved in the CRM.
- **Cite the meeting**, by date (and meeting ID if the tool returns one), for anything sourced from Zocks — and never attribute a fact to a CRM or planning source that the Zocks MCP itself didn't return — its tools expose Zocks's own meeting data only, not the systems Zocks integrates with.
- **Layer firm-level Insights separately**, when the connector has an insights tool — firm-wide trending topics, sentiment, referral opportunities. That's distinct from "what changed for this household" and belongs in Talking Points (see below), not folded into Since We Last Met. A household-scoped insight or sentiment result from the same tool, tied to this client specifically, is a Relationship Signal, not a firm trend — route it there instead.
- **Relationship signals — source from insights and notes, not task fields.** Populate the Relationship Signals section from Zocks' AI results/summaries and insights (`insights_query_insights`, when the connector exposes it) first, then CRM freeform notes fields (meeting notes, "notes"/"comments" on the contact or household record) — never from CRM structured task/action-item fields. Task fields track what's due, not what's true about the relationship, and are used inconsistently across RIAs; a CRM with an empty task list can still have a rich notes field. This section should still populate from whichever of Zocks or CRM notes is available — it does not wait on both, and it never blocks on the task list being empty or unmaintained. If both Zocks and CRM notes are unavailable, mark the section "— pending Zocks / CRM connector" per the Connector Placeholder Convention rather than omitting it. Cite every signal the same way as above: date (and meeting ID if returned) for anything Zocks-sourced, the field name (e.g. "per CRM notes field") for anything CRM-sourced. A signal with no source behind it doesn't go in the doc.
- **This skill still writes the Proposed Agenda itself** from the gathered data — never call a Zocks-generated agenda/prep or its Default Prompts a substitute for that section.

### 5. Email — Gmail / Outlook (available today for most users)
Search correspondence with the household's email address over a window that follows the chosen timeframe — roughly the last 3-4 months for a quarterly review, ~12 months for an annual review, or whatever's appropriate for an ad hoc one. Extract:
- Open requests or questions the client is waiting on
- Commitments the advisor made ("I'll get you that Roth analysis")
- Life events mentioned (job change, new grandchild, home purchase, health, inheritance)
- Tone/sentiment — anything suggesting concern or dissatisfaction

### 6. Plan Snapshot — MoneyGuide
**This source has no review window.** It reads the household's plan as it stands right now, so the dispatch hands that fact over in the window's place — never a blank, and never the review timeframe, which would imply a lookback this source doesn't have.

**Identity stays inside this pull**, the same way every other source resolves its own system: the subagent searches MoneyGuide by surname — households are stored surname first and the search matches the start of the name — and returns `IDENTITY MISMATCH` with what it saw if several match or none do.

Pull:
- Net worth — total, assets, liabilities
- Probability of success — only when the household has a plan
- Each goal — name, initial expense, start year — only when the household has a plan
- The plan's last-updated date, which dates the plan without saying what changed in it

Quote every figure exactly as MoneyGuide returns it: the output is prose and already rounded, so never recompute, re-derive or re-round it, and never fill a gap with a figure of your own.

**No plan on file** is a normal, informative answer from a working connector, not a degraded read: net worth still comes back and still goes in the doc, while probability of success and goals are marked not applicable for this household rather than left blank. An absent probability of success is never rendered as zero and never dropped silently — and never marked pending either, which would send the advisor chasing a connector problem instead of reading the connector's honest answer.

## Assemble the Prep Doc

Use `templates/pre-meeting-template.md` in this skill's folder as the document skeleton. Fill every section; where data was unavailable, mark it "— pending [connector]" rather than leaving blanks silently.

The doc's sections, in order:
1. **Client Snapshot** — household, AUM, tenure, risk profile
2. **Relationship Signals** — client concerns/sentiment, life events, upcoming personal dates (birthdays, anniversaries, milestones), proactive talking points — each signal cited to its source
3. **Since We Last Met** — open action items from last meeting with assignee and status (mark "unknown — pending CRM" unless the CRM's own task list confirms done; never infer "done" from a meeting-notes source that doesn't report completion), notable correspondence
4. **Portfolio Review** — performance vs. benchmark table, top contributors/detractors, allocation drift table, cash position
5. **Planning Opportunities** — proactive items: rebalancing, tax-loss harvesting, Roth conversion window, RMD/QCD planning, 529 funding, beneficiary review, insurance gaps
6. **Proposed Agenda** — a 30-45 minute agenda with time boxes
7. **Talking Points & Anticipated Questions** — 3-5 talking points in plain English (portfolio/market-facing — personal talking points live in Relationship Signals); firm-level Insights/trends when available; likely client questions (especially about underperformance or markets) with suggested framing
8. **Action Items Draft** — pre-drafted next steps to confirm in the meeting

This skill never computes or invents a plan probability, funded status, or Monte Carlo result — MoneyGuide's own net worth, probability of success and goals go under Planning Opportunities as color, quoted exactly as they came back, never as a plan section of their own.

## Output

- Write the prep doc as a markdown file first. One page-ish summary up front, supporting tables behind it.
- Keep language client-friendly — the advisor may screen-share parts of it.
- After writing the markdown file, ask the advisor whether they'd like it converted to .docx or .pdf (via the docx skill) — don't create either format unless they ask. Also ask whether they'd like the doc longer or shorter, and revise if so.
- End the chat response with 2-3 sentence "if you only read one thing" summary of the client's situation.

## Out of Scope (for now)

- **No trade execution.** This skill never places, stages, or confirms a trade.
- **No sending to the client.** The prep doc is for the advisor; sharing it is the advisor's call, through their normal workflow.
- **No inventing plan probabilities or performance.** See "Assemble the Prep Doc" above.
- **No legal advice.** Estate/tax findings are flagged for the advisor (and the household's attorney/CPA where relevant) to evaluate, not acted on here.

## Important Notes

- **Underperformance goes first, not buried.** If the portfolio trailed its benchmark, put it in talking points with an honest explanation — advisors lose trust by dodging it.
- Never fabricate performance numbers, plan probabilities, or client details. If a source is unavailable and the advisor can't provide data, show the section as pending.
- Flag compliance-sensitive content: if the prep doc will be shared with the client, recommend running client-facing excerpts through **/compliance**.
- Watch for milestone triggers in the data: turning 50 (catch-up contributions), 59½ (penalty-free withdrawals), 62-70 (Social Security), 65 (Medicare), 73 (RMDs).
- Treat all client data as confidential; only include what's needed for this meeting.

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

---
name: pre-meeting
description: Готовит финансовому советнику полный документ для подготовки к обзорной встрече с клиентом за любой период, который охватывает обзор (квартальный, годовой, разовый). По названию домохозяйства или электронной почте и периоду собирает контекст из CRM (Salesforce/Redtail/Wealthbox), данные портфеля (Orion/Addepar/Envestnet-Tamarac), статус наследственного и налогового планирования (Wealth.com), заметки со встреч (Zocks или CRM), недавнюю переписку (Gmail/Outlook) и срез финансового плана домохозяйства (MoneyGuide), а затем собирает готовый к встрече документ с повесткой, тезисами и списком действий. Срабатывает на фразы «подготовка ко встрече», «/pre-meeting», «подготовь меня к [клиенту]», «подготовка к квартальному обзору», «подготовь меня к встрече с [клиентом]», «завтра встреча с клиентом».
---

# Подготовка ко встрече

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

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

Обязательно: **название домохозяйства (household) и/или адрес электронной почты** и **период**, который охватывает обзор (квартальный, годовой или разовый). Если чего-то из этого нет, до всего остального спроси оба пункта; если советнику всё равно, считай период квартальным.

Необязательно (спрашивай только при неоднозначности): дата и время встречи, что советник хочет обсудить в первую очередь.

## Сбор данных

Следуй **соглашению о подстановках для коннекторов (Connector Placeholder Convention)**: прежде чем считать, что какая-то из систем ниже не подключена, проверь `ListConnectors` (загрузи через `ToolSearch`, если он пока недоступен). Не угадывай префикс имени инструмента вроде `mcp__orion__*`: у настоящих инструментов коннекторов префиксы непрозрачные. Если система подключена, найди её настоящие инструменты через `ToolSearch` (по названию системы). Если не подключена, скажи: «Здесь я бы обратился к [системе], чтобы получить [данные], когда этот коннектор будет готов», затем предложи ручную замену (вставить текст, загрузить выгрузку или пропустить) и продолжай. Применяй это к каждому источнику ниже, а не только к первому отсутствующему. Если по этому домохозяйству одну и ту же задачу могут решать несколько подключённых инструментов (необязательно двух одного вида), один раз спроси советника, какой из них главный источник данных, по соглашению «Спроси один раз, затем направляй» (Ask-Once, Then Route Convention), а не угадывай, и предложи помочь сохранить этот выбор по соглашению о персонализации (Personalization Convention). Сбор данных затрагивает несколько систем подряд, поэтому проверка не разовая в начале: повторяй её каждый раз, когда более поздний источник может ответить на то, на что уже отвечал более ранний. Если два полученных источника расходятся по существенному факту, остановись и подними это перед советником как блокирующий вопрос до завершения брифа, а не показывай оба варианта. Если расхождение для одного и того же домохозяйства составляет порядки величины, следуй соглашению о конфликте порядков величин (Magnitude-Conflict Convention): назови конфликт и исключи цифры выбивающегося источника из всех таблиц и итогов, а не приводи их как доказательства.

**Сначала ищи инструменты, а не верь реестру.** Решает проверка через `ToolSearch` по названию самой системы: если её инструменты нашлись, система подключена и доступна, пользуйся ими. `ListConnectors` может ответить «No installed connectors found» даже в сессии с несколькими живыми рабочими коннекторами, а в некоторых клиентах он вообще показывает карточку для пользователя, а не возвращает данные. Поэтому он объясняет пробел, но никогда его не устанавливает, а пустой результат означает **неизвестно**, а не «ничего не подключено». Если он всё же вернул записи, смотри на `enabledInChat`, а не на `connected`: `connected: true` при `enabledInChat: false` значит, что вход выполнен, но в этом чате система отключена, поэтому скажи советнику, что её можно включить здесь, а не сообщай, что она не подключена; отсутствующее или `null` значение `connected` означает «неизвестно», а не «отключено».

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

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

**Личность по-прежнему на тебе.** Субагентам велено никогда её не определять: если `claude-for-financial-advisors:source-extract` находит несколько кандидатов или несоответствие, он возвращает `IDENTITY MISMATCH` с тем, что увидел, и останавливается. Обработай это так, как сказано в правиле разведения совпадений ниже: покажи советнику кандидатов, получи подтверждение, запусти заново. Перед сборкой чего-либо проверь, что возвращённые блоки совпадают по домохозяйству. Параллельное чтение не снимает эту ответственность: она остаётся на тебе.

Субагент, который вернул `NOT CONNECTED`, — случай соглашения о подстановках для коннекторов. Ручную замену он сам не предложит: он не участвует в разговоре с советником. Это предложение делаешь ты.

### 1. CRM: Salesforce (или Redtail/Wealthbox)
**Правило разведения совпадений:** ищи в CRM по имени И подтверди личность, прежде чем что-либо получать. Если имени соответствует несколько контактов, покажи советнику кандидатов (имя + замаскированная почта + счёт) и спроси, какое домохозяйство нужное: частые имена дают случайные совпадения, а попадание данных чужого клиента в документ для подготовки — инцидент с конфиденциальностью. Никогда не продолжай, опираясь только на совпадение имени. Когда один из кандидатов явно подходит лучше (точное совпадение почты, самая свежая активность), выбери его по умолчанию в этом запросе: советник всё равно должен подтвердить выбор, пропускать этот шаг нельзя.

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

Получи запись домохозяйства:
- Поля типа заметок/инсайтов (свободные заметки, комментарии) из записи CRM
- Члены домохозяйства, ключевые даты (дни рождения, возраст обязательных минимальных выплат RMD, право на Medicare в 65 лет, точки принятия решений по Social Security)
- Открытые задачи/действия (структурированный список задач) — **на обоих уровнях: собственные пункты записи домохозяйства и пункты каждого контакта-человека.** Домохозяйство в CRM часто само является записью со своим идентификатором (в Wealthbox это контакт), а задачи, привязанные к домохозяйству, не видны при поиске только по контактам
- История обслуживания: недавние обращения, жалобы, данные рекомендации

### 2. Портфель: Orion / Addepar / Envestnet-Tamarac
Получи данные по домохозяйству и по каждому счёту: рыночную стоимость, результативность относительно бенчмарка, структуру относительно целевой и отклонение (drift), реализованную и нереализованную прибыль, доходы и комиссии, остатки денежных средств и крупные потоки за период обзора.

**Особенности Orion Connect:** пять недавно выпущенных инструментов (`oc_search_accounts`, `oc_get_current_value`, `oc_list_household_accounts`, `oc_get_household_address`, `oc_lookup_account_owner`) — только справочные запросы личности и активов под управлением (AUM) без права записи: личность домохозяйства/счёта, текущая стоимость, почтовый адрес. Они **не** возвращают активы, результативность относительно бенчмарка, структуру/отклонение, прибыль, комиссии и потоки; не выводи ничего из этого по цифре текущей стоимости. Используй эти пять для определения личности домохозяйства/счёта и AUM без подтверждения: это быстрые чтения, а не запуск отчётов.

Для активов, результативности, отклонения, прибыли, комиссий или потоков используй существующую цепочку отчётов Orion: `oc_search_households` → `oc_list_reports` → `oc_get_report_parameters` → `oc_generate_report`. Эта цепочка запускает задание в Orion Connect, а не читает готовое, поэтому перед созданием отчёта получи подтверждение советника, примерно расскажи, что в нём будет, и пока он выполняется, показывай текст о ходе и статусе, а не молчаливое ожидание. Шаг генерации возвращает **ссылку на готовый отчёт**, а не его содержимое: передай советнику ссылку, скажи, что это, и скажи, что она **истекает через 24 часа** (уникальный адрес для каждого запуска); не открывай её, чтобы достать цифры, и не считай, что получение ссылки равно прочтению данных. Если советник вернётся с истёкшей ссылкой, создай отчёт заново (с тем же шагом предварительного подтверждения), а не разбирайся с адресом. Если цепочка отчётов не работает или не возвращает данных за период, прямо понизь результат: назови имеющуюся цифру AUM и пометь результативность/отклонение/комиссии/потоки «— ожидается отчёт Orion», а не подавай AUM как полную картину портфеля.

Если коннектор показывает статус сверки (например, `getAccount` у Envestnet/Tamarac возвращает `reconciliationStatus` / `lastReconciliationDate`), получи его и покажи: отметь устаревшие или несверенные данные, прежде чем приводить остатки, построенные на них.

**Лёгкая проверка альтернативных вложений (alts), которые клиент держит вне фирмы (held-away):** если подключён iCapital или Addepar и он ещё не является источником портфеля для этого документа (Addepar как источник уже охватывает альтернативные вложения через сквозной учёт), сделай одну дешёвую проверку экспозиции. `query_positions` в iCapital по `account_name` разрешается на сервере, но возвращает пустые названия счетов и фондов, поэтому сообщай только число позиций, найденных по имени, а не самостоятельно просуммированную сумму в долларах. `search_entities` в Addepar плюс один `get_exposure` по классу активов возвращает вычисленные платформой стоимость и долю по каждой группе: приводи эти строки как возвращены, не складывай их в собственный «итог по альтернативным вложениям». Найдены позиции → одна строка в шаблоне со ссылкой на платформу и отсылкой к `/alts-brief` за подробностями (никаких обращений за капиталом, периодов блокировки и результативности здесь). Альтернативные вложения необязательны, поэтому отсутствие не считается пробелом: если платформы альтернативных вложений не подключены или совпадений нет → **вообще опусти строку, без «ожидается»**. Единственная строка, которую пишут без позиций: платформа подключена, но проверка не удалась → «— альтернативные вложения не проверялись; запусти /alts-brief, если у этого домохозяйства есть альтернативные инвестиции».

### 3. Наследство и налоги: Wealth.com
Получи ретроспективный отчёт по наследственному и налоговому планированию: что изменилось с последнего обзора (документы, оформление права собственности, бенефициары) и налоговые константы конкретного года, важные для домохозяйства (лимиты взносов, коэффициенты RMD и подобные величины). Всегда указывай их так, как сообщает Wealth.com за соответствующий налоговый год, и никогда не пересчитывай и не оценивай константу, которую Claude не получил.

### 4. Заметки со встреч: Zocks (или заметки CRM как запасной вариант)
У Zocks нет точки доступа «подготовка»: MCP Zocks предоставляет только «атомарные» чтения (контакты, встречи, ИИ-результаты по каждой встрече, инсайты), а не готовый бриф, который создаёт интерфейс самого продукта. Собери картину сам:

- **Разверни запросы, затем убери дубли.** Определи контакты домохозяйства, составь список их прошлых встреч, затем получи ИИ-результаты/сводки по каждой встрече. Извлечения по отдельным встречам повторяют почти одни и те же сведения о домохозяйстве и финансах, а у давнего домохозяйства может вернуться несколько десятков результатов и сводок. Сведи их в одну актуальную картину, а не перечисляй каждую копию.
- **Приоритет по порядку:** отдавай предпочтение ИИ-результатам и сводкам Zocks перед исходной расшифровкой; используй расшифровку только когда нужны слова самого клиента дословно (например, прямая цитата), а не как источник по умолчанию. Если Zocks не подключён или подключён, но не возвращает контактов и встреч по этому домохозяйству, возьми то, что CRM записала по прошлым встречам: обычно как раз последнее, а не отсутствие коннектора. Только если недоступно ни то ни другое, переходи дальше к ручной вставке или загрузке.
- **По умолчанию начинай со сводки.** Не выгружай каждую выдачу `ai_results_*` по каждой встрече: по умолчанию получи сводки по последним 1–2 встречам. Полный разворот извлечений по большему числу встреч считай более глубоким и медленным проходом и спроси советника, прежде чем тратить на него дополнительное время.
- **Домохозяйство — это отношения, а не запись.** В Zocks нет объекта «домохозяйство»: это «люди, которые обычно приходят на встречи вместе». Считай запись домохозяйства в CRM главным источником данных, а Zocks используй только для красок; сверяй то, что говорит извлечение по встрече, с CRM и не считай извлечение по одной встрече авторитетным.
- **Один пункт — одна строка.** Когда действие из Zocks и задача CRM описывают одно и то же (например, анализ конвертации в Roth, упомянутый на встрече и отслеживаемый как задача CRM), объедини их в одну строку со статусом из CRM; не перечисляй дважды только потому, что в Zocks пункт значится нерешённым, а в CRM решённым.
- **Ссылайся на встречу** по дате (и по идентификатору встречи, если инструмент его возвращает) для всего, что взято из Zocks, и никогда не приписывай CRM или планировщику факт, которого MCP Zocks сам не вернул: его инструменты отдают только собственные данные Zocks о встречах, а не данные систем, с которыми Zocks интегрируется.
- **Инсайты уровня фирмы показывай отдельно**, когда у коннектора есть инструмент инсайтов: актуальные темы по всей фирме, настроения, возможности для рекомендаций. Это не то же самое, что «что изменилось у этого домохозяйства», и это относится к «Тезисам для разговора» (см. ниже), а не вливается в «С нашей последней встречи». Инсайт или оценка настроения по конкретному домохозяйству из того же инструмента, привязанные именно к этому клиенту, — это «Сигнал об отношениях», а не тренд фирмы: направляй его туда.
- **Сигналы об отношениях бери из инсайтов и заметок, а не из полей задач.** Заполняй раздел «Сигналы об отношениях» сначала ИИ-результатами/сводками и инсайтами Zocks (`insights_query_insights`, если коннектор его предоставляет), затем свободными полями заметок CRM (заметки со встреч, «notes»/«comments» в записи контакта или домохозяйства), и никогда не из структурированных полей задач/действий CRM. Поля задач отслеживают, что должно быть сделано, а не что верно об отношениях, и используются у RIA непоследовательно; CRM с пустым списком задач всё равно может иметь богатое поле заметок. Этот раздел должен заполняться из того, что доступно: Zocks или заметки CRM; он не ждёт обоих и никогда не блокируется из-за того, что список задач пуст или не ведётся. Если недоступны и Zocks, и заметки CRM, пометь раздел «— ожидается коннектор Zocks / CRM» по соглашению о подстановках для коннекторов, а не опускай его. Указывай источник каждого сигнала так же, как выше: дату (и идентификатор встречи, если возвращён) для всего, что из Zocks, и название поля (например, «по полю заметок CRM») для всего, что из CRM. Сигнал без источника в документ не попадает.
- **Предлагаемую повестку по-прежнему пишет этот скилл** сам по собранным данным: никогда не считай сгенерированную Zocks повестку/подготовку или его подсказки по умолчанию заменой этого раздела.

### 5. Почта: Gmail / Outlook (для большинства пользователей доступна сегодня)
Найди переписку с адресом электронной почты домохозяйства за окно, зависящее от выбранного периода: примерно последние 3–4 месяца для квартального обзора, около 12 месяцев для годового или то, что подходит для разового. Извлеки:
- Открытые запросы или вопросы, на которые клиент ждёт ответа
- Обязательства, которые взял на себя советник («Я пришлю вам анализ Roth»)
- Упомянутые жизненные события (смена работы, новый внук, покупка дома, здоровье, наследство)
- Тон и настроение: всё, что говорит о тревоге или недовольстве

### 6. Срез плана: MoneyGuide
**У этого источника нет окна обзора.** Он читает план домохозяйства в том виде, какой он сейчас, поэтому при запуске передай этот факт вместо окна: не оставляй пустое место и не передавай период обзора, который подразумевал бы ретроспективу, которой у этого источника нет.

**Определение личности остаётся внутри этого запроса**, как и в любом другом источнике, который определяет её в своей системе: субагент ищет в MoneyGuide по фамилии (домохозяйства хранятся с фамилии вперёд, и поиск совпадает с началом названия) и возвращает `IDENTITY MISMATCH` с тем, что увидел, если совпадений несколько или нет вовсе.

Получи:
- Чистую стоимость активов: общую, активы, обязательства
- Вероятность успеха: только если у домохозяйства есть план
- Каждую цель: название, первоначальные расходы, год начала: только если у домохозяйства есть план
- Дату последнего обновления плана: она датирует план, но не говорит, что в нём изменилось

Приводи каждую цифру точно так, как её вернул MoneyGuide: вывод — это текст, уже округлённый, поэтому никогда не пересчитывай, не выводи заново и не округляй его повторно и никогда не заполняй пробел собственной цифрой.

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

## Сборка документа для подготовки

Используй `templates/pre-meeting-template.md` в папке этого скилла как каркас документа. Заполняй каждый раздел; где данных нет, помечай «— ожидается [коннектор]», а не оставляй пустоту молча.

Разделы документа по порядку:
1. **Сводка по клиенту (Client Snapshot)** — домохозяйство, AUM, срок сотрудничества, профиль риска
2. **Сигналы об отношениях (Relationship Signals)** — тревоги и настроения клиента, жизненные события, предстоящие личные даты (дни рождения, годовщины, вехи), проактивные темы для разговора, и у каждого сигнала указан источник
3. **С нашей последней встречи (Since We Last Met)** — открытые действия с прошлой встречи с исполнителем и статусом (помечай «неизвестно — ожидается CRM», пока собственный список задач CRM не подтвердит выполнение; никогда не выводи «выполнено» из источника заметок со встреч, который не сообщает о завершении), заметная переписка
4. **Обзор портфеля (Portfolio Review)** — таблица результативности относительно бенчмарка, главные источники вклада и отставания, таблица отклонений структуры, денежная позиция
5. **Возможности планирования (Planning Opportunities)** — проактивные пункты: ребалансировка, реализация убытков в налоговых целях (tax-loss harvesting), окно конвертации в Roth, планирование RMD/QCD, пополнение 529, проверка бенефициаров, пробелы в страховании
6. **Предлагаемая повестка (Proposed Agenda)** — повестка на 30–45 минут с распределением времени
7. **Тезисы для разговора и ожидаемые вопросы (Talking Points & Anticipated Questions)** — 3–5 тезисов простым языком (о портфеле и рынке; личные темы живут в «Сигналах об отношениях»); инсайты и тренды уровня фирмы, если есть; вероятные вопросы клиента (особенно о слабой результативности и рынках) с предлагаемой подачей
8. **Черновик действий (Action Items Draft)** — заранее подготовленные следующие шаги, которые нужно подтвердить на встрече

Этот скилл никогда не вычисляет и не выдумывает вероятность выполнения плана, статус финансирования или результат Монте-Карло: чистая стоимость активов, вероятность успеха и цели из MoneyGuide попадают в «Возможности планирования» как фон, в точности как были возвращены, а не как отдельный раздел плана.

## Результат

- Сначала запиши документ для подготовки как файл markdown. Вверху — сводка примерно на страницу, за ней подтверждающие таблицы.
- Пиши понятным клиенту языком: советник может показывать части документа с экрана.
- Записав файл markdown, спроси советника, нужно ли превратить его в .docx или .pdf (через скилл docx); не создавай ни один из форматов, если он не попросит. Также спроси, нужен ли документ длиннее или короче, и при необходимости доработай.
- Закончи ответ в чате сводкой из 2–3 предложений «если прочитаете только одно» о ситуации клиента.

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

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

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

- **Слабая результативность идёт первой, а не прячется.** Если портфель отстал от бенчмарка, поставь это в тезисы для разговора с честным объяснением: советники теряют доверие, когда уходят от этой темы.
- Никогда не выдумывай цифры результативности, вероятности плана и сведения о клиенте. Если источник недоступен и советник не может дать данные, покажи раздел как ожидающий.
- Отмечай содержимое, чувствительное к требованиям соответствия: если документ для подготовки будет показан клиенту, порекомендуй пропустить выдержки, предназначенные клиенту, через **/compliance**.
- Следи за триггерными вехами в данных: 50 лет (дополнительные взносы catch-up), 59½ (вывод без штрафа), 62–70 (Social Security), 65 (Medicare), 73 (RMD).
- Относись ко всем данным клиента как к конфиденциальным; включай только то, что нужно для этой встречи.

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