Claude Code in the Wild: From MCPs to Skills to Plugins

Guest Speaker

Meet Brandon Guerrero

Brandon Guerrero

Senior GTM Engineer at The Kiln • Founder of Orchid Automation • Mentor at Clay Bootcamp

Brandon is a senior GTM engineer at The Kiln, where he ships plugins for client updates, campaign QA, and project management across a 20-30 person team. He also runs Orchid Automation, the home of SendLens (Instantly analytics done right) and Pluxx (one plugin source, compiled to every agent host). On the side: Clay Bootcamp mentor, Stack mentor, and Maven instructor.

His background is data engineering, which shows up in how SendLens treats every answer as a structured query against a DuckDB cache, not a vibes summary. His pattern: solve the workflow once, then package it so the team can trust it.

Session Overview

What we covered

📦

A plugin is the box the primitives ship in

MCPs, skills, agents, hooks, and commands are the primitives. A plugin is the installable, versioned container that bundles them so the team can one-click install everything at once.

🪝

Hooks are the deterministic check

If something must happen every time, it cannot live in the prompt. Hooks run before or after a workflow, regardless of what the model decides. API key checks, cache freshness, banned phrases, file safety.

📊

SendLens, live

Brandon's free, open-source plugin for Instantly. Pulls campaign data into a local DuckDB cache via MCP, routes natural-language questions through skills and specialist agents, and returns answers with evidence labels attached.

🔄

Pluxx, in preview

A CLI for plugin authors. Maintain one source project, compile native outputs for Claude Code, Cursor, Codex, and OpenCode. Different manifests, different hooks, different MCP locations, all handled.

The Stack

What sits inside the plugin box

Six layers, six jobs. A plugin is what you get when you decide a workflow has graduated from your machine to the team's.

Access

MCP

External systems, APIs, databases. The hands of Claude Code.

Process

Skills

Repeatable SOPs and playbooks. How the work should get done.

Entry point

Commands

Slash commands. Memorable, deterministic ways to invoke a workflow.

Specialization

Agents

Focused analysts, auditors, reviewers. Sub-agents that protect the main context window.

Reliability

Hooks

Checks that run every time. Setup doctors, safety blocks, cache refresh.

Distribution

Plugin

Installable, versioned, team-ready. The package that ships everything above.

Plugin Anatomy

What a real plugin looks like on disk

Brandon walked through the SendLens repo. This is the file tree he showed, annotated.

sendlens-plugin/

skills/        # playbooks
agents/        # specialists
commands/      # entrypoints
hooks/         # checks
scripts/       # runtime glue
docs/          # user guidance
.mcp.json      # data access
dist/          # host bundles

Live Demo

SendLens, end to end

A natural-language question routes through skills and specialist agents, queries a local DuckDB cache via MCP, and returns an answer with evidence labels attached. Built because the analytics Instantly ships are nowhere near enough to derive actionable insight from a campaign.

1 /plugin Open the plugin marketplace inside Claude Code

Forward-slash plugin pulls up the marketplaces Brandon has installed. Anthropic's official marketplace, Every's compound engineering plugin, the SendLens GitHub repo as a marketplace. One-click install, no copy-paste of skill files.

2 SendLens MCP 11 tools provisioned automatically

The plugin ships its own MCP. Refresh data, list tables, list columns, run analysis. The user does not figure out where skills live or how to install the MCP. Installing the plugin sets all of it up.

3 /copy-analysis Run a real analysis on a campaign

Brandon ran copy analysis on a healthcare-operators campaign (fake data for the demo). The command calls a skill, the skill calls a specialist agent, the agent queries the local DuckDB cache via the MCP. What is working, what is hurting, what to change. Each insight tagged with the evidence label that backs it.

4 Hooks A pre-flight check before the chat starts

SendLens uses a SessionStart hook to call Instantly, write fresh data to the local cache, and confirm the API key exists. The plugin will not run until the cache and the key are both verified. No "did you remember to refresh first?" Slack messages.

🔗

Try SendLens yourself

Free and open-source. Clone it, install it, point it at your Instantly workspace.

Open the SendLens repo →

Principles

How Brandon decides what to build into a plugin

Solve the workflow once

The hard part is no longer making Claude Code do something one time. The hard part is making the workflow reliable, repeatable, and usable by someone who is not you.

If it must happen every time, hook it

A prompt asks Claude to remember. A hook actually runs the check. Use hooks for setup doctors, API key checks, cache refresh, banned phrase blocks, sub-agent enforcement.

A skill tells Claude how to work. A plugin ships the work

Skills are personal or project-scoped playbooks, best when atomic. Plugins are the packaged workflow your team installs once and runs the same way you do.

Parameterize the process, not the client

Build skills as processes, not client-specific scripts. Pass arguments to commands. The same generate-ICP skill should run for every client, with the client name as a parameter.

Skills you download are not your skills

Use other people's plugins as inspiration. The skills you actually run for your business should be ones you built and curated. Compounding knowledge over time beats a download.

Start with a workflow you already did the hard way

Repeated weekly. Context-heavy. Quality varies by operator. Small parameters change. Needs setup checks. That is your first plugin candidate.

What Else To Build

GTM in Claude Code is more than outbound automation

Outbound is the obvious case, but Brandon's team at The Kiln has plugins for the whole client lifecycle. Most invisible workflows on a GTM team are plugin candidates.

📝

Meeting follow-up packs

Standardized client recaps from a call transcript.

📊

Account briefs & stakeholder prep

Deep research on a prospect, packaged the same way every time.

✅

Campaign QA & launch readiness

Pre-launch checks against your team's standard for what "ready" means.

📣

Sales handoff QA

Catch what a CSM needs before the kickoff, not after.

🔎

Customer proof search

Surface the right case study, quote, or stat for the call you are about to walk into.

🧹

CRM hygiene audits

Run the same cleanup pass weekly. Catch stale data before it becomes a forecast problem.

Q&A Highlights

Questions Brandon answered

Are hooks like the /doctor command? They check that things are okay?

Yes, that is one use. The bigger use is deterministic enforcement. Brandon has a hook that blocks Claude from sending a Slack message until he approves it. Another that forces a Monday.com update through a sub-agent instead of the main agent. Another that catches em dashes in client communications even when his skill says "never use em dashes" and the model still slips one in. Hooks run whether the LLM wants them to or not.

Can hooks stop Claude from leaking API keys or deleting files?

For destructive things, the right tool is Claude Code's permissions and sandbox modes. Disallow bash deletions, restrict file scopes. For API keys, the rule is simple: never paste an API key into chat. Use a .env file and have the code read from it. Hooks can add an extra layer for project-specific rules, but permissions are the primary defense.

For multiple clients with different ICPs and sequencers, do you build one plugin per client or one monorepo?

Build the plugin as a process, not a client-specific script. Use commands with arguments, so the same plugin runs for every client with the client name passed in. Architecture is preference: a plugins repo plus a separate clients repo works well. Plugin per client is usually overkill. The Kiln runs a single plugin for client work and stores client-specific knowledge in a separate repo.

How do you handle copywriting in Claude Code?

Brandon took every Eric Nowoslawski cold-outbound video, pulled the transcripts via the YouTube transcript API, fed the lot to Claude, and asked it to build skills that write like Eric. The takeaway he kept coming back to: the model is smart enough to translate intent into decent copy, so context (pain points, triggers, who you are talking to) matters more than exact wording. Eric's coldoutboundskills repo is now public, so you can skip the transcript work.

Are there plugins or skills you'd recommend for auditing GTM builds?

Mostly, build your own. Skills you download are not your skills. The exceptions Brandon trusts: the official front-end design plugin (he uses it for slide design and product UI), the Skill Creator plugin (turns a finished session's output into a reusable skill), and Every's Compound Engineering plugin for engineering work. For GTM-specific audits, curate your own over time. That compounding knowledge beats any one-shot download.

When do you decide a workflow is worth turning into a plugin?

Five signals: it is repeated weekly, it is context-heavy (you keep pasting the same setup into chat), quality varies when a teammate runs it, the parameters that change are small while the shape stays the same, and it needs setup checks (a key or cache that has to exist for it to work). When you hit those, package it.

How does Brandon's build process actually look?

"I am repeatedly banging my head against the wall on this particular problem. I know there is a better way. I do not want to do it again." Pattern matching. He consumes a lot of content (Every, How I AI, AI & I, Twitter), pairs that inspiration with first-hand problems, and codifies the best practice as a skill. Then experimentation. "We have AI now. We can just do things."

Stack & References