How to Customize Claude for Financial Advisors: Firm Rules, House Style and Private Skills

1. Why Customize at All

Anthropic wrote the eight skills for every RIA at once. That makes them a good start and a loose fit for any one firm, because the rules that make your firm yours are exactly what they cannot know.

Four gaps show up first:

• The compliance rules are generic and frozen. /compliance works from references/sec-compliance-checklist.md, which the skill itself calls "a static snapshot, not a live firm-rules feed." It covers the Marketing Rule, Section 206, Rule 204-2, and Reg BI and FINRA 2210 for dual registrants. Your required disclosures, banned phrases and review standards appear nowhere in it. (The compliance guide covers what it does check.)
• Your CRM notes have a format. /post-meeting writes notes, tasks and opportunities through your CRM's own objects, in a default structure. If your firm has a note template, the skill has never seen it.
• Your IPS and models have names. /portfolio-rebalance-review measures drift against the IPS or model and drafts a rationale memo with a blank approval table. Your model names, drift bands and required reviewers are yours to supply.
• Your disclosures have approved wording. /compliance drafts ready-to-paste disclosure language. If your firm already has approved language, that is what should be pasted.

Betterment's advisor playbook frames skills as encoded versions of a firm's own processes. That is the right frame. Customizing the plugin means writing down how your firm already works, in a form Claude follows every time.

2. Three Layers, and When to Use Each

A change can live in one of three places. Each has a different owner and a different reach.

To choose, ask one question: would it be wrong for another advisor at your firm to do this differently? If yes, it belongs in layer two. If it is a matter of taste, layer one.

If no skill does the job at all, that is layer three. Layer two is where the compliance rules live, so it deserves most of your attention.

3. Layer One: Personal Instructions

Claude cannot change its own settings, so the plugin cannot either. When an advisor asks for a skill to work differently, the plugin's approach, spelled out in its onboarding skill, is to write a short instruction and tell the advisor to paste it into Settings, General, Instructions for Claude.

Good uses are matters of taste, such as "put the agenda before the snapshot in my prep documents" or "keep talking points to five bullets." Keep each one narrow, and name the skill it applies to.

Two limits matter. These instructions apply to every conversation that advisor has, not only the plugin. And they belong to one advisor, so they bind nobody else.

A disclosure rule that lives in one advisor's settings is a rule the other advisors are not following, and one that never passes through the CCO's review of the firm's skills. Personal instructions are for how an advisor likes to read, and anything the CCO would want to see goes in the fork.

4. How a Skill Is Built

Open the repository before you edit anything. The plugin is Markdown and JSON, with nothing to compile, and its layout is simple:

• skills/<skill-name>/SKILL.md holds one skill. The file starts with a short frontmatter block containing a name and a description, followed by plain-English instructions: the inputs, the steps, what is out of scope and the rules the skill must follow.
• templates/ inside a skill folder holds the shape of the output. The prep document is skills/pre-meeting/templates/pre-meeting-template.md, and the rebalance memo is skills/portfolio-rebalance-review/templates/rebalance-rationale-memo.md.
• references/ holds material a skill reads while it works. The compliance checklist lives in skills/compliance/references/, and the fictional Miller household for the onboarding demo lives in skills/onboarding/references/.
• agents/<name>.md defines a subagent with one narrow job, such as reading one connected system for one household or scanning a draft against the checklist. Each file declares the tools that agent may use, or the tools it is denied.
• .mcp.json declares the connectors, and .claude-plugin/plugin.json holds the plugin's name, description and version, currently 1.0.0.

The description does more work than it looks. The plugin's contributor guide says: "Keep the description short; it is the trigger signal." Claude reads the descriptions to decide which skill fits what an advisor asked for.

The pre-meeting skill's description, for example, lists phrases such as "prep for [client]" and "quarterly review prep." Edit a description carelessly and a skill may stop starting when advisors expect it, or start when they do not.

Treat the instructions as the program. A sentence in a SKILL.md file does the work of a line of code: delete it, and the behavior goes with it.

5. Layer Two: Fork the Plugin Into a Private Repository

The repository is public under the Apache 2.0 license, and its contributor guide is written for anyone forking or adapting it. Anthropic also describes it as "Not actively maintained or monitored, and not accepting contributions," so treat your fork as your firm's own version, maintained by you.

1. Make the copy private. Create a repository in your firm's GitHub account and copy the plugin's files into it. Your review standards and banned phrases are internal documents, and a public copy would publish them.
2. Install the Claude GitHub App on that repository. The organization marketplace needs it to sync from a private or internal repository.
3. Keep the skill names. Leaving the folders and name fields alone keeps the slash commands your advisors already know.
4. Work in small pull requests. One change per pull request, with the version number in .claude-plugin/plugin.json bumped each time.

Before each merge, run the checks the contributor guide asks for: confirm that plugin.json, marketplace.json and .mcp.json are valid JSON, and that every relative path a SKILL.md mentions exists. A skill pointing at a file that is missing has nothing to follow.

6. The First Edits Worth Making

Start where a wrong default costs the most.

/compliance: your rules on top of the SEC's

Add a firm rules file beside the checklist, such as skills/compliance/references/firm-rules.md, and edit the SKILL.md so the skill reads it alongside the checklist, including when it hands the checklist to its scanning subagent. Put in your required disclosures word for word, your banned phrases, your review standards, and anything specific to your registration, such as your state's rules if you are state-registered.

A separate file makes each rule change easy to review, and it leaves Anthropic's checklist intact for comparison. Leave the skill's escalations exactly as they are: performance, hypothetical performance and testimonials always go to the CCO, and your additions should only lengthen that list.

/post-meeting: your note format

Describe your CRM note format in the skill: the headings in order, the required fields, how tasks are named and who they go to by default. The skill already writes through the CRM's own objects (notes, tasks and opportunities in Wealthbox; notes, activities and opportunities in Redtail), so your edit shapes only the content.

The rebalance review: your IPS and models

Add your model names, target allocations and drift bands as a reference file. Then edit the rationale memo template so its approval table lists the reviewers your firm requires, and leave the table blank for the advisor to sign, as it is now.

The prep document: your house style

The prep document's structure lives in the pre-meeting template. If your advisors want the agenda first or a longer section on life events, change the template once instead of asking each advisor to write personal instructions.

Four edits, and the plugin starts to sound like your firm.

7. Sync Your Fork to the Firm as Required

On Team and Enterprise, Owners manage plugins in Organization settings, Plugins and skills. Add a marketplace that syncs from your private repository, then set your firm's plugin to Required, so members cannot remove it.

How the sync behaves, per Anthropic's admin help page:

• A sync runs when a pull request with a version bump merges, and takes up to 30 minutes.
• If a sync fails, members keep the last synced version.
• Members cannot edit organization-managed plugins.
• On Enterprise, access can be set by group, and for someone in two groups the most permissive setting wins.

Then restrict the public version. On Enterprise, admins can restrict which plugins members install, and an advisor running Anthropic's copy beside yours would be working from two sets of rules.

The version bump works as a release button. Changes reach advisors when someone deliberately merges a numbered release, which is the kind of control a CCO wants.

8. Layer Three: New Firm Skills

Some processes have no skill at all. A new one is a new folder, skills/<your-skill>/SKILL.md, with a name, a short description written as the trigger, and the instructions, plus templates or references if it needs them.

Good candidates are repeatable jobs with a known shape, such as a quarterly client letter built from your house market commentary, or a checklist for a new household's first 90 days. Write the steps the way you would train a new associate: the inputs, the sources, the output, and what the skill must refuse to do.

If the job needs a system the plugin does not reach, check the connectors guide first. If nothing covers it, that is a connector project, and the MCP guide explains what building one involves.

Before writing a ninth skill, check whether one of the eight already does most of the job. Editing a template is cheaper than maintaining a new skill.

9. The Design Rules to Keep

The plugin's contributor guide sets five design rules for anyone who forks it. Adopt them as firm rules for every skill, old or new:

1. No client data in the repository. Demo material must be clearly fictional. Real statements, holdings, names or account numbers never go in, even redacted.
2. Every write to an external system pauses for advisor approval. A skill may draft a CRM note, a task or a client message, but it stops and asks before anything leaves the session.
3. No trade recommendations or execution. Skills describe options and surface data, and the advisor decides.
4. Client-facing output routes through /compliance. If a skill produces something a client might see, it says so and points to the check.
5. Degrade gracefully. When a connector is missing, fall back to paste or upload instead of failing.

One more line from the same file is worth keeping: add a connector to .mcp.json only when a skill actually reads from it. Every connector you add is one more system with access to review.

10. What Never to Change

The README splits the plugin's guardrails into two kinds, and that split matters more than anything else in this guide.

Some guardrails are structural. In the README's words, "the file-parsing subagents are allowlisted to read-only tools, and the connector-reading subagents are denied shell, file-write, and web tools." Those limits live in each agent file's tool list, and the software enforces them.

The rest depend on the instructions. Advisor approval before any write, connector-reading subagents never calling a connector's write or send tools, and arithmetic in a shell that never sees document text are, per the README, "enforced by the model following them, not by the runtime."

So some of the plugin's safety lives in plain sentences. Delete one in a tidy-up and that guardrail goes with it. In your fork:

• Never remove or soften an approval step before a write.
• Never add a tool to an agent's allowed list, or take one off a denied list, without reviewing everything that agent reads. Those agents read prospect statements, client emails and CRM notes, and the README says to "Treat that content as untrusted."
• Never let a skill execute or stage a trade.
• Never delete the CCO escalations in /compliance, its description of its output as a draft review for the CCO, or its reminder that its scratchpad is not the firm's books and records.
• Never pass document text into the shell used for arithmetic.

Any pull request that touches this list needs the CCO's sign-off, and the default answer is no.

11. Test on Fictional Households

The onboarding demo uses a fictional household, the Millers, so no real client data is used. Test your changes the same way.

Build a small test pack of made-up material, labeled fictional, and keep it in the repository:

• A meeting transcript with two firm commitments and one vague one, for /post-meeting.
• A marketing email with a performance figure, a testimonial and one phrase from your banned list, for /compliance.
• A holdings export with one sleeve outside its band and a recent loss sale, for the rebalance review.

Run each item through the old version and the new one where no real connectors are live, such as a test account, so a skill never goes looking for a made-up name in your real CRM. Every skill accepts pasted or uploaded material when a system is not connected.

Check what you changed, then check what you did not: the testimonial still escalates to the CCO, the approval batch still appears before any write, and the memo's approval table is still blank.

A change that passes its own test and breaks an escalation is worse than no change.

12. Version Every Change and Put the CCO in the Loop

Every change is a pull request. Any pull request that touches /compliance, a client-facing template or an approval step needs the CCO's review before it merges.

Write each one so a reader who was not there can follow it: what changed, why, which test cases ran, and who approved. Bump the version in plugin.json, merge, and the sync takes it from there.

The history that builds up is useful evidence. When an examiner asks how you supervise the firm's AI use, a dated list of every rule change to the tool, with its approver, is a strong answer. Whether that history belongs in your formal books and records is a question for your CCO and counsel.

Set a review trigger too. The checklist is a snapshot, so when the SEC updates its guidance or your firm changes a disclosure, someone has to update the reference files. Put that duty in your AI use policy with a name next to it.

A snapshot stays a snapshot until someone updates it.

13. Where to Start

Work in this order:

1. Copy the plugin into a private repository.
2. Add your disclosures and banned phrases to /compliance.
3. Add your note format to /post-meeting.
4. Run the test pack and get the CCO's sign-off.
5. Sync it to the firm as Required.

Personal instructions can wait until advisors ask, and new skills can wait until the first edits have run for a month.

If the plugin is not installed yet, start with the setup guide, and read the complete guide to see what each skill does before you change it. The customization FAQ has the short answer for colleagues, and the training guide covers bringing advisors along.