alts-brief

---
name: alts-brief
description: Prepare a meeting-ready alternative-investments brief for a client, household, IRA, trust, or named account before a review: pulls the alts book from the alts platforms, iCapital, Addepar and CAIS (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 portfolio platform (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. 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.
---

# Alts Brief

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.

## Inputs

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:** never proceed on a name match alone, 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 building anything on it. This skill reads no CRM, so the matching happens in the reads: dispatch them on the name and grain as the advisor gave them, and a read that finds several candidates or a different household returns `IDENTITY MISMATCH` with what it saw — that is when you show the candidates and ask. Never call a platform's tools yourself to check the name first: that call is a read, and reads are dispatched (Data Gathering below). Where no read matched the name — nothing connected, or nothing found — say in the brief that the name and grain are as the advisor gave them.

Once you have the name and grain, **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.

## Data Gathering — Steps 1 and 2 run at the same time

Steps 1 and 2 read different systems and share no state. **Dispatch them as `claude-for-financial-advisors:source-extract` reads, one per platform, in a single message**: one `Agent(claude-for-financial-advisors:source-extract)` call per read, all in the same response, each in the foreground (`run_in_background: false`) so every block comes back as its call's result inside this turn: iCapital, Addepar and CAIS for the alts book (Step 1), Orion Connect and Envestnet for the liquid book (Step 2), with Step 2's fields added to Addepar's read because it serves both steps. The five go out every time, whatever you expect a platform to hold — with one exception: when your tool search finds tools for more than one of the liquid-book platforms, their Step 2 reads wait on the book-of-record question below, and every other read still goes in the first message. **Writing each dispatch is where you look for its platform's tools**: take their names from your own tool list, or, where they aren't there, from a `ToolSearch` by the platform's own name, and put every name you found into that dispatch exactly as written — the full name, never a prefix you guessed and never the platform's name in a tool's place — because a read calls only the tools you name, by exactly the names you give. **Asking a platform's assistant is a read.** A question put to a platform's own assistant reads that platform, even where the platform keeps the question in the advisor's own history, so it is never a reason to leave the platform unread. A dispatch hands its read every tool you found for its platform, never a shorter list and never a note to avoid one, and a read you finish inline works from the same list: which of them a read calls is for the read's own instructions and the platform's provider file to decide. Where you found none — not in your list, nothing from the search, or no `ToolSearch` offered in this session — that dispatch says so in their place, and names no status for the read to return: the read's own contract decides that, and the brief reports what it returned. That search decides what each read is handed, never whether it is dispatched — only the advisor's book-of-record answer below holds a read back — and it never stands in for a read's return: what the brief says about a platform comes from its read (below). Make it yourself, never through a general-purpose helper. Hand each the household identity as you have it, the one system that subagent is to query, the tool names you found for it or that you found none, the field schema under its step heading, and the window its step states for that read.

**An alts platform the advisor asks you to read beyond those five** gets its own read the same way: one more `source-extract` dispatch in that same message, handed Step 1's schema and the tool names you found for it, and never read by you instead. Everything below about a read covers it, and Step 6's Sources line names it.

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. **A platform's part of the brief is written from its read's block** — its figures, each with any qualifier the source states on it (an estimate, "approximately", a range, positions valued as of different dates), its `NOTHING FOUND` line and its "— pending" cells alike — or from your own inline read where Finish every read below sends you there. There is no third source: a platform with neither has not been read, and your own tool search is not a read.

**Finish every read in this turn.** A read whose dispatch errors, is refused because the concurrent-subagent limit is reached, returns `CANNOT CALL`, or hasn't come back by the time you would otherwise end your turn is yours to do inline — the same platform, the tools you found for it, the same schema — and its result goes into the brief exactly as a returned block would. Those four cases are the only times you call a platform's tools yourself before the brief is written, and each is something a dispatch did, so a platform you haven't dispatched has nothing to finish: never read one inline in place of its dispatch, ahead of it, or to check the name. A read you finish inline follows the plugin's provider file for its platform where there is one, as its dispatched read would: before your first call, list `${CLAUDE_PLUGIN_ROOT}/providers/`, and if it holds a folder named for that platform, read every file in it and follow it for the whole read. When a read you finish inline is of a source that answers in prose, read it as its dispatched read would. Ask one question naming every field. If the answer leaves fields out and returned a session or conversation id, ask once more on that id, naming only those fields; with no id, ask nothing more. Never ask in a new conversation, never two questions at once in one conversation, and never a second follow-up, so a field still unstated is not available. Fill a field only from a figure the source labels as that field. For a field it does not hold, quote its own words, and never turn them into a figure. Where the provider file differs from these rules on how to word a question, how many calls a conversation takes, or a reply an answer needs, follow the provider file; it never changes which household you read. Never end your turn with a read outstanding: a slower brief is the fallback, a half-built one never is. An `IDENTITY MISMATCH` is not outstanding — it is the question below — nor is a Step 2 read waiting on the book-of-record question below, which hasn't been dispatched; and no failure here is fixed by dispatching the same read again.

**Identity stays with you.** `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 when every read for its step returned it (Steps 1 and 2) — the subagent won't offer the manual fallback, because it isn't in the conversation. You do. One that comes back beside a read for its step that answered is not: the brief is built from what answered, with no placeholder sentence and no pending row for that platform, since nothing says the household holds anything there. Its Sources entry gives its status, and For the advisor (Step 6) asks whether the household holds anything there, offering to add it from an upload or a paste. A `NOTHING FOUND` return is neither: the platform was reached, searched, and holds nothing for this household — that is the empty result Step 3 describes, written with the search the read reports, never a "— pending" row, which says the data is still to come, and never a candidate question, which says it found someone else. A `PARTIAL` return is used as far as it goes: the fields it filled go in as returned, and each field it did not is "— pending [source]", naming the platform and the reason the read gives — never re-read to fill it, because a read stops at `PARTIAL` only where going on would take a write, which no read in this skill makes, or where every call it made returned an error, which a second read would only meet again. A read where some calls were answered and others returned an error comes back `OK`, and its fields are marked as Step 3 says. Asking which system to trust is yours too, under the Ask-Once, Then Route Convention. The alts book is a defined route, not a question: every alts read goes out, and Step 1 says which figure the brief uses and labels each with its platform. The liquid book is not: **if your tool search found tools for more than one of Orion Connect, Envestnet and Addepar**, each could answer Step 2 for this household, so the order is fixed — **the alts reads identify the household first** (an `IDENTITY MISMATCH` from any of them is settled before anything else), **then ask the advisor once which is the book of record for the household's liquid book and IPS target, then dispatch Step 2's read to that platform only.** While the question is open, Addepar's first read carries Step 1's fields only; if they name Addepar, its Step 2 fields go in a second read to it. A liquid platform they didn't name is not read for Step 2 (Addepar still gets its Step 1 read, and its Sources entry gives that read's status and says its liquid book wasn't read). If no alts read identified the household, don't read a liquid platform to find it: ask with the name as the advisor gave it, and the read you dispatch to the platform they name settles identity the usual way. The question comes when the alts reads return, whatever they returned — a match, `NOTHING FOUND`, or a failure — before any Step 2 read goes out. "It isn't in this one, so let me check the other" is exactly the read this rule forbids: which platform holds the liquid book is the advisor's to tell you, not yours to find out by reading. Never guess, and never merge two platforms' liquid figures. When they answer, offer to save the choice so they aren't asked again next session — the offer opens the reply that takes their answer, before your first read to the platform they named, even when their answer also hands you a different name to search: they paste *"For the [household] household, treat [system] as the book of record for the liquid book and IPS target. Don't ask me to choose again for this household."* into **Settings → General → Instructions for Claude** — Claude can't write those settings, so never offer to save it yourself or say you have. This 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.

## Step 1: Alts Book — the alts platforms (iCapital, Addepar or CAIS)

Alts can come from any of these platforms, and some households hold funds on more than one, so the Step 1 reads go to every one (see Data Gathering above): each that returns data is used, and every one 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 you take them from your own tool list or a search by the platform's name (Data Gathering above) and hand them to the read.

**Look for the tools before you trust the registry.** `ToolSearch` by the system's own name is where you look when a platform's tools aren't in your own list: the names that come back are the ones you hand its read, and if none do, its dispatch says so — whether the platform is connected is what that read returns. `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.

- **iCapital** — the alts platform book: positions, valuations, cash flow, and iCapital-computed performance metrics.
- **Addepar** — publics and privates in one view, with lookthrough into the underlying holdings of private funds. Addepar names the funds it holds and classifies them by strategy and vintage year, and it is the path for capital calls, cash coverage, and reconciliation (see Step 2). Commitment and unfunded figures may come back empty here — take those from another alts platform that returns them, or mark the cells as Step 3 says, rather than reporting a zero as though the household had no commitment.
- **CAIS** — the alts platform book for funds held through CAIS.

Where more than one platform returns data, **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 platforms are not reconciled to each other. **No alts platform outranks another**, so for a fund more than one of them reports, which figure the brief uses is settled field by field, in this order, and never by which platform gave it:

1. **A field only one platform returns** comes from that platform, and the brief says so ("vintage year per Addepar"). A platform that answered without the field, or returned it empty, is not a figure to set against the other's.
2. **Figures at different as-of dates** are lag: the one with the latest as-of date is used, and every one is shown with its platform and date (the as-of comparison below).
3. **Figures that agree at the same as-of date**, or facts with no as-of date of their own that agree, such as a lockup end, are one figure, written once and labeled with every platform that gave it, so the advisor can see each system holds it. Where a NAV agrees only because one platform rounds it, show each as its platform gave it, and use the unrounded one.
4. **Figures that disagree at the same as-of date**, or such facts that disagree, are a genuine conflict (the as-of comparison below): the brief picks neither, and stops there. Ask the advisor which is right as a blocking question before the brief is finalized, never as one of the For the advisor questions the brief is written around (Step 6). A brief written before they answer says it is a draft, with the conflict open.

Never present a figure from one platform as though it came from another. (This is a defined route under the Ask-Once, Then Route Convention, not a question for the advisor: the platforms aren't reconciled to each other, so labeling each preserves information a single pick would lose.) Of the four, only the last stops the brief for the advisor. An export the advisor hands over follows the same order, its figures labeled as that platform's export ("per the Addepar export"), not as a read: the platform's Sources entry still gives what its read returned.

**Two sources' figures share a row only when they are the same fund**, and that is settled before anything is merged: a wrong merge puts one fund's figures under another's name. They are the same fund when the names match once case, spacing and punctuation are set aside, with the same fund number or series, and the same share class or none stated by either, whether the class is a column or part of the name. A pair that meets this is one fund, settled by this rule rather than by the advisor: don't ask them to confirm it, in For the advisor (Step 6) or anywhere else. Figures that agree across the two are what one fund on two sources looks like, never a reason to ask whether one source repeats the other. Names that would match but for one of those are unresolved: Fund V beside Fund VI, Class A beside Class I or beside no class at all, or a legal suffix only one carries. So is a position one source gives only as an identifier that no source ties to a name. A source can confuse similar names, so a difference like that proves neither one fund nor two. An unresolved pair keeps two rows, each source's figures under its own name, and For the advisor (Step 6) asks whether they are the same fund. Until they answer, both rows count, so every total and flag (Step 4) that counts both names the pair and says what it would be if they are one fund, counted once by the order above, or, where their figures differ at one as-of date, that as one fund they would be a conflict (the order's fourth case) and no single figure stands until the advisor says which is right, so the question that asks whether they are the same fund also asks which figure is right if they are: a total that counts one fund twice without saying so overstates the book. Names that differ beyond that are different funds, and nothing is asked. This holds for any two sources, whether reads or an export the advisor hands over.

**When two sources report the same fund, compare their figures only at the same as-of date.** This holds for any two sources, whether reads or an export the advisor hands over. Different as-of dates are lag, not a conflict — alts NAVs are marked on each platform's own schedule, so one platform is often a quarter behind another. Show each figure, labeled with its platform and its own as-of date, and don't ask the advisor to choose between them. The fund is still one position: count it once in every total and flag, using the figure with the latest as-of date, and say which one you used. The older figure is shown and feeds nothing else — no total and no flag, the stale as-of flag included (Step 4). Which figure counts is settled by this rule, not a choice you made, so it is not a question for the advisor: don't ask them to confirm it, in the For the advisor section (Step 6) or anywhere else. At the same as-of date the sources must agree — commitment and called-to-date exactly, NAV to rounding — and so must any fact that carries no as-of date of its own, such as a lockup end or a call's due date. A disagreement beyond that is a genuine conflict, and labeling both isn't enough: stop and surface it to the advisor as a blocking question before the brief is finalized, never resolving it yourself by picking one. Lag never explains figures apart by orders of magnitude, whatever their dates — that is the Magnitude-Conflict Convention (Data Gathering above).

Query the connected platform(s) for the client's alternative investment positions. Every commitment, NAV, call, distribution, fund name and metric comes from a read's return, a fund document, or the advisor — never from a guess, a prior brief, or knowledge of the manager:
- 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 document in the firm's document store 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 document in the firm's document store, an uploaded statement, or the advisor. Never assume a standard lockup for the structure, and mark the cell as Step 3 says: "not available" with the platform's own words where a read answered without them, and "— pending [source]" where nothing has answered for them yet or an error kept them from a read
- 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.

**This read is time-bounded in parts**, so the dispatch tells its extractor the window for each part as well as the schema: recent activity covers the lookback window, ending at the advisor's cutoff date if they gave one (Inputs); commitment, called-to-date, paid-in, unfunded, each position's cumulative cash flows and the platform's performance metrics are inception-to-date; NAV is the latest the platform reports.

### Performance metrics — pass through, never recalculate

Report performance metrics **as the alts 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.

- A metric the platform answered without is **"not available"** (one an error kept from the read is pending, Step 3) — not a guess, not a dash implying zero, and never a different metric substituted in. MOIC and TWR are commonly asked for and commonly absent; say so rather than offering TVPI in their place.
- **Returns are inception-to-date.** There is no per-quarter IRR to report, so don't compute one from period figures.
- **Check whether IRR arrives as a decimal fraction** before display, and flag an implausibly large result as reflecting an early or unusual cost basis rather than presenting it as a return the advisor can explain.
- **Say whether figures are net or gross**, and don't mix the two in one comparison.
- **Report commitment, called, and unfunded as three separate figures.** Don't derive a "% funded" from them or reconcile them against each other — they're reported independently and aren't meant to tie, and dividing them can produce a figure over 100%. If a platform reports a paid-in percentage itself, use that and cite it; otherwise leave it out rather than calculating one. Same for two different value figures on one position: show one, say which.
- **Lifetime figures need lifetime windows.** On some platforms, columns like called-to-date, paid-in, and total commitment are computed over the query window — a trailing-12-month pull can understate called-to-date or return commitments as zero. Pull cumulative figures with an inception-wide window, prefer a field that stores the lifetime total over one computed across a window, and when two sources both carry the figure, cross-check them and surface a disagreement rather than picking one silently. State the window behind any windowed figure.

> **Connector Placeholder Convention:** if every alts read (iCapital, Addepar and CAIS) returns `NOT 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.

## Step 2: Liquid Book & IPS Target — the portfolio platform (Orion Connect, Addepar or Envestnet)

Pull the rest of the household picture so alts can be sized in context:
- Total liquid/investable assets and current cash balance
- IPS or model target allocation to alternatives (%) — **check the connected platform for it first.** If a platform exposes target allocations or IPS bands, use them and cite the platform. Not every platform surfaces targets even when it holds them, so if nothing comes back, ask the advisor for the target or accept a pasted IPS — and say which of the two the number came from, since a target the advisor supplied from memory carries different weight than one read from the system of record.
- Household AUM for sizing alts against the total. If the connected platform reports allocation or exposure percentages itself, use those and cite them rather than summing an alts NAV onto a liquid balance by hand — the two may be valued as of different dates, and a platform-computed percentage is the defensible number. If you do have to combine figures, whether an alts NAV onto a liquid balance or one fund's NAV onto another's for an alts total, say which values and as-of dates you combined, and present the result as approximate. Where those dates differ, call it an estimate valued as of different dates, never a value at one date.

Follow the same **Connector Placeholder Convention** as Step 1 — if the reads for all three return `NOT CONNECTED`, 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]".

**A portfolio system that runs reports but returns no holdings** is worked with the way @${CLAUDE_PLUGIN_ROOT}/partials/rules/report-only-systems.md says. In this brief its read supplies at most the household's current value, so cash and the IPS target are "not available" from it (Step 3), and For the advisor (Step 6) asks the advisor for both.

**When Addepar is connected**, it answers the capital-call and cash questions directly, and these feed the flags in Step 4:
- **Upcoming capital activity** — future-dated calls by fund and date, returned alongside the household's cash balances so coverage is assessed against real cash rather than an estimate. Forward-looking only: it does not return calls that already happened.
- **Private-fund cash movements** — recent calls, contributions and distributions matched against actual cash-account activity, which answers "did that call clear?" rather than only "was it announced?" Use the platform's own matches; report an unmatched item as unmatched rather than pairing it yourself.

A call that is upcoming has not cleared — never describe it as funded, and never subtract it from the cash balance the brief reports: that balance is the figure the platform returned. Weighing upcoming calls against that cash is Step 4's first flag, and that is where the comparison is made.

**This read is time-bounded in parts**, so the dispatch tells its extractor the window for each part as well as the schema: the balances, the IPS target and household AUM are the latest the platform reports; the private-fund cash movements cover Step 1's lookback window, ending at the advisor's cutoff date if they gave one (Inputs); and the upcoming capital activity is every future-dated call the platform returns, never cut to the lookback.

**Documents, if the firm's document store is connected.** Find its tools the same way you found the platforms' — your own tool list, or `ToolSearch` by the product's own name (for example @${CLAUDE_PLUGIN_ROOT}/partials/connectors/storage-examples.md) — 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 no document store is connected, or a search finds nothing, say so in one line and continue. Never block or delay the brief on document search.

## Step 3: Assemble the Position Table

| Fund | Manager/Strategy | Commitment | Called-to-Date | NAV | Unfunded | Recent Activity | Lockup/Liquidity | As-of Date |
|------|------------------|-----------|-----------------|-----|----------|-----------------|-------------------|-----------|

One row per position. A fund more than one source reports, whether reads or an export the advisor hands over, is still one row, its cells filled as Step 1 orders: a cell they fill at different as-of dates carries each figure with its source and its own as-of date, and a figure they agree on at the same as-of date is written once, with every source that gave it, unless one source rounds a NAV the other states in full, which shows each. **Recent Activity** carries the fund's calls and distributions from the lookback window (Step 1) and, after them, any upcoming call for that fund (Step 2), marked upcoming with its amount and due date — the flags in Step 4 cite these rows, so a call that is only mentioned elsewhere leaves the cash flag with no row to point at. A cell with no figure says which of two things is true, and never guesses. **"not available"**: a platform answered and does not hold the field, or did not state it when asked. A line under the table names each such field for that fund with the platform's reason, in its own words where the read quotes them. **"— pending [source]"**: nothing has answered for the figure yet, and [source] names what would supply it: a platform not yet connected, a `PARTIAL` read, a call that returned an error from the platform, or a fund document or the advisor where Step 1 looks there. An error is not an answer about the field, since it says nothing about whether the platform holds it, so a field kept from a read by an error is "— pending [source]" in an `OK` read as in a `PARTIAL` one, even where the read marked it "not available", and the line under the table quotes the error in the platform's own words. The error rule is for a field no answer covered: a field a source already answered without, including one a prose source's first answer did not state, stays "not available" even if a later call about it, a follow-up, errors or is refused, so no field gets both markers. What the reads returned decides between the two, not who could still supply the field: a field a read answered without is "not available" even where Step 1 also looks to a document or the advisor for it, and its line under the table says where it can still come from. The metrics table below uses the same two markers.

**A zero is not the same as "not reported."** A figure that comes back empty or zero from a platform that doesn't carry it is "not available", never `$0` or `0%`: "$0 unfunded" tells an advisor the commitment is fully drawn, which is a different and possibly wrong statement. Put a zero in a cell only when the platform reports it as a real value for that field.

**A figure under another metric is not a substitute for the column's.** When a read returns a figure under a different name than the column's (an estimated position value where the column is NAV, a purchase amount where it is Commitment), show it on that fund's line under the table, under the platform's own name for it and with the date the platform gives it, never in the NAV or Commitment column, which stays "not available". That date belongs to that figure, whatever the platform calls it: a "NAV Date" beside an estimated position value dates that value, and is neither a NAV's as-of date nor the row's As-of Date.

**An empty result is an answer, not a gap to fill.** If no positions come back — a read's `NOTHING FOUND` — the table isn't built: say "no alts positions found for [client] in [platform]" and name what the read searched, so the advisor can tell a real absence from a bad search. Never assemble an illustrative table in the space. A zero result may mean the client holds nothing or that the advisor isn't entitled to see that book; don't assert which, and suggest they confirm entitlements if they expected positions.

Put performance metrics in a **second table** rather than widening this one past readability — one row per fund and a column for each of IRR, TVPI, DPI and RVPI, with the marker Step 3 gives 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. Where no fund has any of the four, leave the table out: each fund's line under the position table names all four with the marker Step 3 gives and the platform's reason.

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

## Step 4: Flags

Surface what actually needs the advisor's attention — this is the point of the brief, not just the data dump above:

- **Cash needed for upcoming calls**: any known/expected near-term capital calls vs. the household's current cash balance — this is where upcoming calls are weighed against cash (Step 2), so do the comparison here and show it. Flag if calls would draw cash below a reasonable buffer. If the advisor hasn't given a threshold, the flag is still made: state the buffer you assumed, as a figure, measure the calls against it, and ask for their threshold in the close. A missing threshold never means the flag is skipped or made against no buffer.
- **Alts % vs. target**: alts as a share of household AUM against the IPS target, flagging meaningful drift either direction. Say which basis you used — NAV alone, or NAV plus unfunded — and unless the advisor has already said which the firm uses, ask in the brief's close (Step 6) whether the firm counts unfunded commitment toward the target: it materially changes the answer. Prefer a platform-reported allocation percentage over one you compute, and note where the target itself came from (see Step 2).
- **Concentration**: any single manager, strategy, or vintage year that's an outsized share of the alts book.
- **Unfunded concentration**: which fund holds the largest share of remaining unfunded commitment — the likeliest source of the next call, and the one to watch against cash.
- **Stale as-of data**: private-fund NAVs typically lag a full quarter. Flag any position whose as-of date is older than ~100 days so the advisor knows the number isn't current, not that nothing changed.

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

## Step 5: A Platform's Disclaimer Is a Link, Never Its Text

**No platform's disclaimer, terms or disclosure text goes in the brief** — not quoted, not paraphrased, not summarized — and no read is asked for it, so a dispatch's schema never names one. The same holds for the disclosure pages of a statement or export the advisor hands over. A platform's terms are its own and change when it chooses, so the brief points to them rather than keeping a copy that can go out of date. Where a read returned a link to its platform's own disclaimer or terms page, that link goes whole into the platform's entry in the Sources line (Step 6); where none did, the brief says nothing about that platform's disclaimer. Never write disclaimer text yourself, and never carry wording forward from another brief.

A figure's own qualifiers are not disclaimers: an as-of date, an "estimate" or "approximately", or the name a platform gives a metric stays with its figure, as Data Gathering says.

## Step 6: Output

Write the brief to a markdown file first. If the file you are about to write is already in the working folder, ask the advisor whether to replace it before you write, and never overwrite it without their say-so. It carries client data, so it holds what this review needs and nothing more:
- A meeting-ready brief opening with an **Executive Summary** — two or three sentences on the household's alts picture, in plain English, including how it sits against the IPS target. This is the same summary the chat reply opens with, not a second one written for chat, and it goes above the analysis rather than after it. Where a read returned nothing or the target is unknown, it says so here instead of summarizing a picture the brief doesn't hold.
- Then the position table, then the flags — the flags cite rows in the table, so the table belongs above them. Give the flags their own heading so an advisor short on time can go straight to it.
- Cite the source platform for the alts data — iCapital, Addepar, CAIS, or more than one, naming which one each figure came from when the book spans more than one (Step 1) — and give a **Sources** line above the position table naming each platform read (the five, and any the advisor named) with the status its read returned (`OK`, `NOT CONNECTED`, `NOTHING FOUND`, `PARTIAL`), or, for one you finished inline, that you read it yourself and why, or, for a liquid platform the advisor didn't name as book of record, "not read — [system] is the book of record". A platform's disclaimer appears only as the link Step 5 describes, in that platform's entry.
- **Where a source said where its answer came from, the brief keeps it**, so the advisor, or anyone reviewing the brief, can check a figure against the platform that gave it. A citation a read returned after a value stays beside that figure, or in a numbered note under the table that the figure points to, and is never moved to another figure or dropped. It always names the platform it came from and keeps its citation id and page, so a reader can tell which system to check the figure against, and where: carry it in the form the read gave it, add the platform's name where that form lacks it, and shorten nothing in it but the document's name. Each link a read returned under `sources:` goes whole into that platform's entry in the Sources line, after its status, whatever the status was. That entry is the brief's one place for the link: never a list of links of its own, under the table or anywhere else. When the advisor asks to see the source behind a citation a read returned, list `${CLAUDE_PLUGIN_ROOT}/providers/`, and if it holds a folder named for that platform, read every file in it and follow what it says about showing a cited source. That is the advisor's request, not a read, and adds nothing to the brief. With no such folder, or nothing in it about showing a source, say you can't open the source from here, and give the citation and the link as the brief carries them.
- Then a short **For the advisor** section naming every question the brief was written around rather than waiting on — each asked as a question the advisor can answer in a word, not as a default you've noted ("I'll use trailing 12 months unless you say otherwise" states a choice; "Is trailing 12 months the right window, or is there a prior brief to measure from?" asks one): which lookback window to use if you defaulted to trailing 12 months (Step 1), whether the firm counts unfunded commitment toward the target (Step 4), their cash-buffer threshold if you assumed one (Step 4), whether two positions Step 1 could not match are the same fund, whether the household holds anything on a platform whose read came back `NOT CONNECTED` beside one for its step that answered, and if so, that an upload or a paste adds it (Data Gathering), and anything a "— pending [source]" cell is waiting for, or a "not available" one could still take from the advisor or a document (Step 3). These are asked here, in the file, and again in the chat — never instead of the file.
- If the advisor asked for the whole household picture — or the request reads that way, not just the alts sleeve — say in the brief that this covers alts only and point at **/portfolio-rebalance-review** for the full multi-asset drift review and rebalance prep.
- If any part of this brief will be shared with the client directly, recommend running it through **/compliance** first — this skill produces an advisor-facing prep document, not pre-cleared client communication.

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

That close is one short set, with nothing between its parts: **two to four directions to go deeper**, the **format question** — would they like it converted to .docx or .pdf, created only if they ask (markdown is the first-pass deliverable; heavy formats are materially slower) — and the **For the advisor** questions from the file, asked again here. **Where a same-date conflict is open** (Step 1), its blocking question comes first, before that set, and the format question waits for the answer: a draft is not converted to .docx or .pdf. **Only offer directions this run can actually deliver:** a fund-level look is a direction only into positions a platform actually returned, and a sleeve the reads came back empty or `NOT CONNECTED` on is not something waiting to be shown. **Where no read returned positions at all, the set is shorter rather than padded** — the manual fallback the Connector Placeholder Convention already owes (upload a statement or export, paste position details) is what the close offers, and it stands in for the directions rather than sitting beside them. Two directions is a floor for a run that produced something, never a quota met by naming a direction that leads nowhere.

## Out of Scope

- **No fund recommendations.** This skill reports what's on platform and flags what needs attention — it does not suggest adding, dropping, or replacing a fund or manager.
- **No NAV/IRR forecasting or projections.** Report only actuals as reported by the source platform. Never estimate future NAV, project IRR, or otherwise forward-look.
- **No allocation simulations.** Questions like "what if we added 10% private equity?" are out of scope — say that scenario modeling is outside this brief.
- **No recalculated or hypothetical performance.** "Recalculate IRR assuming a higher exit multiple," "what will NAV be next quarter," and similar are out of scope — the metrics are the platform's computed figures, and re-deriving them under different assumptions produces a number no system will stand behind. Say so plainly and offer what the record does show.
- **No transactions.** This skill never initiates a subscription, capital call funding, or redemption — those go through the advisor's normal workflow on their alts platform (for example CAIS or iCapital).

## Important Notes

A summary; each rule is stated in the step it governs.

- Never fabricate commitment amounts, NAVs, call/distribution history, fund names, or performance metrics. Missing data is "not available" or "— pending [source]", never a guess (Steps 1 and 3).
- **A zero is not the same as "not reported"** (Step 3).
- **An empty result is an answer, not a gap to fill** (Step 3).
- This skill covers the alts sleeve specifically. For a full multi-asset-class drift review and rebalance prep, that's **portfolio-rebalance-review** (`/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.
- **Lead the chat response with the brief's Executive Summary**, then offer two to four directions this run can actually deliver — fewer, or none, where no read returned positions — and the position table and the flags stay in the file (Step 6).
- Treat client data as confidential; only include what's needed for this review (Step 6).