3. Client Plugins
Note: The video covers material not in the guide below — please watch in full.
Action Step
Complete this before moving on.
Clone the duped Coactive plugins repo (Coactive Plugins 0612) into your own GitHub — add it as an existing repo, refresh, then open it and point Claude at it so it walks you through what each of the five plugins does. As you explore, internalize the key lesson: you build these with the Salesforce CLI as the operator, but you QA them using the exact runway the client will use — the read-only Salesforce MCP connector — by adding the marketplace yourself and running the plugin through that connector. If you haven't done the Salesforce MCP course or the Google Drive internal-folder setup training yet, knock those out first.
Training Guide
Now let's look at real plugins we've already built for a customer — how we made them, how we tested them, and what the whole thing looks like end to end. The customer here is Coactive.
Here's what we've shipped so far.
The Plugins We Built for Coactive
As of recording — almost mid-June '26 — we've created five plugins for Coactive: pipeline hygiene, pre-call prep, post-call, morning brief, and leadership morning brief.
You can't get into the original Coactive repo unless you're on their account — they have permissions locked down. So I duped a copy into a separate repo called Coactive Plugins 0612. Add it as an existing repo in your GitHub, clone it, hit refresh, then open it and point Claude to it — Claude will tell you more about everything inside. There's also a write-up Claude created for each plugin showing what happens when the skill runs (that's separate from the skill's own .md file).
The more important part is how these actually get made.
How We Build Them: Working Log + Salesforce CLI
The way I work, I drop a working log into every project — it's easy to add a folder and keep going. For Coactive, that lives inside the Coactive internal folder, which is the Google Drive equivalent (there's a separate training on setting that up, so check that out if you don't have it yet).
To build a plugin, you're approximating whatever skill lives inside it. Right now the pipeline hygiene plugin is just one skill — a pipeline hygiene skill inside a pipeline hygiene plugin — and down the road it may grow. You develop it using the Salesforce CLI: connect to Coactive's Salesforce and start drafting what the plugin should look like, collabing with Claude as you go.
Why the CLI? Because a client plugin has to be customized. For pipeline hygiene, you need their stages, the fields on those stages, their objects — so when the rep or GTM leader downloads it in Cowork and runs it, nothing breaks. The plugin has already been molded ahead of time by us, the operators. I built all of these in VS Code first, then just grabbed the repo path and asked Claude to move the plugins into the client's marketplace.
But how you build is not how you test.
Build With the CLI, QA With the Connector
The Salesforce MCP is a requirement to properly QA this (there's a whole separate course on setting it up).
Here's the trap: you build as the operator through the CLI, where you have unlimited permissions — so of course it works for you. But the client runs it on a different runway: the MCP connector, which in Coactive's case is object read-only. If you skip QA-ing on that connector, you ship it to their marketplace and it doesn't work.
So set it up exactly the way it'll look on the client side. Load the plugins into your own Customize — not at the org level, since we don't put client plugins on the LeanScale level — add the marketplace yourself, then run the plugin using the exact connector the customer will use. Get as close to their real conditions as you can.
Beyond the core skill, a plugin is a product — so think like a product builder.
Thinking Through the Whole Plugin
You'll also lean on the Plugin Maker plugin here. It's available via slash commands in VS Code, or you can reveal LeanScale's marketplace in Finder, Option-copy the Plugin Maker path, and tell Claude to use it directly.
Then think through commands, hooks, sub-agents, and connectors. Inside Claude you can hook up a bunch of tools, so simulate the client's tech stack — maybe the Gmail connector, the Fireflies connector, whatever they run — by connecting it in your own account and baking it into the skill. Use Claude as your thinking partner: "I think hooks might help here — give me examples of hooks we could build into this plugin."
Building a plugin feels like writing a spec doc and an architecture inside that folder. Scope the use cases, connect the tools, get everything on the table. You're packaging a real product. The next pipeline hygiene plugin for another customer will probably be 50–60% bespoke and 40–50% reusable best practices — this is V1, and we build on it.
The Client Request Flow
With Coactive, there's a GTM help desk channel where they submit a workflow requesting a plugin or skill. When a client asks for one: map the flow and architecture with Claude, create the repo with the files, then have Claude simulate it — "run one for me, let's see what it looks like." Deploy it into the marketplace, commit and push, then QA again in the customer's instance through Cowork and the connector.
Wrap-Up
That's the end-to-end of building a plugin as a customized client asset: scope it to their Salesforce with the CLI, build it as a product with the right connectors and sub-agents, and QA it on the exact connector they'll run it on. It keeps getting better the more clients we do it for — this is just what we have for Coactive so far.
Comment in Slack
Post your answer in your onboarding channel.
What was your biggest takeaway(s) from this training?