Обзор портфеля и ребалансировка

Проверяет доходность и отклонение портфеля от целевой структуры, подбирает налогово выгодные варианты ребалансировки и пишет записку с обоснованием.

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

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

Что делает: Проверяет доходность и отклонение портфеля от целевой структуры, подбирает налогово выгодные варианты ребалансировки и пишет записку с обоснованием.
Когда брать: Перед обзором портфеля клиента, когда нужно понять дрейф от IPS или модели и подготовить варианты ребалансировки для проверки советником.
Когда не брать: Не исполняет сделки, не оценивает пригодность портфеля для клиента и не придумывает позиции и базовую стоимость, если источник их не подтверждает.
Пример запроса: Сделай обзор портфеля семьи Смитов и подготовь варианты ребалансировки с учётом налогов.
Нужно подключить: портфельная система (Orion, Addepar или Envestnet)
Работает лучше с: BlackRock Advisor Center, Zocks, Google Диск

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

Как включить

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

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

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

Текст

---
name: portfolio-rebalance-review
description: Проводит обзор портфеля клиента или домохозяйства: доходность из Orion, анализ дрейфа структуры относительно IPS или модельного портфеля, сопоставление с модельным портфелем, подготовка ребалансировки с налоговыми возможностями, которые стоит рассмотреть, и записка с обоснованием ребалансировки для файла по соблюдению требований. Срабатывает на «обзор портфеля», «/portfolio-rebalance-review», «анализ дрейфа», «ребалансируй [клиент]», «как расположен портфель [клиент]», «обоснование ребалансировки» или «подбери [клиент] модель».
---

Обзор портфеля и ребалансировка

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

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

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

Шаг 1: Достань доходность и позиции

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

Запроси в подключённой системе портфельных данных домохозяйства:

Счета с регистрациями (облагаемый налогом, IRA, Roth, 401k, траст) и рыночной стоимостью
Позиции с количеством, рыночной стоимостью, базовой стоимостью (cost basis) и нереализованной прибылью или убытком
Доходность: QTD/YTD/1 год/3 года против назначенного бенчмарка, после комиссий
Назначенная модель или целевая структура и денежные остатки
Недавние потоки (взносы, выплаты, статус RMD)

Какую систему запрашивать: эти данные могут лежать в Orion, Addepar или Envestnet/Tamarac в зависимости от фирмы. Проверь ListConnectors (загрузи через ToolSearch, если он ещё недоступен), чтобы увидеть, какая реально подключена: не гадай префиксы имён инструментов, а когда узнаешь, какая работает, ищи через ToolSearch по названию системы.

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

Если не подключена ни одна: следуй правилу заглушки коннектора (Connector Placeholder Convention) и скажи *«Здесь я бы обратился к [система], чтобы получить [позиции/доходность], когда этот коннектор будет готов»*, затем предложи запасной вариант. Прежде чем просить загрузить файл вручную, предложи поискать на Google Диске (если он подключён) уже существующую выгрузку или выписку. Если и там ничего нет, попроси советника загрузить выгрузку (CSV/PDF), выписку кастодиана или вставить позиции. Продолжай с тем, что дали, а всё ещё отсутствующее помечай «— ожидает [коннектор]», а не оставляй пустым: отсутствующий источник ухудшает только зависящий от него раздел, а не весь обзор.
Если эту задачу для домохозяйства могут решить несколько подключённых инструментов, один раз спроси советника, какой из них считать основным учётным (book of record), по правилу «Спроси один раз, дальше маршрутизируй» (Ask-Once, Then Route Convention), а не угадывай и не объединяй обе, и используй эту систему до конца обзора. Это действует, даже если имя домохозяйства ещё не нашлось ни в одной из систем: спроси до дальнейшего поиска, а не после того, как выяснится, что ни одна не узнаёт имя: неопределённое домохозяйство не исключение из этого правила. Предложи помочь советнику сохранить выбор по правилу персонализации (Personalization Convention), чтобы в следующей сессии не спрашивать снова. Эта проверка действует до конца обзора, а не только один раз в начале: если советник посреди обзора назовёт ещё один источник, спроси и до того, как брать данные из него. А если цифры второй системы всё же были вытянуты и расходятся с основной по существенному факту (остаток, процент дрейфа), это блокирующий вопрос к советнику, а не примечание в результате.

Счета вне системы (held-away): спроси советника, есть ли у домохозяйства счета, хранящиеся вне этой системы (401k супруга, активы у другого кастодиана), которые важны для согласования правила отмывочных продаж (wash sale) или для общей картины структуры. Если да, запроси эти позиции вручную: коннектора для внешних счетов нет.

Особенности Addepar: вызывай get_portfolio_data с lookthrough=false для целей дрейфа. Разложение по базовым активам (lookthrough: фонд → составляющие) — это отдельный взгляд на риск: IPS называет блоки (sleeves) на уровне обязательств перед фондами, а lookthrough молча возвращает несовместимый набор корзин без предупреждения. Группируй по direct_owner, а не по account: последнее не является допустимым ключом группировки и приводит к ошибке. Для детализации по налоговым лотам передавай значение налогового лота в groupings только если живая схема инструмента действительно его описывает: базовая стоимость и поля уровня лота существуют не на каждом развёртывании Addepar. Если схема этого не поддерживает или в возвращённых столбцах нет базовой стоимости, скажи об этом прямо, а не выдавай выдуманные данные по лотам; это питает ту же проверку «Полнота» ниже.

Особенности Orion: инструменты Orion Connect (поиск домохозяйства, каталог отчётов, параметры отчётов, oc_generate_report) касаются только идентификации, каталога отчётов и их формирования: они не возвращают структурированные позиции, базовую стоимость и налоговые лоты. Формирование отчёта даёт ссылку на готовый отчёт, а не его содержание: передай её советнику и скажи, что она истекает через 24 часа (уникальный адрес на каждый запуск; сформируй заново, а не разбирайся с просроченным); не загружай её, чтобы вытащить таблицу позиций, и не считай, что выдача ссылки равна прочтению данных. Если Orion — единственная подключённая система, данные о позициях и базовой стоимости придётся получить от советника (загрузка или вставка), а не выводить из отчёта. Если Orion позже выпустит инструмент структурированных позиций или базовой стоимости, подключи его в ту же форму данных шага 1 рядом с Addepar.

Перед формированием отчёта в Orion: сначала подтверди у советника: oc_generate_report запускает задание в Orion Connect, а не читает из него. Подтверждение не нужно для поиска домохозяйства, каталога отчётов и запросов параметров отчётов: это вызовы идентификации и каталога, а не формирования отчёта.

Проверка данных на здравый смысл: выполни до шага 2, не пропускай. Отдай её субагенту claude-for-financial-advisors:holdings-sanity, то есть Agent(claude-for-financial-advisors:holdings-sanity), а не проходи вручную: передай ему данные по позициям, указанную стоимость портфеля или домохозяйства и структуру блоков из IPS или модели, если она есть. Он вернёт таблицу отметок со столбцом Contaminates (что портит), в котором названо, какую последующую цифру питает каждая проблема, а также прямой список проверок, которые прошли.

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

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

Временная: отметь любую позицию, у которой дата оценки раньше первой операции финансирования или взноса.
Масштаб: отметь любую позицию, у которой прибыль выглядит неправдоподобной для типа актива и срока владения (например, частный фонд вырос в несколько раз через несколько месяцев после финансирования), и подтверди оценку у советника, прежде чем использовать её.
Агрегирование: отметь любую доходность блока или домохозяйства, которая существенно не согласуется с суммой частей (когда одна позиция даёт всю доходность домохозяйства, а все остальные стоят на месте или в минусе, это сигнал, а не факт).
Сверка: сверь итог по позициям с указанной стоимостью портфеля.
Полнота: отметь любую позицию, где нет поля, от которого зависит последующий шаг (базовая стоимость, количество или метка класса активов или блока), а не исключай её молча из расчётов дрейфа или налогов.
Устаревание: отметь, когда дата оценки заметно старше остального портфеля, с которым сравнивают (обычно для частных и неликвидных позиций, которые оцениваются реже публичных): отметь расхождение, а не считай все цифры «Текущая доля %» одинаково свежими.
Дублирование: отметь, если одна и та же базовая экспозиция может быть представлена более одного раза: например, и позиция на уровне фонда, и её разложение по базовым активам попали в одну таблицу, или счёт вне системы оказался уже виден через основной коннектор.
Если что-то сработало, скажи об этом прямо и назови, какие последующие выводы (процент дрейфа, процент доходности) зависят от сомнительной цифры: никогда не позволяй плохой оценке молча попасть в таблицу дрейфа.

Шаг 2: Анализ дрейфа

Сравни текущую структуру с целевыми долями из IPS или назначенной моделью. Откуда взять цель:

IPS есть в деле: он главнее. Предпочитай брать его из подключённой учётной системы, если какая-то отдаёт его структурированно; сегодня ни одна подключённая не отдаёт (в Addepar диапазоны IPS и целей есть в самом продукте, но через MCP пока не доступны), поэтому спроси у советника диапазоны целей или прими вставленный IPS; эта инструкция обновится автоматически, когда коннектор начнёт отдавать данные IPS. Модель BlackRock здесь служит материалом для сравнения на шаге 3, а не заменой целевой структуры.
Домохозяйство ведётся по назначенной модели (по выгрузке шага 1 или названной советником): если подключён BlackRock Advisor Center (проверка подключения на шаге 3) и назначение совпадает с его набором (list_models, который содержит и сторонние модели, доступные фирме), получи цель из get_model: сверни его позиции по меткам asset_class в целевые доли блоков и перенеси дату модели as_of в таблицу дрейфа. Модель даёт только точечные цели, а никогда не диапазоны: диапазоны остаются политикой фирмы или IPS; спроси, если неизвестно.
Цели нет в деле: если подключён Advisor Center, предложи его набор вместо импровизации: покажи семейства-кандидаты и профили риска и дай советнику выбрать; никогда не выбирай за него модель или профиль риска. Подпиши таблицу дрейфа и каждую выведенную из неё цифру так: *«по сравнению с иллюстративной моделью [название], выбранной советником, — не IPS клиента»* и перенеси эту подпись в записку и в сводку для клиента. Если он откажется или коннектор не подключён, запроси диапазоны целей, как описано выше.

Названия блоков, цели и диапазоны бери из того IPS или модели, которые у тебя оказались, и не предполагай фиксированный набор классов активов. Возвращайся к таблице ниже, только когда в деле нет структуры блоков из IPS или модели:

Класс активов	Цель %	Текущая доля %	Дрейф	Избыток / нехватка, $
Акции США крупных компаний
Акции США малых и средних компаний
Развитые рынки вне США
Развивающиеся рынки
Облигации инвестиционного уровня
Высокодоходные облигации / кредит
Альтернативные инвестиции
Денежные средства

Отметь позиции, превышающие диапазон ребалансировки (по умолчанию ±5 % в абсолютном выражении или заявленный диапазон фирмы; спроси, если неизвестен). Диапазоны могут различаться по уровню ликвидности: неликвидные блоки (private equity, венчур, реальные активы) обычно имеют более широкий диапазон, чем ликвидные; используй то, что указывает IPS, а если он не различает, спроси. Выход за диапазон в неликвидном блоке — сигнал о темпе вложений по обязательствам, а не торговая инструкция: вернуть его сделками нельзя, поэтому покажи это как контекст, а не создавай изменение по нему.

Отметь также: концентрированные отдельные позиции (>10 % домохозяйства), «лежачие» деньги (cash drag) и дрейф стиля внутри класса активов.

Периодичность пересмотра IPS: сравни дату «последнего пересмотра» самого IPS с заявленной периодичностью пересмотров в фирме. Если её нет в деле, по умолчанию отмечай всё, что не пересматривалось последние 12 месяцев (обычная отраслевая норма для фидуциарных счетов), и спроси советника о фактической политике фирмы; схема та же, что с диапазоном по умолчанию выше. Отметь устаревание рядом с таблицей дрейфа, но не блокируй из-за этого ребалансировку.

Путь только анализа: если советник попросил только анализ (см. «Входные данные»), остановись здесь: выдай анализ дрейфа и резюме простым языком из шага 6 и пропусти шаги 3–5.

Шаг 3: Сопоставление с модельным портфелем

Какой источник моделей: проверь BlackRock Advisor Center так же, как шаг 1 проверяет систему портфельных данных: сначала ToolSearch по названию (никогда не гадай префикс mcp__blackrock__*), ListConnectors только чтобы объяснить пробел, и смотри на enabledInChat, а не на connected. Если подключён, бери набор моделей из list_models, а позиции выбранной модели из get_model. Если нет, работай с определением модели, которое даёт советник, а если оно не дано, скажи об этом и пропусти сопоставление, а не оценивай по предполагаемой модели. Модель BlackRock не становится автоматически целью дрейфа: если у домохозяйства есть свой IPS, модели питают только сопоставление на этом шаге. Если на шаге 2 цель была взята из назначенной или выбранной советником модели, оценивай здесь по той же модели, а не по другой.

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

Проверка условий: отказ [terms_not_acknowledged] или [terms_unavailable] при любом вызове BlackRock означает, что советник не принял (или должен принять заново) условия Advisor Center. Вызови show_terms и покажи текст условий целиком, не обобщая и не пересказывая. Когда советник явно примет их, вызови acknowledge_terms, указав в displayed_hash значение content_hash из show_terms, затем повтори исходный вызов. Никогда не вызывай show_terms или acknowledge_terms по собственной инициативе или как обычную проверку: только при реальном отказе или если советник сам спрашивает об условиях.

Если домохозяйству назначена модель, оцени текущие позиции по ней: совпавшие позиции, близкие замены и позиции-сироты.
Если модель не назначена, предложи наиболее подходящую: из набора BlackRock, когда он подключён; иначе спроси советника о наборе фирмы или используй стандартные блоки по риску: Консервативный 30/70 → Агрессивный 90/10, и покажи анализ разрыва. Любую модель или фонд от BlackRock подавай как вариант, который предлагает Advisor Center, а не как собственную рекомендацию Claude.
Выдай таблицу сопоставления: текущая позиция → позиция модели → действие (держать / заменить / продать).

Шаг 4: Подготовка ребалансировки

Определи корректировки, которые вернут домохозяйство к цели с учётом налогов:

Сначала ребалансируй в счетах с налоговыми льготами (без налоговых последствий). Если у домохозяйства их нет, скажи об этом прямо в списке вариантов и в записке, а не пропускай молча.
В облагаемых налогом счетах: избегай реализации крупной краткосрочной прибыли; реализуй доступные убытки (harvest) при ребалансировке; следи за отмывочными продажами (окно 30 дней, по каждому счёту домохозяйства, чьи позиции и историю операций ты действительно собрал: быть подключённым — не то же самое, что быть собранным; счёт вне системы, о котором советник подтвердил, что он существует, но позиций не дал, остаётся за пределами этой проверки, как и подключённый счёт, чей поток не вернул базовую стоимость или детали налоговых лотов, пробел, который уже фиксируют примечание об Addepar на шаге 1 и проверка «Полнота»). Если проверка не охватила всё домохозяйство, скажи об этом прямо: назови счета, которые она охватила, и те, которые нет, и перенеси этот же объём в строку записки об отмывочных продажах, а не пиши голое «да».
Проверь статус RMD, прежде чем продажа в IRA появится в вариантах: не создавай недобор выплаты и предпочитай использовать уже обязательный RMD как источник средств для нужной продажи вместо несвязанной.
Для концентрированной позиции с большой накопленной прибылью (embedded gain) сопоставь сокращение с вероятным горизонтом владения клиента: продажа сейчас лишает пересмотра базовой стоимости при наследовании (step-up in basis). Для пожилого или неизлечимо больного клиента это настоящий компромисс, который нужно обдумать и задокументировать, а не «сократить по умолчанию, потому что вышли за диапазон».
Предпочитай направлять ожидаемые взносы и деньги в недовзвешенные позиции вместо продаж
Учитывай ограничения клиента (ESG-фильтры, концентрированные и унаследованные акции, блокировки)

Деньги, заблокированные под вызовы капитала (путь альтернатив): если подключённая система — Addepar, вызови его инструмент предстоящей активности по частным фондам, прежде чем считать денежные остатки доступными: вычти из того, что считается деньгами для вложения, обязательства по вызовам капитала, которые приняты, но ещё не востребованы; это то же, что выход за диапазон в неликвидном блоке — сигнал о темпе, а не торговая инструкция. Покажи любой ближайший вызов как отметку или строку контекста рядом с затронутыми им денежными цифрами, а не расходуй его молча в списке вариантов. Ни одна подключённая система сейчас не даёт будущих дат вызовов для домохозяйств, которые есть только в Orion/Envestnet: отметь этот пробел, а не угадывай.

Результаты ИИ из Zocks как вход для обоснования ребалансировки: если Zocks подключён, достань его результаты и инсайты ИИ по домохозяйству и проверь, согласуются ли возможные изменения с тем, что клиент действительно выразил (заявленная терпимость к риску, жизненные события), и с IPS в деле. Отметь несоответствие прямо у конкретного изменения, к которому оно относится (например, рискованное изменение при явно заявленной низкой терпимости к риску или жизненное событие, из-за которого сам IPS мог устареть), а не общим абзацем в начале результата. Zocks — источник настроений и контекста, а не учётная книга портфеля.

Проверка исполнимости перед окончательным списком вариантов: отмечай, а не предполагай молча:

Неполные лоты (odd lots): если рассчитанное число акций не кратно круглому лоту, отметь это и предложи округлить до ближайшего круглого лота или выставить ордер в долларах.
Паевые фонды: отметь, что ордер подчиняется минимуму фонда и дневному времени отсечки по NAV; скажи советнику подтвердить и то и другое у кастодиана или компании фонда, не придумывай число.
Менее ликвидные ETF (международные, высокодоходные, муниципальные): отметь, что премию или дисконт к NAV нужно проверить в момент сделки.
Торговля одной бумагой сразу по многим домохозяйствам (блочная торговля) вне рамок этого скилла, рассчитанного на одно домохозяйство: отметь это как известное ограничение и не пытайся агрегировать.

Варианты ребалансировки:

Счёт	Действие	Бумага	Акции / $	Причина	Оценка налогового эффекта

Включи итоги: оценочные реализованные прибыли и убытки, издержки на сделки и дрейф до и после.

Примечание об исполнении: этот скилл *излагает варианты ребалансировки* и никогда ничего не исполняет. Когда коннекторы кастодианов (например, Schwab) начнут поддерживать подготовку ордеров, предложи подготовить файл ордеров, а до тех пор говори: *«Здесь я бы подготовил эти ордера в [Schwab / кастодиан], когда этот коннектор будет готов»* и выдавай список вариантов в формате загрузки кастодиана, если он известен.

Шаг 5: Записка с обоснованием ребалансировки

Для каждой ребалансировки нужна записка в файл по соблюдению требований. Используй templates/rebalance-rationale-memo.md в папке этого скилла. В ней должны быть указаны: цель клиента или ссылка на IPS, что отклонилось и почему, что меняется и почему каждая корректировка служит интересам клиента, учтённый налоговый эффект и рассмотренные альтернативы. Таблицу утверждения в шаблоне оставь пустой: ничто в этом обзоре не устанавливает, кто утвердил изменение, а советник и любой проверяющий, которого требует фирма, расписываются сами. Никогда не вписывай туда имя или дату и никогда не называй записку утверждённой.

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

Сначала запиши всё в файл markdown:

Таблица анализа дрейфа и сравнение структуры до и после
Варианты ребалансировки со сводкой налогового эффекта
Таблица сопоставления с моделью (если шаг 3 выполнялся)
Записка с обоснованием ребалансировки (по templates/rebalance-rationale-memo.md)
Резюме из 3 предложений простым языком, которое советник мог бы передать клиенту

Затем спроси советника, нужно ли выгрузить список вариантов в Excel и (или) преобразовать записку с обоснованием в Word или PDF; не создавай эти форматы, пока он не попросит.

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

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

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

Обзор может занять несколько минут, когда данные портфеля начнут проходить через шаги: скажи об этом сразу, а не спрашивай, продолжать ли; вызов скилла — уже разрешение.
Не ребалансируй ради ребалансировки: дрейф внутри диапазонов допустим; налоговые издержки могут превысить выгоду. Показывай точку безубыточности, когда она близка.
Проверяй ожидаемые денежные потоки (взносы, изъятия, RMD), прежде чем продажа появится в вариантах.
Любой результат по покупкам и продажам — черновик для проверки советником, варианты, которые советник взвешивает, а не рекомендация: за пригодность и лучшее исполнение отвечает советник.
Документируй всё: записка с обоснованием — элемент книг и учётных записей; любую сводку для клиента прогони через /compliance.
Согласуй отмывочные продажи по каждому счёту домохозяйства, чьи позиции и детали налоговых лотов ты действительно собрал: по счёту вне системы, когда советник даст его позиции, по подключённому счёту, когда его поток действительно вернёт базовую стоимость. Говори об этом, когда проверка не смогла охватить все.
Считай данные клиентского портфеля и счетов конфиденциальными; включай только то, что нужно для этого обзора.

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

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

---
name: portfolio-rebalance-review
description: Run a portfolio review for a client or household — performance pulled from Orion, allocation drift analysis vs. IPS or model portfolio, model-portfolio mapping, rebalance preparation with tax-aware rebalance opportunities to consider, and a rebalance rationale memo for the compliance file. Triggers on "portfolio review", "/portfolio-rebalance-review", "drift analysis", "rebalance [client]", "how is [client]'s portfolio positioned", "rebalance rationale", or "map [client] to a model".
---

# Portfolio Rebalance Review

Review a client portfolio end to end: performance → drift → model mapping → rebalance prep → rebalance rationale memo.

## Inputs

Required: **client/household name**. Optional: which accounts to include, the model portfolio or IPS targets (if not on file), and whether the advisor wants analysis only or a full rebalance prep.

## Step 1: Pull Performance & Holdings

**Disambiguation rule:** confirm which household before pulling anything, the same as every other skill in this plugin — if a name search returns more than one match, show the advisor the candidates and ask which one before proceeding. Never proceed on a name match alone.

Query the household's connected portfolio-data system for:
- Accounts with registrations (taxable, IRA, Roth, 401k, trust) and market values
- Holdings with quantity, market value, cost basis, and unrealized gain/loss
- Performance: QTD/YTD/1yr/3yr vs. assigned benchmark, net of fees
- Assigned model/target allocation and cash balances
- Recent flows (contributions, distributions, RMD status)

**Which system to query:** this data can live in Orion, Addepar, or Envestnet/Tamarac depending on the firm. Check `ListConnectors` (load via `ToolSearch` if not already available) to see which is actually connected — don't guess at tool-name prefixes, use `ToolSearch` by system name once you know which is live.

**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.
- **If none is connected**: follow the Connector Placeholder Convention — say *"This is where I'd make a call out to [system] to pull [holdings/performance] once that connector is built,"* then offer the fallback. Before asking for a manual upload, offer to search Google Drive (if connected) for an existing export or statement. If nothing turns up there either, ask the advisor to upload an export (CSV/PDF), a custodian statement, or paste holdings. Continue with whatever's provided, and mark anything still missing "— pending [connector]" rather than leaving it blank — a missing source degrades only the section that depends on it, not the whole review.
- **If more than one connected tool could try to solve this for the household**, ask the advisor once which is the book of record — per the Ask-Once, Then Route Convention — rather than guessing or merging both, and use that system for the rest of this review. This applies even when the household name hasn't resolved against either system yet: ask before searching further, not after finding out neither recognizes the name — an unresolved household is not an exception to this rule. Offer to help the advisor save the choice using the Personalization Convention so they aren't asked again next session. This check runs for the rest of the review, not just once up front — if the advisor brings up another source mid-review, ask before pulling from it too. And if a second system's figures get pulled anyway and disagree with the routed one on a material fact (a balance, a drift percentage), that's a blocking question for the advisor, not a note in the output.

**Held-away accounts:** ask the advisor whether the household has accounts held away from this system (a spouse's 401k, assets at another custodian) relevant to wash-sale coordination or the overall allocation picture. If yes, request those holdings manually — there's no connector for outside accounts.

**Addepar specifics:** call `get_portfolio_data` with `lookthrough=false` for drift purposes. Lookthrough decomposition (fund → underlying constituents) is a separate risk-review lens — an IPS names sleeves at the fund-commitment level, and lookthrough silently returns an incompatible set of buckets with no warning. Group by `direct_owner`, not `account` — the latter is not a valid grouping key and errors. For tax-lot detail, pass a tax-lot value in `groupings` only if the live tool schema actually documents one — cost basis and lot-level fields are not confirmed to exist on every Addepar deployment. If the schema doesn't support it or the returned columns don't include cost basis, say so explicitly rather than presenting fabricated lot data; this feeds the same "Completeness" gate below.

**Orion specifics:** Orion Connect's tools (household search, report catalog, report parameters, `oc_generate_report`) are identity and report-catalog/generation only — they do not return structured holdings, cost basis, or tax lots. Generating a report yields a **link to the finished report**, not its contents — hand it to the advisor and say it **expires after 24 hours** (a unique per-run URL; regenerate rather than troubleshoot an expired one); don't fetch it to scrape a holdings table out of, and don't treat having produced a link as having read the data. If Orion is the only connected system, holdings/cost-basis data has to come from the advisor (upload/paste) rather than being inferred from a report. If Orion later ships a structured holdings or cost-basis tool, wire it into this same Step 1 data shape alongside Addepar.

**Before generating an Orion report:** confirm with the advisor first — `oc_generate_report` runs a job in Orion Connect rather than reading from it. No confirmation is needed for household search, the report catalog, or report-parameter lookups; those are identity/catalog calls, not report generation.

**Data-sanity gate — run before Step 2, don't skip.** Dispatch this to the `claude-for-financial-advisors:holdings-sanity` subagent — `Agent(claude-for-financial-advisors:holdings-sanity)` — rather than working through it inline: hand it the holdings data, the reported portfolio/household value, and the sleeve structure from the IPS or model if one is on file. It returns a flag table with a `Contaminates` column naming which downstream figure each problem feeds, plus an explicit list of the checks that passed.

Act on what comes back before touching Step 2. A `BLOCKING` verdict means a flag would corrupt the drift table itself — resolve it with the advisor first. `FLAGS` means the review continues with the caveats carried into the output. The subagent never repairs data, drops a position, or estimates a missing field, so anything it raises is still yours to decide about.

The seven checks it runs, which are also the checks to run by hand if the subagent is unavailable:
- **Temporal:** flag any position whose valuation date precedes its first funding/contribution transaction.
- **Magnitude:** flag any position whose gain looks implausible for the asset type and time held (e.g. a private fund up several multiples within months of being funded) and confirm the mark with the advisor before using it.
- **Aggregation:** flag any sleeve or household-level return that's materially inconsistent with the sum of its parts (one position driving the whole household return while everything else is flat/negative is a signal, not a fact).
- **Reconciliation:** reconcile the holdings total against the reported portfolio value.
- **Completeness:** flag any position missing a field a later step depends on — cost basis, quantity, or an asset-class/sleeve tag — rather than silently excluding it from drift or tax calculations.
- **Staleness:** flag when a mark's as-of date is materially older than the rest of the portfolio it's being compared against (common for private/illiquid holdings priced less often than public ones) — note the mismatch rather than treating all "Current %" figures as equally current.
- **Duplication:** flag if the same underlying exposure may be represented more than once — e.g. a fund-level position and its lookthrough decomposition both pulled into the same table, or a held-away account that turns out to already be visible through the primary connector.
- If anything trips, say so explicitly and state which downstream conclusions (drift %, performance %) depend on the suspect figure — never let a bad mark flow silently into the drift table.

## Step 2: Drift Analysis

Compare current allocation to the IPS targets / assigned model. **Sourcing the target:**

- **IPS on file — the IPS governs.** Prefer pulling it from the connected system of record if one exposes it as structured data; today no connected system does (Addepar has IPS/target bands in-product but doesn't expose them over MCP yet), so ask the advisor for target bands or accept a pasted IPS — this instruction upgrades automatically once a connector exposes IPS data. A BlackRock model is comparison material for Step 3 here, never a substitute target.
- **Household managed to an assigned model** (per Step 1's pull or the advisor naming one): if BlackRock Advisor Center is connected (Step 3's connection check) and the assignment matches its lineup (`list_models` — which also carries the firm's entitled third-party models), hydrate the target from `get_model`: roll its holdings up by their `asset_class` tags into sleeve targets and carry the model's `as_of` date into the drift table. The model supplies point targets only, never bands — bands stay firm/IPS policy; ask if unknown.
- **No target on file:** if Advisor Center is connected, offer its lineup rather than improvising — show candidate families and risk profiles and let the advisor pick; never select a model or a risk profile for them. Label the drift table and every figure derived from it *"vs. advisor-selected illustrative model [name] — not a client IPS"*, and carry that label into the memo and the client-facing summary. If they decline, or it isn't connected, ask for target bands as above.

Source sleeve names, targets, and bands from whatever IPS/model you end up with — don't assume a fixed set of asset classes. Fall back to the table below only when no IPS/model sleeve structure is on file:

| Asset Class | Target % | Current % | Drift | $ Over/Under |
|------------|----------|-----------|-------|-------------|
| US Large Cap Equity | | | | |
| US Small/Mid Cap | | | | |
| International Developed | | | | |
| Emerging Markets | | | | |
| Investment Grade Bonds | | | | |
| High Yield / Credit | | | | |
| Alternatives | | | | |
| Cash | | | | |

Flag positions exceeding the rebalancing band (default ±5% absolute or the firm's stated band — ask if unknown). **Bands may differ by liquidity tier** — illiquid sleeves (private equity, venture, real assets) typically carry a wider band than liquid ones; use what the IPS specifies, ask if it doesn't distinguish. A breach in an illiquid sleeve is a commitment-pacing signal, not a trade instruction — it can't be traded back — so surface it as context rather than generating a change against it.

Also flag: concentrated single positions (>10% of household), cash drag, and style drift within an asset class.

**IPS review cadence:** check the IPS's own "last reviewed" date against the firm's stated review cadence. If none is on file, default to flagging anything not reviewed in the last 12 months (a common industry norm for fiduciary accounts) and ask the advisor for the firm's actual policy — same pattern as the band default above. Note staleness alongside the drift table; don't block the rebalance on it.

**Analysis-only path:** if the advisor asked for analysis only (see Inputs), stop here — output the drift analysis and the plain-English summary from Step 6, and skip Steps 3–5.

## Step 3: Model-Portfolio Mapping

**Which model source:** check for BlackRock Advisor Center the same way Step 1
checks for a portfolio-data system — `ToolSearch` by name first (never guess
an `mcp__blackrock__*` prefix), `ListConnectors` only to explain a gap, and
read `enabledInChat` rather than `connected`. If it's connected, source the
model lineup from `list_models` and the chosen model's holdings from
`get_model`. If it isn't, work from the model definition the advisor supplies
— and if none is supplied, say so and skip the mapping rather than scoring
against an assumed model. **A BlackRock model is not automatically the drift
target** — when the household has its own IPS, models feed only this step's
mapping. When Step 2 sourced the target from an assigned or advisor-selected
model, score against that same model here, never a different one.

**Advisor Center's MCP doesn't expose synced client accounts today:** its
"households" are proposal groupings, and accounts imported or synced from the
book of business aren't readable over MCP yet — so don't look a client
household up there; this instruction upgrades automatically once the MCP
exposes synced accounts. Independent of that: never offer to create or update
anything there — `create_portfolio` and every other Advisor Center write is
out of scope for this skill.

**Terms gate:** a `[terms_not_acknowledged]` or `[terms_unavailable]` refusal
from any BlackRock call means the advisor hasn't accepted (or needs to
re-accept) Advisor Center's terms. Call `show_terms` and present the terms
text in full — never summarized or paraphrased. Once the advisor explicitly
accepts, call `acknowledge_terms` with `displayed_hash` set to `show_terms`'s
`content_hash`, then retry the original call. Never call `show_terms` or
`acknowledge_terms` on your own initiative or as a routine check — only on an
actual refusal, or if the advisor asks about terms directly.

- If the household is assigned a model, score current holdings against it: matched positions, close substitutes, and orphan positions.
- If no model is assigned, propose the best-fit model — from BlackRock's lineup when connected, otherwise ask the advisor for the firm's lineup or use standard risk-based sleeves: Conservative 30/70 → Aggressive 90/10 — and show the gap analysis. Present any BlackRock-sourced model or fund suggestion as an option Advisor Center is offering, not as Claude's own recommendation.
- Output a mapping table: current holding → model position → action (hold / substitute / sell).

## Step 4: Rebalance Prep

Identify the adjustments that would bring the household back to target, tax-aware:
- Rebalance in tax-advantaged accounts first (no tax consequences). If the household has none, say so explicitly in the options list and memo rather than silently skipping this.
- In taxable accounts: avoid realizing large short-term gains; harvest available losses while rebalancing; watch wash sales (30-day window, across every household account whose holdings and transaction history you **actually gathered** — being connected is not the same as being gathered: a held-away account the advisor confirmed exists but never supplied holdings for sits outside that check, and so does a connected account whose feed returned no cost basis or tax-lot detail, the gap Step 1's Addepar note and Completeness check already record). Where the check couldn't reach the whole household, say so plainly: name the accounts it covered and the ones it didn't, and carry that same scope into the memo's wash-sale line rather than a bare "yes".
- Check RMD status before an IRA sell appears in the options — don't create a distribution shortfall, and prefer using an already-required RMD as the funding source for a needed sale over an unrelated one.
- For a concentrated position with a large embedded gain, weigh trimming against the client's likely holding horizon: selling now forfeits any step-up in basis at death. For an elderly or terminally-ill client this is a real tradeoff to reason through and document, not a default "trim because it's outside the band."
- Prefer directing pending contributions/cash to underweights over selling
- Respect client restrictions (ESG screens, concentrated/legacy stock, lockups)

**Cash locked for capital calls (alts path):** if Addepar is the connected system, call its upcoming private-fund capital-activity tool before treating cash balances as available — net out committed-but-uncalled capital-call obligations from what counts as deployable cash, same as an illiquid-sleeve band breach is a pacing signal rather than a trade instruction. Surface any near-term call as a flag/context line next to the cash figures it affects, don't silently consume it into the options list. No connected system currently supplies forward-looking call dates for Orion/Envestnet-only households — note that gap rather than guessing.

**Zocks AI results as a rebalance-rationale input:** if Zocks is connected, pull its AI results/insights for the household and check whether the potential changes line up with what the client has actually expressed — stated risk tolerance, life events — and with the IPS on file. Flag a mismatch inline against the specific change it bears on (e.g. a risky change against an explicitly stated low risk tolerance, or a life event suggesting the IPS itself may be stale), not as a general blurb at the top of the output. Zocks is a sentiment/context source, never a portfolio book of record.

**Execution feasibility check** before finalizing the options list — flag, don't silently assume:
- Odd lots: if a computed share count isn't a round lot, note it and suggest rounding to the nearest round lot or a dollar-based order.
- Mutual funds: flag that the order is subject to the fund's minimum and daily NAV cutoff — tell the advisor to confirm both with the custodian/fund company, don't assume a number.
- Less-liquid ETFs (international, high-yield, muni): flag that premium/discount to NAV should be checked at time of trade.
- Trading the same security across many households at once (block trading) is out of scope for this skill's single-household design — note it as a known limitation, don't attempt to aggregate.

**Rebalancing options:**

| Account | Action | Security | Shares/$ | Reason | Est. Tax Impact |
|---------|--------|----------|----------|--------|-----------------|

Include totals: estimated realized gains/losses, transaction costs, and before/after drift.

**Execution note:** this skill *lays out rebalancing options*; it never executes anything. Once custodian connectors (e.g., Schwab) support order staging, offer to stage the order file — until then say: *"This is where I'd stage these orders to [Schwab/custodian] once that connector is built"* and output the options list in the custodian's upload format if known.

## Step 5: Rebalance Rationale Memo

Every rebalance gets a memo for the compliance file. Use `templates/rebalance-rationale-memo.md` in this skill's folder. It must state: client objective/IPS reference, what drifted and why, what is being changed and why each adjustment serves the client's interest, tax impact considered, and alternatives considered. Leave the template's Approval table empty — nothing in this review establishes who approved a change, and the advisor and any reviewer the firm requires sign for themselves. Never fill in a name or a date there, and never describe the memo as approved.

## Step 6: Output

Write everything to a markdown file first:
- Drift analysis table + before/after allocation comparison
- Rebalancing options with tax impact summary
- Model mapping table (if Step 3 ran)
- Rebalance rationale memo (using `templates/rebalance-rationale-memo.md`)
- 3-sentence plain-English summary the advisor could relay to the client

Then ask the advisor whether they'd like the options list exported to Excel and/or the rationale memo converted to Word/PDF — don't create those formats unless they ask.

## Out of Scope (for now)

- **No trade execution.** This skill prepares options for advisor review; it never places an order.
- **No fabricating holdings, lots, or cost basis.** When a connected source doesn't confirm a figure, say so — never fill the gap with an invented number.
- **No suitability or legal determination.** This skill surfaces drift, tax impact, and rationale for the advisor to weigh — it never states that a portfolio is or isn't suitable.

## Important Notes

- This review can take a few minutes once portfolio data starts flowing across steps — say so up front rather than asking whether to proceed; invoking the skill is already the go-ahead.
- Don't rebalance for rebalancing's sake — drift within bands is fine; tax costs can exceed the benefit. Show the breakeven when it's close.
- Check pending cash flows (contributions, withdrawals, RMDs) before a sell appears in the options.
- All buy/sell output is **a draft for advisor review — options laid out for the advisor to weigh, not advice** — the advisor owns suitability and best execution.
- Document everything: the rationale memo is a books-and-records item; run any client-facing summary through **/compliance**.
- Coordinate wash sales across every household account whose holdings and tax-lot detail you actually gathered — a held-away account once the advisor supplies its holdings, a connected account once its feed actually returns cost basis — and say so when the check couldn't cover them all.
- Treat client portfolio and account data as confidential; only include what's needed for this review.

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

---
name: portfolio-rebalance-review
description: Проводит обзор портфеля клиента или домохозяйства: доходность из Orion, анализ дрейфа структуры относительно IPS или модельного портфеля, сопоставление с модельным портфелем, подготовка ребалансировки с налоговыми возможностями, которые стоит рассмотреть, и записка с обоснованием ребалансировки для файла по соблюдению требований. Срабатывает на «обзор портфеля», «/portfolio-rebalance-review», «анализ дрейфа», «ребалансируй [клиент]», «как расположен портфель [клиент]», «обоснование ребалансировки» или «подбери [клиент] модель».
---

# Обзор портфеля и ребалансировка

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

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

Обязательно: **имя клиента или домохозяйства**. Необязательно: какие счета включить, модельный портфель или целевые доли из IPS (если их нет в деле) и хочет ли советник только анализ или полную подготовку ребалансировки.

## Шаг 1: Достань доходность и позиции

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

Запроси в подключённой системе портфельных данных домохозяйства:
- Счета с регистрациями (облагаемый налогом, IRA, Roth, 401k, траст) и рыночной стоимостью
- Позиции с количеством, рыночной стоимостью, базовой стоимостью (cost basis) и нереализованной прибылью или убытком
- Доходность: QTD/YTD/1 год/3 года против назначенного бенчмарка, после комиссий
- Назначенная модель или целевая структура и денежные остатки
- Недавние потоки (взносы, выплаты, статус RMD)

**Какую систему запрашивать:** эти данные могут лежать в Orion, Addepar или Envestnet/Tamarac в зависимости от фирмы. Проверь `ListConnectors` (загрузи через `ToolSearch`, если он ещё недоступен), чтобы увидеть, какая реально подключена: не гадай префиксы имён инструментов, а когда узнаешь, какая работает, ищи через `ToolSearch` по названию системы.

**Ищи инструменты, прежде чем верить реестру.** Решает проверка через `ToolSearch` по названию самой системы: если её инструменты нашлись, система подключена и доступна, используй их. `ListConnectors` может ответить «Установленные коннекторы не найдены» даже в сессии с несколькими работающими живыми коннекторами, а в некоторых клиентах он выводит карточку для пользователя вместо данных. Поэтому он объясняет пробел, но никогда не устанавливает его, и пустой результат означает **неизвестно**, а не «ничего не подключено». Когда он всё же возвращает записи, смотри на `enabledInChat`, а не на `connected`: `connected: true` при `enabledInChat: false` означает, что вход выполнен, но для этого чата коннектор выключен. Скажи советнику, что он может включить его здесь, а не сообщай, что коннектор не подключён; отсутствующее или равное `null` значение `connected` — это неизвестно, а не «отключён».
- **Если не подключена ни одна**: следуй правилу заглушки коннектора (Connector Placeholder Convention) и скажи *«Здесь я бы обратился к [система], чтобы получить [позиции/доходность], когда этот коннектор будет готов»*, затем предложи запасной вариант. Прежде чем просить загрузить файл вручную, предложи поискать на Google Диске (если он подключён) уже существующую выгрузку или выписку. Если и там ничего нет, попроси советника загрузить выгрузку (CSV/PDF), выписку кастодиана или вставить позиции. Продолжай с тем, что дали, а всё ещё отсутствующее помечай «— ожидает [коннектор]», а не оставляй пустым: отсутствующий источник ухудшает только зависящий от него раздел, а не весь обзор.
- **Если эту задачу для домохозяйства могут решить несколько подключённых инструментов**, один раз спроси советника, какой из них считать основным учётным (book of record), по правилу «Спроси один раз, дальше маршрутизируй» (Ask-Once, Then Route Convention), а не угадывай и не объединяй обе, и используй эту систему до конца обзора. Это действует, даже если имя домохозяйства ещё не нашлось ни в одной из систем: спроси до дальнейшего поиска, а не после того, как выяснится, что ни одна не узнаёт имя: неопределённое домохозяйство не исключение из этого правила. Предложи помочь советнику сохранить выбор по правилу персонализации (Personalization Convention), чтобы в следующей сессии не спрашивать снова. Эта проверка действует до конца обзора, а не только один раз в начале: если советник посреди обзора назовёт ещё один источник, спроси и до того, как брать данные из него. А если цифры второй системы всё же были вытянуты и расходятся с основной по существенному факту (остаток, процент дрейфа), это блокирующий вопрос к советнику, а не примечание в результате.

**Счета вне системы (held-away):** спроси советника, есть ли у домохозяйства счета, хранящиеся вне этой системы (401k супруга, активы у другого кастодиана), которые важны для согласования правила отмывочных продаж (wash sale) или для общей картины структуры. Если да, запроси эти позиции вручную: коннектора для внешних счетов нет.

**Особенности Addepar:** вызывай `get_portfolio_data` с `lookthrough=false` для целей дрейфа. Разложение по базовым активам (lookthrough: фонд → составляющие) — это отдельный взгляд на риск: IPS называет блоки (sleeves) на уровне обязательств перед фондами, а lookthrough молча возвращает несовместимый набор корзин без предупреждения. Группируй по `direct_owner`, а не по `account`: последнее не является допустимым ключом группировки и приводит к ошибке. Для детализации по налоговым лотам передавай значение налогового лота в `groupings` только если живая схема инструмента действительно его описывает: базовая стоимость и поля уровня лота существуют не на каждом развёртывании Addepar. Если схема этого не поддерживает или в возвращённых столбцах нет базовой стоимости, скажи об этом прямо, а не выдавай выдуманные данные по лотам; это питает ту же проверку «Полнота» ниже.

**Особенности Orion:** инструменты Orion Connect (поиск домохозяйства, каталог отчётов, параметры отчётов, `oc_generate_report`) касаются только идентификации, каталога отчётов и их формирования: они не возвращают структурированные позиции, базовую стоимость и налоговые лоты. Формирование отчёта даёт **ссылку на готовый отчёт**, а не его содержание: передай её советнику и скажи, что она **истекает через 24 часа** (уникальный адрес на каждый запуск; сформируй заново, а не разбирайся с просроченным); не загружай её, чтобы вытащить таблицу позиций, и не считай, что выдача ссылки равна прочтению данных. Если Orion — единственная подключённая система, данные о позициях и базовой стоимости придётся получить от советника (загрузка или вставка), а не выводить из отчёта. Если Orion позже выпустит инструмент структурированных позиций или базовой стоимости, подключи его в ту же форму данных шага 1 рядом с Addepar.

**Перед формированием отчёта в Orion:** сначала подтверди у советника: `oc_generate_report` запускает задание в Orion Connect, а не читает из него. Подтверждение не нужно для поиска домохозяйства, каталога отчётов и запросов параметров отчётов: это вызовы идентификации и каталога, а не формирования отчёта.

**Проверка данных на здравый смысл: выполни до шага 2, не пропускай.** Отдай её субагенту `claude-for-financial-advisors:holdings-sanity`, то есть `Agent(claude-for-financial-advisors:holdings-sanity)`, а не проходи вручную: передай ему данные по позициям, указанную стоимость портфеля или домохозяйства и структуру блоков из IPS или модели, если она есть. Он вернёт таблицу отметок со столбцом `Contaminates` (что портит), в котором названо, какую последующую цифру питает каждая проблема, а также прямой список проверок, которые прошли.

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

Семь проверок, которые он проводит и которые нужно провести вручную, если субагент недоступен:
- **Временная:** отметь любую позицию, у которой дата оценки раньше первой операции финансирования или взноса.
- **Масштаб:** отметь любую позицию, у которой прибыль выглядит неправдоподобной для типа актива и срока владения (например, частный фонд вырос в несколько раз через несколько месяцев после финансирования), и подтверди оценку у советника, прежде чем использовать её.
- **Агрегирование:** отметь любую доходность блока или домохозяйства, которая существенно не согласуется с суммой частей (когда одна позиция даёт всю доходность домохозяйства, а все остальные стоят на месте или в минусе, это сигнал, а не факт).
- **Сверка:** сверь итог по позициям с указанной стоимостью портфеля.
- **Полнота:** отметь любую позицию, где нет поля, от которого зависит последующий шаг (базовая стоимость, количество или метка класса активов или блока), а не исключай её молча из расчётов дрейфа или налогов.
- **Устаревание:** отметь, когда дата оценки заметно старше остального портфеля, с которым сравнивают (обычно для частных и неликвидных позиций, которые оцениваются реже публичных): отметь расхождение, а не считай все цифры «Текущая доля %» одинаково свежими.
- **Дублирование:** отметь, если одна и та же базовая экспозиция может быть представлена более одного раза: например, и позиция на уровне фонда, и её разложение по базовым активам попали в одну таблицу, или счёт вне системы оказался уже виден через основной коннектор.
- Если что-то сработало, скажи об этом прямо и назови, какие последующие выводы (процент дрейфа, процент доходности) зависят от сомнительной цифры: никогда не позволяй плохой оценке молча попасть в таблицу дрейфа.

## Шаг 2: Анализ дрейфа

Сравни текущую структуру с целевыми долями из IPS или назначенной моделью. **Откуда взять цель:**

- **IPS есть в деле: он главнее.** Предпочитай брать его из подключённой учётной системы, если какая-то отдаёт его структурированно; сегодня ни одна подключённая не отдаёт (в Addepar диапазоны IPS и целей есть в самом продукте, но через MCP пока не доступны), поэтому спроси у советника диапазоны целей или прими вставленный IPS; эта инструкция обновится автоматически, когда коннектор начнёт отдавать данные IPS. Модель BlackRock здесь служит материалом для сравнения на шаге 3, а не заменой целевой структуры.
- **Домохозяйство ведётся по назначенной модели** (по выгрузке шага 1 или названной советником): если подключён BlackRock Advisor Center (проверка подключения на шаге 3) и назначение совпадает с его набором (`list_models`, который содержит и сторонние модели, доступные фирме), получи цель из `get_model`: сверни его позиции по меткам `asset_class` в целевые доли блоков и перенеси дату модели `as_of` в таблицу дрейфа. Модель даёт только точечные цели, а никогда не диапазоны: диапазоны остаются политикой фирмы или IPS; спроси, если неизвестно.
- **Цели нет в деле:** если подключён Advisor Center, предложи его набор вместо импровизации: покажи семейства-кандидаты и профили риска и дай советнику выбрать; никогда не выбирай за него модель или профиль риска. Подпиши таблицу дрейфа и каждую выведенную из неё цифру так: *«по сравнению с иллюстративной моделью [название], выбранной советником, — не IPS клиента»* и перенеси эту подпись в записку и в сводку для клиента. Если он откажется или коннектор не подключён, запроси диапазоны целей, как описано выше.

Названия блоков, цели и диапазоны бери из того IPS или модели, которые у тебя оказались, и не предполагай фиксированный набор классов активов. Возвращайся к таблице ниже, только когда в деле нет структуры блоков из IPS или модели:

| Класс активов | Цель % | Текущая доля % | Дрейф | Избыток / нехватка, $ |
|---------------|--------|----------------|-------|-----------------------|
| Акции США крупных компаний | | | | |
| Акции США малых и средних компаний | | | | |
| Развитые рынки вне США | | | | |
| Развивающиеся рынки | | | | |
| Облигации инвестиционного уровня | | | | |
| Высокодоходные облигации / кредит | | | | |
| Альтернативные инвестиции | | | | |
| Денежные средства | | | | |

Отметь позиции, превышающие диапазон ребалансировки (по умолчанию ±5 % в абсолютном выражении или заявленный диапазон фирмы; спроси, если неизвестен). **Диапазоны могут различаться по уровню ликвидности:** неликвидные блоки (private equity, венчур, реальные активы) обычно имеют более широкий диапазон, чем ликвидные; используй то, что указывает IPS, а если он не различает, спроси. Выход за диапазон в неликвидном блоке — сигнал о темпе вложений по обязательствам, а не торговая инструкция: вернуть его сделками нельзя, поэтому покажи это как контекст, а не создавай изменение по нему.

Отметь также: концентрированные отдельные позиции (>10 % домохозяйства), «лежачие» деньги (cash drag) и дрейф стиля внутри класса активов.

**Периодичность пересмотра IPS:** сравни дату «последнего пересмотра» самого IPS с заявленной периодичностью пересмотров в фирме. Если её нет в деле, по умолчанию отмечай всё, что не пересматривалось последние 12 месяцев (обычная отраслевая норма для фидуциарных счетов), и спроси советника о фактической политике фирмы; схема та же, что с диапазоном по умолчанию выше. Отметь устаревание рядом с таблицей дрейфа, но не блокируй из-за этого ребалансировку.

**Путь только анализа:** если советник попросил только анализ (см. «Входные данные»), остановись здесь: выдай анализ дрейфа и резюме простым языком из шага 6 и пропусти шаги 3–5.

## Шаг 3: Сопоставление с модельным портфелем

**Какой источник моделей:** проверь BlackRock Advisor Center так же, как шаг 1 проверяет систему портфельных данных: сначала `ToolSearch` по названию (никогда не гадай префикс `mcp__blackrock__*`), `ListConnectors` только чтобы объяснить пробел, и смотри на `enabledInChat`, а не на `connected`. Если подключён, бери набор моделей из `list_models`, а позиции выбранной модели из `get_model`. Если нет, работай с определением модели, которое даёт советник, а если оно не дано, скажи об этом и пропусти сопоставление, а не оценивай по предполагаемой модели. **Модель BlackRock не становится автоматически целью дрейфа:** если у домохозяйства есть свой IPS, модели питают только сопоставление на этом шаге. Если на шаге 2 цель была взята из назначенной или выбранной советником модели, оценивай здесь по той же модели, а не по другой.

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

**Проверка условий:** отказ `[terms_not_acknowledged]` или `[terms_unavailable]` при любом вызове BlackRock означает, что советник не принял (или должен принять заново) условия Advisor Center. Вызови `show_terms` и покажи текст условий целиком, не обобщая и не пересказывая. Когда советник явно примет их, вызови `acknowledge_terms`, указав в `displayed_hash` значение `content_hash` из `show_terms`, затем повтори исходный вызов. Никогда не вызывай `show_terms` или `acknowledge_terms` по собственной инициативе или как обычную проверку: только при реальном отказе или если советник сам спрашивает об условиях.

- Если домохозяйству назначена модель, оцени текущие позиции по ней: совпавшие позиции, близкие замены и позиции-сироты.
- Если модель не назначена, предложи наиболее подходящую: из набора BlackRock, когда он подключён; иначе спроси советника о наборе фирмы или используй стандартные блоки по риску: Консервативный 30/70 → Агрессивный 90/10, и покажи анализ разрыва. Любую модель или фонд от BlackRock подавай как вариант, который предлагает Advisor Center, а не как собственную рекомендацию Claude.
- Выдай таблицу сопоставления: текущая позиция → позиция модели → действие (держать / заменить / продать).

## Шаг 4: Подготовка ребалансировки

Определи корректировки, которые вернут домохозяйство к цели с учётом налогов:
- Сначала ребалансируй в счетах с налоговыми льготами (без налоговых последствий). Если у домохозяйства их нет, скажи об этом прямо в списке вариантов и в записке, а не пропускай молча.
- В облагаемых налогом счетах: избегай реализации крупной краткосрочной прибыли; реализуй доступные убытки (harvest) при ребалансировке; следи за отмывочными продажами (окно 30 дней, по каждому счёту домохозяйства, чьи позиции и историю операций ты **действительно собрал**: быть подключённым — не то же самое, что быть собранным; счёт вне системы, о котором советник подтвердил, что он существует, но позиций не дал, остаётся за пределами этой проверки, как и подключённый счёт, чей поток не вернул базовую стоимость или детали налоговых лотов, пробел, который уже фиксируют примечание об Addepar на шаге 1 и проверка «Полнота»). Если проверка не охватила всё домохозяйство, скажи об этом прямо: назови счета, которые она охватила, и те, которые нет, и перенеси этот же объём в строку записки об отмывочных продажах, а не пиши голое «да».
- Проверь статус RMD, прежде чем продажа в IRA появится в вариантах: не создавай недобор выплаты и предпочитай использовать уже обязательный RMD как источник средств для нужной продажи вместо несвязанной.
- Для концентрированной позиции с большой накопленной прибылью (embedded gain) сопоставь сокращение с вероятным горизонтом владения клиента: продажа сейчас лишает пересмотра базовой стоимости при наследовании (step-up in basis). Для пожилого или неизлечимо больного клиента это настоящий компромисс, который нужно обдумать и задокументировать, а не «сократить по умолчанию, потому что вышли за диапазон».
- Предпочитай направлять ожидаемые взносы и деньги в недовзвешенные позиции вместо продаж
- Учитывай ограничения клиента (ESG-фильтры, концентрированные и унаследованные акции, блокировки)

**Деньги, заблокированные под вызовы капитала (путь альтернатив):** если подключённая система — Addepar, вызови его инструмент предстоящей активности по частным фондам, прежде чем считать денежные остатки доступными: вычти из того, что считается деньгами для вложения, обязательства по вызовам капитала, которые приняты, но ещё не востребованы; это то же, что выход за диапазон в неликвидном блоке — сигнал о темпе, а не торговая инструкция. Покажи любой ближайший вызов как отметку или строку контекста рядом с затронутыми им денежными цифрами, а не расходуй его молча в списке вариантов. Ни одна подключённая система сейчас не даёт будущих дат вызовов для домохозяйств, которые есть только в Orion/Envestnet: отметь этот пробел, а не угадывай.

**Результаты ИИ из Zocks как вход для обоснования ребалансировки:** если Zocks подключён, достань его результаты и инсайты ИИ по домохозяйству и проверь, согласуются ли возможные изменения с тем, что клиент действительно выразил (заявленная терпимость к риску, жизненные события), и с IPS в деле. Отметь несоответствие прямо у конкретного изменения, к которому оно относится (например, рискованное изменение при явно заявленной низкой терпимости к риску или жизненное событие, из-за которого сам IPS мог устареть), а не общим абзацем в начале результата. Zocks — источник настроений и контекста, а не учётная книга портфеля.

**Проверка исполнимости** перед окончательным списком вариантов: отмечай, а не предполагай молча:
- Неполные лоты (odd lots): если рассчитанное число акций не кратно круглому лоту, отметь это и предложи округлить до ближайшего круглого лота или выставить ордер в долларах.
- Паевые фонды: отметь, что ордер подчиняется минимуму фонда и дневному времени отсечки по NAV; скажи советнику подтвердить и то и другое у кастодиана или компании фонда, не придумывай число.
- Менее ликвидные ETF (международные, высокодоходные, муниципальные): отметь, что премию или дисконт к NAV нужно проверить в момент сделки.
- Торговля одной бумагой сразу по многим домохозяйствам (блочная торговля) вне рамок этого скилла, рассчитанного на одно домохозяйство: отметь это как известное ограничение и не пытайся агрегировать.

**Варианты ребалансировки:**

| Счёт | Действие | Бумага | Акции / $ | Причина | Оценка налогового эффекта |
|------|----------|--------|-----------|---------|---------------------------|

Включи итоги: оценочные реализованные прибыли и убытки, издержки на сделки и дрейф до и после.

**Примечание об исполнении:** этот скилл *излагает варианты ребалансировки* и никогда ничего не исполняет. Когда коннекторы кастодианов (например, Schwab) начнут поддерживать подготовку ордеров, предложи подготовить файл ордеров, а до тех пор говори: *«Здесь я бы подготовил эти ордера в [Schwab / кастодиан], когда этот коннектор будет готов»* и выдавай список вариантов в формате загрузки кастодиана, если он известен.

## Шаг 5: Записка с обоснованием ребалансировки

Для каждой ребалансировки нужна записка в файл по соблюдению требований. Используй `templates/rebalance-rationale-memo.md` в папке этого скилла. В ней должны быть указаны: цель клиента или ссылка на IPS, что отклонилось и почему, что меняется и почему каждая корректировка служит интересам клиента, учтённый налоговый эффект и рассмотренные альтернативы. Таблицу утверждения в шаблоне оставь пустой: ничто в этом обзоре не устанавливает, кто утвердил изменение, а советник и любой проверяющий, которого требует фирма, расписываются сами. Никогда не вписывай туда имя или дату и никогда не называй записку утверждённой.

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

Сначала запиши всё в файл markdown:
- Таблица анализа дрейфа и сравнение структуры до и после
- Варианты ребалансировки со сводкой налогового эффекта
- Таблица сопоставления с моделью (если шаг 3 выполнялся)
- Записка с обоснованием ребалансировки (по `templates/rebalance-rationale-memo.md`)
- Резюме из 3 предложений простым языком, которое советник мог бы передать клиенту

Затем спроси советника, нужно ли выгрузить список вариантов в Excel и (или) преобразовать записку с обоснованием в Word или PDF; не создавай эти форматы, пока он не попросит.

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

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

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

- Обзор может занять несколько минут, когда данные портфеля начнут проходить через шаги: скажи об этом сразу, а не спрашивай, продолжать ли; вызов скилла — уже разрешение.
- Не ребалансируй ради ребалансировки: дрейф внутри диапазонов допустим; налоговые издержки могут превысить выгоду. Показывай точку безубыточности, когда она близка.
- Проверяй ожидаемые денежные потоки (взносы, изъятия, RMD), прежде чем продажа появится в вариантах.
- Любой результат по покупкам и продажам — **черновик для проверки советником, варианты, которые советник взвешивает, а не рекомендация**: за пригодность и лучшее исполнение отвечает советник.
- Документируй всё: записка с обоснованием — элемент книг и учётных записей; любую сводку для клиента прогони через **/compliance**.
- Согласуй отмывочные продажи по каждому счёту домохозяйства, чьи позиции и детали налоговых лотов ты действительно собрал: по счёту вне системы, когда советник даст его позиции, по подключённому счёту, когда его поток действительно вернёт базовую стоимость. Говори об этом, когда проверка не смогла охватить все.
- Считай данные клиентского портфеля и счетов конфиденциальными; включай только то, что нужно для этого обзора.

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

Обзор портфеля и ребалансировка

Как включить

Текст

Обзор портфеля и ребалансировка

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

Шаг 1: Достань доходность и позиции

Шаг 2: Анализ дрейфа

Шаг 3: Сопоставление с модельным портфелем

Шаг 4: Подготовка ребалансировки

Шаг 5: Записка с обоснованием ребалансировки

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

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

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

Похожие