クライアント、世帯、IRA(個人退職口座)、信託、あるいは指定口座を対象に、レビュー前の会議向けオルタナティブ投資(従来の株式・債券以外の投資)概要書を作成します。 iCapital や Addepar から投資ポートフォリオのデータ(保有銘柄、時価評価額と出資額、コール(投資資金の追加請求)と未払い金、出資・分配・購入・償還、ロックアップ(売却制限期間)、IRR(投資利益率)・TVPI・DPI・RVPI(各種投資パフォーマンス指標))を取得し、接続されたポートフォリオシステム(Orion Connect、Addepar、Envestnet など)から流動性資産のポートフォリオと IPS(投資方針書)の目標値を並べて表示します。 その際、資本コール時に必要な現金、目標に対するオルタナティブ投資の割合、集中度、未払い部分の集中度、古いデータの日付などを自動で指摘します。すべての数字に対して情報源プラットフォームを記載し、開示事項をページ上に保持します。 **機能の制限:** ファンドの推奨、時価評価額やリターン率の予測、配分変更のシミュレーションは行いません。 **次のような場合に使用:** 「オルタナティブ投資概要書」「/alts-brief」「[クライアント名]のオルタナティブ投資レビューを準備して」「[クライアント名]のプライベート・エクイティ(非公開株式投資)の状況は」「[クライアント名]のオルタナティブ投資の成績は」というように、会議前にクライアント世帯のオルタナティブ投資ポジションをレビューするよう求められたとき。
Prepare a meeting-ready alternative-investments brief for a client, household, IRA, trust, or named account before a review — pulls the alts book from iCapital or Addepar (positions, NAV vs. commitment, called and unfunded amounts, contributions/distributions/subscriptions/redemptions, lockups, and the platform's own IRR/TVPI/DPI/RVPI) and sits it beside the liquid book and IPS target from the connected portfolio system (Orion Connect, Addepar, or Envestnet), then flags cash needed for capital calls, alts % vs. target, concentration, unfunded concentration, and stale as-of data. Cites the source platform on every figure and keeps disclosures on the page. Does not recommend funds, forecast NAVs/IRRs, or simulate allocation changes. Triggers on "alts brief", "/alts-brief", "prep the [client]'s alts review", "what's going on with [client]'s PE/private investments", "how's [client] doing on their alts", or any request to review a household's alternative investment positions before a meeting.
Give an advisor a clear, meeting-ready read on a household's alternative investments: what's on platform, how it's tracking against their goals, and what needs attention — sitting alongside the liquid book so the advisor can see the whole household, not just the alts sleeve in isolation.
Required: client/household name. Optional: an as-of/cutoff date if the advisor wants the "recent activity" portion of the brief anchored to a specific date rather than "latest available" (default: since the last brief, or trailing 12 months if this is the first one), and a specific fund or manager to focus on if they only want part of the book.
Identity grain: alts are frequently held at a level below the household — an IRA, a trust, a single person, or one named account. Take the advisor's grain literally: "the Harrington IRA," "the Whitmore Trust," "Robert Harrington," or "the Northgate account" each mean that entity, not the whole household. Don't silently widen a named account up to its household, and don't narrow a household down to one account.
Disambiguation rule: confirm identity before pulling anything, the same as every other skill in this plugin — if more than one client, household, or account matches the name, show the candidates and ask which one before proceeding. Never proceed on a name match alone. When nothing is connected there is no match to confirm: take the name and grain as the advisor gave them, say so in the brief, and go.
Once identity is confirmed, pull the alts book and the liquid/IPS picture in parallel (Steps 1 and 2) — one missing source degrades only its own section, never the other. Before starting, tell the advisor what you're gathering and why, so a slow multi-source pull doesn't look like a silent hang. And once the client and grain are known, don't ask "should I start?" — narrate what you're doing and go; the approval gates here are the format conversion at the end and the /compliance recommendation, not permission to begin.
Steps 1 and 2 read different systems and share no state. Dispatch them as claude-for-financial-advisors:source-extract subagents in a single message — one Agent(claude-for-financial-advisors:source-extract) call per platform the household could be on, all in the same response rather than in sequence: iCapital and Addepar for the alts book; Orion Connect, Addepar, or Envestnet for the liquid book. You don't know which of them is connected until a read tells you, and finding out is the read's job, not a step before it: each searches for its own platform's tools by name and returns data or NOT CONNECTED, so a platform the household isn't on costs one short return. Never run a connectivity check from this session first — not yourself, and not through a general-purpose helper — because in a session with no platform tools that check ends with no read dispatched at all, and the Convention below is triggered by a read's NOT CONNECTED, never by a guess made before it. Hand each the household identity as you have it, the one system that subagent is to query (iCapital or Addepar for a Step 1 read; Orion Connect, Addepar, or Envestnet for a Step 2 read), the field schema under its step heading, and the lookback window.
Each returns a filled schema block. They do not summarize, flag, or size anything against the IPS target — Steps 3 and 4 are yours, and they need the raw figures, not a subagent's read of them.
Identity stays with you. claude-for-financial-advisors:source-extract never resolves a household: if it returns IDENTITY MISMATCH, show the advisor the candidates, confirm, and re-dispatch. A NOT CONNECTED return is the Connector Placeholder Convention case — the subagent won't offer the manual fallback, because it isn't in the conversation. You do. The same goes if more than one connected tool could try to solve the same problem for this household on either read below (not necessarily two of the same kind): ask the advisor once which is the book of record, per the Ask-Once, Then Route Convention, rather than guessing, and offer to help them save the choice using the Personalization Convention. (Step 1's iCapital/Addepar handling below is a deliberate exception to this, not an oversight.) This check isn't one-time — a source the advisor mentions on the fly mid-gathering counts too, and asking again before merging it in. And if two systems were pulled anyway and return the same household at figures apart by orders of magnitude, follow the Magnitude-Conflict Convention: name the conflict, and exclude the outlier's figures from every table and total rather than quoting them as evidence.
Alts can come from either platform, and some households have both, so the Step 1 reads go to both (see Data Gathering above): the one that returns data is the one you use, and both returning NOT CONNECTED is the Convention case at the end of this step. Don't guess at a tool-name prefix like mcp__icapital__*; real connector tool names use opaque, unpredictable prefixes, which is why the read searches by the platform's name.
The read looks for the tools before it trusts 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, and the read uses 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 both are connected, label each figure with the platform it came from rather than merging them into one undifferentiated list — the advisor needs to know which system to open to act on a row, and the two are not reconciled to each other. Where the two overlap, prefer whichever platform actually returns the field: Addepar can supply a fund name and a computed paid-in percentage for positions iCapital returns only as an internal identifier. Say so when you do it ("fund name per Addepar"), and never present a figure from one platform as though it came from the other. (This is a deliberate exception to the Ask-Once, Then Route Convention: the two platforms aren't reconciled to each other, so labeling both preserves information a single pick would lose.) That exception covers which fields each platform supplies, not a genuine conflict: if the two ever disagree on a material fact for the same position (a valuation, a commitment amount, a date), labeling both isn't enough — stop and surface it to the advisor as a blocking question before the brief is finalized.
Query the connected platform(s) for the client's alternative investment positions:
Fund/product name, manager, strategy (PE, private credit, real estate, hedge fund, etc.), and structure (drawdown commitment vs. evergreen/interval fund) — Addepar returns fund name, strategy and vintage; iCapital may return none of it, in which case take it from the advisor, an uploaded statement, or a Drive document rather than inferring it
Commitment amount, called-to-date, and NAV, with the as-of date for each
Unfunded commitment remaining
Recent activity: capital calls and distributions in the lookback window (default: since the last brief, or trailing 12 months if this is the first one). When it's unclear which applies, use trailing 12 months, say so where the activity is reported, and ask in the brief's close (Step 6) — don't hold the brief for the answer.
Lockup/liquidity terms (lockup end date, redemption windows/gates, or "committed capital, no redemption" for drawdown funds) — these usually live in the fund's own documents rather than in a platform field, so expect to source them from a Drive document, an uploaded statement, or the advisor; mark them "— pending [source]" rather than assuming a standard lockup for the structure
Cash-flow detail per position: contributions, distributions, subscriptions, redemptions, and remaining unfunded commitment. Note which fund holds the largest share of the remaining unfunded — that's the one most likely to generate the next call.
Classify each transaction by its type, not by whether its amount is positive or negative — signs are not a reliable indicator of direction here. And sort by trade date yourself before calling anything "recent": activity may arrive ordered by when it was last edited.
Report performance metrics as the platform computed them — IRR, TVPI, DPI, RVPI. Narrate and rank them (best and worst, early vs. mature); never recompute one, never derive one the platform didn't return, and cite the platform on the numbers.
Connector Placeholder Convention: if neither iCapital nor Addepar shows as connected, say: "This is where I'd make a call out to [platform] to pull [client]'s alts positions once that connector is available." Then offer the fallback: the advisor can upload a statement/export (PDF/CSV) or paste position details. Don't wait for it — write the brief now (Step 6): the position table carries one row of "— pending [source]" cells in place of the positions you couldn't pull (never an invented fund or figure), each flag is named with what it's missing, and the questions you owe the advisor sit in the close after the file exists. A brief that is all pending rows is still the deliverable; a question with no brief behind it is a stall. Anything the advisor provides afterwards is a fresh pass over the same brief.
Pull the rest of the household picture so alts can be sized in context:
Follow the same Connector Placeholder Convention as Step 1 — if none of the three is available, fail gracefully: say so, then offer the manual fallback (paste, upload, or skip) and continue to the brief with the liquid/IPS figures marked "— pending [source]".
When Addepar is connected, it answers the capital-call and cash questions directly, and these feed the flags in Step 4:
A call that is upcoming has not cleared — don't describe it as funded, and don't net it against cash beyond the comparison the platform already provides.
Documents, if Drive is connected. ToolSearch for Google Drive's tools by name — the one lookup you make yourself, for documents only; the platform reads check their own connectivity — and if they come back, offer to search it for the household's fund documents — capital call notices, subscription agreements, K-1s, quarterly letters — which often carry terms and dates the platforms don't expose. This is additive: if Drive isn't connected, or a search finds nothing, say so in one line and continue. Never block or delay the brief on document search.
| Fund | Manager/Strategy | Commitment | Called-to-Date | NAV | Unfunded | Recent Activity | Lockup/Liquidity | As-of Date |
|---|
One row per position. If a field is unavailable for a given fund, mark that cell "— pending [source]" rather than guessing — [source] names what would supply it (iCapital, Addepar, a fund document, the advisor). That is the one sentinel this skill uses, everywhere a value is missing.
Where performance metrics are available, put them in a second table rather than widening this one past readability — one row per fund, columns for the metrics that fund actually has (IRR, TVPI, DPI, RVPI), with "not available" in any cell the source didn't return. Say in a line above it that these are the platform's own computed figures, as of the report date, and whether they are net or gross.
Naming rows: iCapital may identify a position only by an internal product id, without fund name, manager, or strategy. Don't infer any of them — from the id, a prior brief, or knowledge of the manager. If Addepar is connected, use the fund name, strategy, and vintage year it returns and attribute them to Addepar. Otherwise label the row with the identifier given, say the name isn't available, and offer to take it from the advisor or an uploaded statement; a wrong fund name on a meeting document is worse than a missing one.
Surface what actually needs the advisor's attention — this is the point of the brief, not just the data dump above:
If a flag can't be evaluated because its input is missing — no IPS target, no cash balance, no as-of date — name the flag and say what's missing, rather than dropping it from the list. A flag that silently disappears reads as "nothing to worry about here," which is not the same as "this couldn't be checked."
Before assembling the final output, gather the disclosures that have to travel with this data — platform-level disclaimers, fund-specific disclosures, and as-of/data-lag notices.
Take them from whatever the source actually provides: text returned alongside the position data, or the disclosure pages of an uploaded statement or export. If the connector returns no disclosure text, say so and ask the advisor for their firm's standard alts disclosure language — never draft disclosure or disclaimer text yourself, and never carry forward remembered wording from another brief. These are reproduced verbatim in Step 6, so identify them here rather than reconstructing them afterward.
Write the brief to a markdown file first:
Then ask the advisor whether they'd like it converted to .docx or .pdf — don't create either format unless they ask. Markdown is the first-pass deliverable; heavy formats are materially slower, so produce them only on request.
/portfolio-rebalance-review) — Step 6 says to point at it in the brief whenever the advisor wants the whole household picture rather than just alts.原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。