In our last post, we walked through instance context: the reference document that teaches your AI what your Marketo instance looks like (such as your folders, naming conventions, channels, tokens, and fields).

That solves the knowledge problem, turning a generic AI into one that knows its way around your specific setup.

But knowing your way around a place isn’t the same as knowing how to do the work inside it.

That’s the gap we’re closing today.

Instance context handles knowledge, while Claude Skills handle process. Together, they turn your AI from a clever tool that can reach into Marketo into a teammate that can actually run Marketo processes.

From Context to Process

Think about almost any real task in Marketo. It’s rarely a single click; it’s a sequence. You clone a program, rename it to your convention, move it to the right folder, set the tokens, check the smart campaigns, and leave it for approval. The order matters, and each step depends on the one before it.

Doing that work through the API in a chat window is far less forgiving than doing it in the Marketo UI itself. The UI hides complexity behind clicks. You drag a program into a folder, right-click to clone, and see every token on one screen. The API, however, offers none of that. It’s dozens of granular endpoints, and you have to know which ones to call, in what order, and with which IDs.

The Marketo MCP runs on that API, so an AI working through it inherits all of that non-intuitiveness. Left alone, it will probably find a path to get the job done. But it might not be your path. It might be slower, more expensive, or subtly wrong.

This is where skills come in. A skill is a written playbook your AI reads before executing a specific type of task. It spells out the workflow: the steps, the order, the API calls, the decision points, the edge cases, and the moments where the AI should stop and ask you instead of guessing.

Thing of it like this. If “instance context” is the onboarding doc you hand a new hire, skills are the SOPs. One teaches them how the company works, while the other teaches them how to do their job.

Skills and Instance Context Work Together

It’s important to keep in mind that skills should never hardcode the facts about your instance.

A skill shouldn’t have your “Webinars” folder ID baked into it or carry its own copy of your naming pattern. Instead, every time it runs, it reads the instance context first and pulls what it needs. This way, there is a single source of truth.

When someone updates a template with a new token or destination folder, they change it once in the context, and every skill picks it up automatically. You’re never hunting through five skills to fix the same folder ID.

Instance context holds the “information” (what exists and what the rules are). And Skills hold the “procedures” (what to do and in what order). Information will change often, but procedures change rarely. That’s why keeping them separate makes it much easier to maintain both.

One last thing to add is that when a skill reads folder trees and template IDs straight from the context doc, it doesn’t rediscover them on every run. That saves API calls. And since Marketo limits how many calls you can make in a given window, every wasted discovery call has real cost.

Three Skills in Action

Now we’re going to run through three specific skills to illustrate all of this in action. These aren’t meant to be in-depth tutorials, so we’re going to keep it high-level.

Our goal is to show you the shape of a skill and the spots where the API turns out trickier than the UI ever lets on.

1. Clone Program

Here, you type something like “set up a webinar for next Thursday,” and the skill hands you back a fully placed, named, and tokenized program in one pass. Roughly, here’s the path it follows:

1. Read your request for the details: program type, name, date, region, any token values.
2. Pick the right template based on program type, and confirm the name against your naming convention. If the template choice is ambiguous, ask rather than guess, since that choice drives the channel statuses and smart campaigns downstream.
3. Find the destination folder and clone.
4. Set every token you provided, and ask for any required ones still missing in a single consolidated question.
5. Surface the smart campaigns, ask which to activate, and log a follow-up task for the remaining manual steps.

A few of these steps are sneakier than they sound.

For example, take finding the right template. In the UI, you just browse to your Templates folder and right-click clone. Through the API, the AI has to know which folder holds your templates, query the programs inside by folder ID, and then tell the live template apart from the deprecated lookalikes sitting right next to it. Instance context shortcuts all of that, since the template list and IDs are already written down. Several discovery calls drop to zero.

Folders are the same story. A quick mouse drag in the UI becomes a folder-tree query through the API. And the right home for a new program usually isn’t the top-level type folder; it’s a year or category subfolder underneath it, so the skill carries a rule like “always drill at least one level down before cloning” while the context supplies the actual IDs.

Then there are rate limits, which nobody ever thinks about while clicking around in the UI. A token-rich template can fire off 15 or more token update calls in a row, and the skill has to expect Marketo’s rate limit errors and pace itself accordingly.

2. Clone Email (Prepare Email)

This is the fast track from an email brief to a ready-to-review email program. Roughly, here’s the path it follows:

1. Read the instance context for the naming convention, destination folders, and the email template’s token schema.
2. Parse your brief into token values.
3. Generate and confirm the program name.
4. Clone into the right folder and set the tokens.
5. Summarize what’s done and what’s left, since the smart list, approval, and send are still yours.

Two things make this skill more than a glorified copy-paste.

The first is token formatting, the kind of quirk a human just absorbs over time but an AI needs spelled out. Classic example: your template might expect CTA URLs without the “https://” prefix because it tacks the prefix on itself. In the UI you’d spot the doubled “https://https://” the second you previewed it. Through the API, you’d never see it coming, unless the skill writes that rule down.

The second is edge cases, which is really where the work lives. When the destination year folder doesn’t exist yet, the skill finds it or creates it. When you reference a program by partial name, it runs a lookup, and if it’s still unsure, it asks. When the template only supports one CTA, it uses the primary one and flags the limitation. The happy path is easy. It’s the documented exceptions that make a skill reliable.

3. QA Program

After a program is created or changed by your AI or a person, this skill runs a structured QA pass. The clever part is that the checklist lives in your instance context, in the QA Instructions section, split into two categories:

• The first is what the API can verify, which the AI runs automatically: the program exists, sits in the right folder, matches your naming convention, uses the correct channel, carries the required tags, has tokens filled rather than left at defaults, has approved email assets, and has a smart list with rules and the expected smart campaigns.
• The second is what needs a human, which the AI flags but never pretends to handle: rendering across email clients, mobile responsiveness, personalization fallbacks, whether the smart list logic targets the right audience, send volume, timing and timezone fit, fatigue rules, legal compliance, and A/B setup.

That second list points to the most important idea in the whole skill. The API can tell you that a smart list has rules, but it cannot tell you the rules are right. The existence of rules is checkable, but rules being correct takes judgment. Part of the skill’s job is knowing where that boundary sits and saying so out loud, instead of handing you false confidence. This is what trustworthy AI operations look like: not “the AI checks everything,” but “the AI checks everything checkable and hands you the rest with a named list.”

Which Skills Should You Build?

A simple way to decide what skills to build is to look at the work you do many times a day or week that follows a repeatable process.

If you can write an SOP for a new team member, you can write a skill. Good candidates jump out quickly, like cloning programs, preparing email sends, QA passes, standard reporting pulls, and recurring list hygiene – as long as the MCP has the right endpoints available to accomplish the task, a skill can be made. The poor ones are one-off, judgment-heavy, or constantly changing work, so don’t force it!

In other words, the best way to spot a skill is to notice repetition. The third time you type the same multi-step instructions into a chat, that’s a skill telling you it wants to exist. And like your instance context, skills should be organized and maintained. Keep them in a shared, central place, version them, keep them current, and have them reference the instance context rather than duplicating it.

Start with the task that drains the most time, write that skill, and let the wins compound from there.

If you want something to get you started, we’ve made all 3 of the skills in this article available for free!