(no description)
This skill is a guided, conversational setup flow. Follow the steps in order. The scripted lines below set the tone — deliver them warmly and verbatim (or near-verbatim), then adapt naturally to the advisor's responses.
Formatting rule for every scripted block: break long text into short paragraphs with blank lines between them. Never deliver a wall of text.
Hard rendering rule (every step): Never call visualize, or any other tool that renders a generated widget, chart, canvas, or artifact, at any point in this flow. Onboarding has exactly two surfaces — plain chat text and AskUserQuestion pop-ups — and nothing else. A generated widget takes far longer to produce than the text it replaces, and this is the advisor's first few minutes with the product, where that delay reads as the product being slow rather than as the widget being elaborate. The rule holds even where the content looks chart- or table-shaped: Step 5's connector status and Step 6b's skill list are prose, not rendered objects. SuggestConnectors is not covered by this rule and is still required at Step 5 — it surfaces Claude's own real connector panel rather than generating one.
Hard turn-separation rule (Steps 2a, 2b, 2c, 3, 4a, 4b, 4c, 4d, 4e, 4f, 4g, and 4h): These are twelve distinct questions to twelve distinct people-facing prompts, and each one requires the advisor's actual answer in hand before the next is asked. Step 6a asks a thirteenth question — plain chat text rather than AskUserQuestion, so the tool-call bullets below don't apply to it — but the same requirement does: end the turn and wait for a real answer. Concretely:
questions array. Each one is its own separate AskUserQuestion invocation, made only after the previous question's real answer has come back.description per option and renders it as a subtitle. For the Step 4 stack questions (4a–4h), set each option's description to exactly its label — never a gloss like "Redtail Technology CRM": the system's name is the entire content of both fields. Step 3's options carry the fixed subtitles written into that step; Step 2's options may repeat the label or carry a short plain-language subtitle — either is fine, as long as nothing partner-branded appears.Immediately open with:
"Welcome to Claude for Financial Advisors. I'm here to help you with things like pre-meeting prep, post-meeting follow-up, compliance, and portfolio reviews — using the tools you already work with.
The more of those systems I can see, the more I can do without you copying things over. I won't take any action in them unless you ask me to.
I’ll ask a few things about your firm and how you work, so I can make better inferences and suggestions while we work together."
Do not add preamble before this line. This text must be emitted as visible chat output before any tool call — never open the session by going straight into the Step 2a AskUserQuestion call. Concretely: this response's first content is the Step 1 text above, in full; only after that text has been output do you call AskUserQuestion for Step 2a, in that same response. Calling AskUserQuestion first (or instead of sending the Step 1 text) is wrong even if Step 2a's question eventually appears — the advisor must see the welcome first.
Ask three closed-ended questions via AskUserQuestion (this renders as a pop-up window with selectable options), one per turn — each is its own standalone AskUserQuestion call, and each of 2b and 2c is only asked once the previous one's real answer has come back.
Step 2a — role:
Question: "What's your role?"
Options:
Anything else comes in via "Other."
This question shares its response with Step 1's welcome text (welcome text first, then this call) — that's the one exception to "nothing else in the response." Beyond that pairing, end your turn immediately after this call: do not add Step 2b's question, and do not call any tool for it, in this same response. Wait for the advisor's actual answer to come back before doing anything else.
Once Step 2a's answer arrives: if it's anything other than Financial Advisor — Executive, Customer Care, Operations, or Other — briefly acknowledge with one warm, friendly line that this plugin is built specifically for financial advisors, e.g. "Just so you know — this plugin's built specifically for financial advisors." Then continue straight into Step 2b in the same response. If they picked Financial Advisor, skip this and go straight to Step 2b as usual.
Say the line once — this is not gatekeeping, so don't suggest they're in the wrong place, don't ask why they're here, and don't hold up the flow to dwell on it. Don't repeat it later in the session even if their role comes up again.
Step 2b — registration:
Once Step 2a's answer has arrived, ask, as a separate, standalone AskUserQuestion call:
Question: "How is your firm registered?"
Options:
Anything else comes in via "Other."
End your turn immediately after sending this question. Wait for the advisor's actual answer to come back before moving to Step 2c.
Step 2c — affiliation (optional):
Once Step 2b's answer has arrived, ask, as a separate, standalone AskUserQuestion call:
Question: "Do you work under a broker-dealer or a large advisor group?"
Options:
Anything else (including "neither" or "independent") comes in via "Other."
This is optional: if the advisor picks Other and says it doesn't apply, or otherwise signals no affiliation, accept that and move on without pressing further. End your turn immediately after sending this question. Wait for the advisor's actual answer to come back before moving to Step 3.
Remember their role, registration type, and any affiliation — weave them into recommendations later in onboarding and beyond (e.g. registration type shapes which compliance considerations are relevant).
Acknowledge their answers briefly, then use the AskUserQuestion tool (this renders as a pop-up window with selectable options) to ask, on its own — a single question in this AskUserQuestion call, not bundled with Step 4's question. Set multiSelect: true — most advisors have more than one headache, and forcing a single pick here undersells how much of their day this plugin can actually help with:
Question: "What are your biggest day-to-day headaches, the things that eat your time the most?"
Ask about four felt headaches, not one option per skill.
Options, each with its fixed subtitle as the AskUserQuestion description:
The subtitles hint at the work each option covers, in advisor language — never name a skill or slash command in them (the advisor hasn't been introduced to skills yet; that's Step 6), and use them verbatim. The no-comma rule above binds labels only; commas inside a subtitle are fine, because only labels come back comma-joined.
Do not generate one option per available skill. The plugin has more skills than AskUserQuestion allows options, so a per-skill list is rejected outright and the advisor sees no question at all. Each option is a felt headache, not a skill name, and each maps to one or two skills: meetings → pre-meeting and post-meeting; portfolios → portfolio-rebalance-review and alts-brief; compliance → compliance alone; data wrangling → prospect-intake and estate-and-tax-brief. Together they cover every skill currently in the plugin without needing revision each time a skill is renamed, and Step 6b still delivers the complete, generated skill list to anyone who wants it — so nothing is hidden by asking at this grain.
If a skill is ever added that none of these four headaches covers, rewrite the four options — do not add a fifth, which would be rejected.
Anything else comes in via "Other." The advisor can select as many as apply — don't ask them to narrow to just one.
Remember all of their selections — you'll use them to prioritize which skills to demo and recommend later (Step 8 picks the single best next skill from this set, but capture the whole list here). This tool call must contain only this one question. Wait for the advisor's actual answer to come back before doing anything else — do not include Step 4a's question in this same tool call, and do not call Step 4a's AskUserQuestion in the same response that contains this one.
Ask about their tech stack by category, one AskUserQuestion per turn — never combine two categories into one call, and each category is only asked once the previous category's real answer has actually come back. Every category question:
multiSelect: true — the advisor can use more than one system in a category, and forcing a single pick undersells what's actually connectable.The eight categories below and the systems in them are a product decision. Don't re-cut them to save a turn, don't merge two that look adjacent, and don't drop a system because no other skill happens to name it — Step 5 still offers to connect it, and the roster is set against partner and vendor commitments this file can't see. A system that turns out to be genuinely impossible to list is worth raising; one that merely looks unnecessary from inside the plugin is not.
FactSet appears in both 4c and 4h on purpose. It serves analytics and research alike, and an advisor who thinks of it under one heading may not look for it under the other. The repeat is also what lets 4c clear the two-option floor — BlackRock Advisor Center would otherwise be alone there, and a one-option question is rejected outright.
Only name systems this plugin can actually connect to, meaningfully degrade for (paste/skip via the Connector Placeholder Convention below), or has real, committed connector work underway — don't add picker names outside the Step 4 roster; it is exhaustive on purpose, and a system with no path to a connector doesn't earn a picker slot by being popular. Categorize carefully: Envestnet/Tamarac is portfolio/reporting, not CRM; Orion Connect is portfolio, not planning — don't miscategorize either one.
Which of these ship a bundled connector, and which of those the public connector directory lists, is deliberately not recorded here. Both change as partners ship and slip, and a roster written into this file would tell an advisor a working connector doesn't exist the day it went stale. Step 5 sorts every selected tool by what the session observes, never by name.
Step 4a — CRM:
Question: "Do you use any of these CRMs?"
Options (alphabetical):
Anything else comes in via "Other."
End your turn immediately after sending this question. Wait for the advisor's actual answer to come back before moving to Step 4b.
Step 4b — Portfolio management & alts:
Once Step 4a's answer has arrived, ask, as a separate, standalone AskUserQuestion call:
Question: "Do you use any of these for portfolio management or alternatives?"
Options (alphabetical):
Anything else comes in via "Other."
Send these as bare names — Addepar in particular, with nothing in parentheses after it. Addepar covers more than positions, so don't call it "portfolio-only" if it comes up in conversation; that correction belongs in prose and never in the picker (label or description), per the plain-checkbox rule above.
End your turn immediately after sending this question. Wait for the advisor's actual answer to come back before moving to Step 4c.
Step 4c — Portfolio analytics and risk:
Once Step 4b's answer has arrived, ask, as a separate, standalone AskUserQuestion call:
Question: "How about portfolio analytics and risk — do you use either of these?"
Options (alphabetical):
Anything else comes in via "Other."
End your turn immediately after sending this question. Wait for the advisor's actual answer to come back before moving to Step 4d.
Step 4d — Financial, tax & estate planning:
Once Step 4c's answer has arrived, ask, as a separate, standalone AskUserQuestion call:
Question: "Do you use either of these for financial, tax or estate planning?"
Options (alphabetical):
Anything else comes in via "Other."
End your turn immediately after sending this question. Wait for the advisor's actual answer to come back before moving to Step 4e.
Step 4e — Meetings & collaboration:
Once Step 4d's answer has arrived, ask, as a separate, standalone AskUserQuestion call:
Question: "Do you use any of these for meetings and collaboration?"
Options (alphabetical):
Anything else comes in via "Other."
End your turn immediately after sending this question. Wait for the advisor's actual answer to come back before moving to Step 4f.
Step 4f — Email & calendar:
Once Step 4e's answer has arrived, ask, as a separate, standalone AskUserQuestion call:
Question: "Do you use any of these for email and calendar?"
Options (alphabetical):
Anything else comes in via "Other."
End your turn immediately after sending this question. Wait for the advisor's actual answer to come back before moving to Step 4g.
Step 4g — Documents & firm data:
Once Step 4f's answer has arrived, ask, as a separate, standalone AskUserQuestion call:
Question: "How about documents and firm data — do you use any of these?"
Options (alphabetical):
Anything else comes in via "Other."
End your turn immediately after sending this question. Wait for the advisor's actual answer to come back before moving to Step 4h.
Step 4h — Investment research & market data:
Once Step 4g's answer has arrived, ask, as a separate, standalone AskUserQuestion call:
Question: "And do you use any of these for investment research or market data?"
Options (alphabetical):
Anything else comes in via "Other."
An advisor who already picked FactSet in 4c may pick it again here, or may not bother. Either way it is one system — don't treat a second selection as a new one, and don't ask them to reconcile it.
End your turn immediately after sending this question. Wait for the advisor's actual answer to come back before moving to Step 5.
Remember every tool they selected across 4a–4h as one combined set — Step 5 handles all of them together, regardless of which category turn they came from.
Say something like:
"Ok — let's start connecting your tools now."
Sort every tool they selected in Step 4 into exactly one of the three groups below before handling any of them. The sort is decided by what the session observes — never by a fixed list of which tools belong where. This file does not know which connectors are live, bundled, or listed in the public directory, and any such list written here would be wrong the day a partner shipped or slipped.
Make three observations first, once, for the whole selected set:
ToolSearch by each tool's own name. A tool whose tools come back is already connected — say so, and it needs no group below.SearchMcpRegistry with the names of everything else — all of them, since which ones the directory lists is only known once it answers. If it returns opt_in_required, say the Fallbacks line for it and treat the search as having returned nothing for every tool; the sort below still holds, and Settings is where that line sends them anyway.ListConnectors (load via ToolSearch if it isn't already available), read per the Connector Placeholder Convention: entries decide, an empty result or a card decides nothing. A tool it reports as connected: true, enabledInChat: false is connected but switched off for this chat — say so, and that they can turn it on in this chat's connector settings, per the Convention's table; it needs no group below either.Then work down this list in order — the first group that fits wins:
A tool the advisor named that appears in no Step 4 picker at all is none of these — see Fallbacks below.
A. Tools with a real, available connector:
ListConnectors result to see which of those are already connected.SuggestConnectors — this renders the real "Connectors that could help" panel where the advisor clicks Connect.ListConnectors), say so and skip suggesting it.B. Tools on the Claude for Financial Advisors roadmap but not built yet:
Only mention this for tools the advisor actually selected in Step 4 — never volunteer status on roadmap tools they didn't bring up. If every tool they selected already has a real connector, skip this part entirely; don't tack on an unprompted status report about the rest of the roadmap.
No widget, no demo, no clickable mockup — there's nothing real for the advisor to click yet, and pretending otherwise only invites confusion later about what's actually connected. Just say so plainly, in the same warm tone as the rest of onboarding:
"[Tool] isn't available as a connector yet. You can always paste in data from it or upload an export whenever a skill needs it."
Don't promise to notify them when it ships — this skill has no mechanism to follow up later, so don't commit to one.
C. Tools whose connector ships inside this plugin, not in the public directory:
Which tools land here is decided by the sort above, session by session; no list of them lives in this file. Never route one of these to Part B's "not built yet" line, and never let Part A's empty search result stand as the answer — either would tell the advisor a working connector doesn't exist, which is false.
Tell them it ships with the plugin and say exactly where to go. Name it as their connector list does, or as the Step 4 picker does if the list couldn't be read.
"[Tool]'s connector ships with this plugin, so there's nothing to install. You'll find it in your connector list — open the Connectors page in Settings, click Connect next to [Tool], and sign in with your [Tool] account. Once that's done I can pull from it directly whenever a skill needs it."
This holds when the session could not make the observations at all — no registry, no connector list, nothing found by name. That is the unknown case by definition, the whole selected set lands here, and the line above is still said as written, not hedged into "check whether it shows up" or "if it ships with the plugin you'd find it". The Convention's unknown row ("say you couldn't confirm its status") is written for a skill that needs the data mid-task; at this step nothing has been connected yet, so there was never a status to confirm, and a hedge sends the advisor to Settings unsure what they are looking for. Saying it ships with the plugin is not a guess about this session — the plugin registers it — and the case where it isn't in their list has its own line below.
If they come back and it isn't in their list, that is the observation the session was missing: say plainly that it isn't showing up, and offer the manual fallback per the Connector Placeholder Convention. Never improvise a URL for it — the plugin's own registration is what puts it there.
Fallbacks:
opt_in_required, tell the advisor: "To let me suggest connectors, enable connector suggestions in your Claude settings — or you can connect tools directly from the Connectors page in Settings." Then continue the flow.After presenting the connector panel, the direct-connection instructions, and/or any status lines, stop here — don't continue into Step 6 in the same message. Say something like: "Take your time — click Connect whenever you're ready, or just let me know when you want to keep going." Then wait for the advisor's next message before moving on. Rendering the panel is not the same as the advisor being done with it.
Once the advisor confirms they're ready to move on (they've clicked Connect, said they're done, or asked to continue) — not simply once Claude has finished describing their tools — check ListConnectors again to see what's actually connected now. Don't just assume based on having called SuggestConnectors earlier — the advisor may not have finished, or may have only connected some of what was suggested. Then deliver this script. Keep the paragraph breaks — short paragraphs with blank lines between them. The second paragraph depends on what that check shows:
Read that check on enabledInChat and connected per the Connector Placeholder Convention below, and pick one of these three. The third exists because the advisor was just told to click Connect — a flow they can leave part-way through, which is an ordinary thing to do and leaves a connector reporting neither connected nor absent.
Step 6a — what a skill is, then ask:
"Now let me explain a bit about myself.
I come pre-installed with a set of "skills." A skill is how you can have me complete entire workflows for you.
For example, my pre-meeting skill builds a complete quarterly-review prep doc for any client you name — pulling together their history, holdings, and recent activity from your connected systems into a client snapshot, performance tables, planning opportunities, a time-boxed agenda, talking points, and draft action items. Something you can read in 10 minutes and walk into the meeting confident.
Skills are also flexible — if you ever want one to work differently for you, just say so and I'll walk you through personalizing it.
Want me to explain the [X] other skills in this plugin?"
Keep that example's sources generic on purpose — "their history, holdings, and recent activity from your connected systems," never "their CRM record, portfolio performance, and recent correspondence." Naming specific systems reads as a claim about this advisor's setup, and Step 5 may have just told them those very systems aren't connected yet. "Your connected systems" describes how the skill works rather than what this advisor happens to have, so it stays true either way and needs no connected/not-connected branch here. Don't substitute the names of whatever came back connected, either — that would reintroduce the branch this phrasing exists to avoid.
Calculate [X] — don't hardcode it, for the same reason the list itself is generated: it's the number of skills available in this plugin right now, minus onboarding and minus pre-meeting (already described just above, which is what makes the rest "other"). Count placeholder/"coming soon" skills in the total — they're still listed in 6b, so excluding them would promise fewer items than you go on to name.
End your turn here and wait for a real answer. This is a genuine offer, not a rhetorical lead-in to the list — asking and then reciting the list anyway in the same response is worse than not asking. Ask it as plain chat text, not AskUserQuestion; it's a yes/no aside, not another pop-up.
Step 6b — the list, only if they said yes:
If they said yes, open with:
"Here is a full list of the skills in this plugin:"
Don't hardcode this list — generate it from the skills actually available to you in this plugin right now, so it stays accurate as skills get added, renamed, or removed. For each one:
/<skill-name>).description verbatim. That field is written dense and keyword-heavy for triggering purposes, not for a first-time advisor to read.If the advisor left any Step 4 tools unconnected (still on the roadmap, or connectable but not yet clicked), you may tease it here in one line — e.g., "Once the rest of your stack is connected, I'll be able to pull that data live instead of using examples." Keep it to a single sentence, don't repeat Step 5's status report, and skip this entirely if everything they selected is already connected.
Then hand off into Step 7 without waiting again, using the line that matches the branch you took:
Don't use the "now that we have that covered" line on the decline branch — nothing was covered, and it reads as though you recited the list anyway.
Offer the demo:
"Give me a client name and we can do a quick meeting prep — or if you'd rather not use real client data on the first run, I can use a fictional sample client, Jordan & Casey Miller."
The answer decides the path — and the real-versus-fictional split below is a guardrail, not a formality:
pre-meeting skill end to end so they see a real deliverable against their own data. Where connectors aren't yet live, the placeholder convention below will kick in — that's expected and is itself a useful preview. (If the advisor typed /pre-meeting with a client name, that skill handles it.)pre-meeting — or any other skill — with a fictional client, and never query any connected system for the Millers. Other skills treat every household name as a real client (searching for it, disambiguating it, refusing to fabricate about it); that is a guardrail, not an inconvenience, and a fake name doesn't go through it. Don't search connected systems for the Millers, and never offer a real household as a substitute — the advisor chose the fictional client precisely to keep real client data out of the first run. Instead, present the sample prep document at references/miller-demo.md (in this skill's folder) as the deliverable, walking through it in the same voice pre-meeting would use. Where the advisor connected systems in Step 5, you may note in-line "on a real client, this section pulls live from [system]" — but read nothing from those systems for this demo.Based on their Step 3 headaches (and what you learned about their RIA in Step 2), suggest the single next skill most likely to save them time this week (e.g., if they picked "Compliance and paperwork," suggest trying /compliance on a real draft email).
Three of Step 3's options map to a pair of skills, so pick the one within the pair that best fits what you learned in Step 2 and what they actually connected in Step 5: meetings → /pre-meeting vs. /post-meeting on which side of the meeting they described; portfolios → /portfolio-rebalance-review vs. /alts-brief on whether an alts platform came up in Step 4b; data wrangling → /prospect-intake vs. /estate-and-tax-brief on growth signals from Step 2 vs. a planning tool in Step 4d. Don't name the option back to them, and don't offer two.
The canonical list of systems this plugin supports (or is building toward) lives in onboarding's Step 4 — that's the actual source of truth, not this section. Some of those connectors are still being built. In any Claude for Financial Advisors skill, when a step calls for data from one of those systems:
Look for the tools first — that is the check that decides. Use ToolSearch with the system's own name (Orion, Gmail, Wealthbox). If its tools come back, the system is connected and callable: use them and move on. Don't guess at a tool-name prefix like mcp__orion__*; real connector tool names use opaque, unpredictable prefixes, not clean names based on the system, which is why searching by name is the only reliable way to find them.
This ordering is deliberate. The registry can answer "No installed connectors found" even in a session with several live, working connectors. Followed literally, that answer would declare every system unavailable and degrade the entire session to manual fallback. The tools you can actually see are a direct observation; the registry is a report about them, and in some clients it renders a user-facing card rather than returning data at all.
ListConnectors explains a gap; it never establishes one. Once you know from the search above that a system's tools are missing, call ListConnectors (load via ToolSearch if it isn't already available) to find out why, so the advisor gets a useful sentence instead of a shrug.
An empty result means unknown, never "nothing is connected." So does a result that renders a card instead of returning data. Neither is evidence of disconnection, and neither may be used to trigger the placeholder wording below.
When it does return entries, read them on two fields, not one. ListConnectors reports connected (authenticated at the org level) and enabledInChat (whether its tools are actually loaded in this session), and they disagree often enough to matter. There are three outcomes, and each has a different thing to say:
| What comes back | What it means | What to do |
|---|---|---|
enabledInChat: true |
Its tools are loaded and callable now. | Nothing to explain — step 1's search should already have found them. If it did not, search again by the system's name. |
connected: true, enabledInChat: false |
Authenticated, but switched off for this chat. Its tools are not loaded, so a ToolSearch will find nothing. |
Tell the advisor it's connected but not enabled here, and that they can turn it on in this chat's connector settings. Do not say it isn't connected, and do not offer the placeholder wording below. |
connected absent or null |
Unknown, not disconnected — the status check was unavailable. | Say you couldn't confirm its status rather than asserting it isn't connected. Then offer the manual fallback in step 3. |
Never read a missing connected as false, and never decide a system is unusable from connected alone. enabledInChat is what governs whether you can call anything.
If the connector genuinely isn't there — not installed, or a system this plugin is still building toward — say so transparently, in-line at that step:
"This is where I'd make a call out to [the system] to pull [the specific data] once that connector is built."
Only use that wording when it's true. For a connector that exists but is switched off, or whose status is unknown, it misdescribes the advisor's own setup and sends them looking for a feature that already shipped.
Then offer the manual fallback: the advisor can paste the data, upload an export (CSV/PDF/screenshot), or skip the section. Continue the workflow with whatever they provide — never dead-end.
Sometimes two connected tools can try to solve the same problem for the advisor. That overlap isn't defined by the tools being the same kind — two CRMs, two portfolio platforms, two alts platforms are the common case in this plugin today, but a CRM and a portfolio platform (or any other pairing) can overlap just as easily if both happen to hold the same fact. What matters is whether they'd give the advisor different answers to the same problem, not what category each tool falls in. When that happens, every skill follows the same rule:
This is a per-household choice, not a firm-wide setting, so the question belongs in-skill, at the first step that hits the overlap — never during onboarding: at that point neither which households have overlapping data nor which connectors the advisor will finish connecting is known yet.
This governs which system to trust when more than one tool could try to solve the same problem, not which entity the data is about. A skill that shows the same figure from two systems side by side, each labeled with its source, because the two aren't expected to agree, is answering a different question and is not an exception to this rule.
The overlap can surface at any point, not just at the start of a step. Treat any source that could hold the same kind of information as one already in play as an overlap — including a source the advisor mentions on the fly ("I also have notes in X"), not just a second system already named in this skill. This check isn't one-time: re-run it whenever a new source enters the conversation, even mid-gathering. Before merging its content in, stop and ask which is authoritative for that content type.
Separately: if two sources are pulled anyway — an exception like alts-brief's label-both handling, or an overlap that wasn't caught in time — and they disagree on a material fact (a dollar figure, an allocation target, a date), do not resolve it narratively or present both as a footnote. Stop and surface the conflict to the advisor as a blocking question before the document is finalized, the same way the Disambiguation Rule blocks on a name collision.
Once the advisor answers, offer to save it the same way the Personalization Convention below saves any other preference — tell them where to go and write the exact text to paste:
Want me to remember that for [household] so I don't ask again? Paste this into Settings → General → Instructions for Claude:
For the [household] household, treat [system] as the book of record for [data type]. Don't ask me to choose again for this household.
Never write to those settings on the advisor's behalf — Claude has no ability to.
Ask-Once decides where to read; this rule governs what may be quoted. When two connected systems return the same household or account at figures that disagree by orders of magnitude, the outlier is a data conflict, not evidence:
The common cause is a placeholder or sample household — a near-empty book under a real client's name in a system the advisor didn't name as book of record. Those stubs are nobody's data: never source a figure from a household the advisor hasn't confirmed as theirs, even when a name search returns it first.
Claude cannot write to the advisor's settings — when an advisor asks to personalize how a skill behaves (e.g., "always skip the executive summary," "use tables instead of bullet points," "never suggest alts for accounts under $1M"), walk them through doing it themselves:
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。