INBOX INSIGHTS: Skills Governance, Vibe Coding Part 3 (2026-08-19)

INBOX INSIGHTS: Skills Governance, Vibe Coding Part 3 (2026-08-19) :: View in browser

👉 Read our newest paper on what jobs AI can actually take!

INBOX INSIGHTS: AI Skills Governance, Vibe Coding Part 3 (2026-08-19)

Watch this video on YouTube

Skills Governance

I have two skills sitting in my Claude account with almost the same name. They do almost the same thing. One of them is the good one, and yet, I reliably pick the wrong one. I’ve known this for weeks. Every time it happens I think “I really need to delete that,” and then I close the window and go do something else.

I’m one person. I built both of them. And I still can’t keep them straight.

When I talk about governance for skills and plugins and agents, I’m not talking from a place of having solved it. I’m talking about it because I opened my own cabinet and it’s a mess in there.

Most people hear “governance” and picture a policy document, an approval workflow, and probably a committee. Then they decide to deal with it later. That’s not where this starts. It starts with knowing what you have, where it came from, and whether it still works, which isn’t compliance. That’s basic housekeeping and doesn’t need a special title or large budget.

The spice cabinet

You know the spice cabinet. Maybe it’s a physical cabinet, maybe it’s just counter space posing as a cabinet. When we redid our kitchen a few years ago, my husband immediately adopted the largest storage cabinet for his collection of spices.

I currently have three pouches of cinnamon because every time I need cinnamon, I cannot find it. So I assume I don’t have it, and I buy more. And then I inevitably find the other pouches as soon as I’m done with the one I just purchased. You’d think I’d remember this each time, but I’m human and easily distracted. There’s a jar with no label, and I keep meaning to open it and find out what it is. I think it’s an Italian blend, but I cannot be sure.

None of that is broken, exactly. The cabinet still opens and dinner still happens. It just costs us something every time we cook: time, flavor, maybe expired, bland spices.

That’s what a skills library looks like after a few months, and most organizations are further along than they think. Skill and plugin building didn’t arrive through a rollout with a project plan attached. They showed up because people built useful things on their own time, which is what you said you wanted, and now they’re everywhere and nobody has a list. Personally, this is a source of a lot of my anxiety at work.

Run it through the 5P Framework by Trust Insights™

This might (or might not) come as a surprise, but start with the 5P Framework by Trust Insights™. The 5Ps are Purpose, People, Process, Platform, Performance. We’ve watched clients very successfully use it to write the requirements for a single skill. I want you to bring it up a level to the management of the skills themselves.

Purpose. Before anything else, answer who this thing is for. Just me? Me and one other person? Everyone at the company? Something I want to publish free on GitHub, or sell in our academy? Yes, you are defining your “People” in your “Purpose.” This is an important step. Knowing who this is for is your first Purpose. That will set the stage for the other 4 Ps.

People. Purpose already told you who’s in the room. People is where you get honest about what those humans are actually like, because governance runs on behavior, not on job titles. Are these people who keep things updated, or people who mean to? Do they read notifications, or do they have four hundred unread and a whole philosophy about it? Is there somebody who’ll notice a skill has gone stale, and is noticing part of their job or just something they do when they happen to have a spare Thursday? You’re not looking for the right answer here. You’re looking for the honest one, because everything you write next has to survive the people you actually have.

Process. Now write down what happens today, step by step, including the embarrassing parts.

Here’s mine. Chris and I work at the same company and we’re in separate Claude accounts, so when I change a skill, I export the file, send it to him, then he has to import it and delete the old version. Then he has to confirm with me, probably in Slack, since we don’t have a different mechanism.

That’s a broken process. I can say that with confidence because I wrote it out and can point to the exact spot where it fails: it depends on me remembering to update the skill, send a message, and follow up that it was done. No software purchase fixes that step.

That’s the whole exercise. Write the sequence, find every step that depends on a human remembering something, and decide what you need to do instead and how big of a risk it is when something fails. A governance plan starts with that list of vulnerabilities.

Platform. Now, and only now, look at tools. I want you to start with what you already have, not what you can purchase.

Version control isn’t new technology. This is an old problem in a new context, and you’ve solved a version of it before, which is why you flinch at proposal_v2_final_FINAL_reallyfinal_pleasestop.docx. You already have Google Drive or SharePoint (or something similar), and both of them do version history. You already have a notification system people are more or less in the habit of reading. You already have automation inside your large language model that can do the reminding and the logging. A lot of the governance people assume they need to go buy, they’re already paying for and not using. If you outgrow it, there’s a real next step, and you’ll know what to ask for because you’ll have watched your shared folder fail in a specific way.

Performance. Two questions: are two people running the same skill getting the same answer, and is the skill still working from current information? That second one is where this gets uncomfortable, because there are two kinds of failure and only one of them is polite enough to announce itself.

Loud failures are the good kind. Something breaks, you see it break, somebody fixes it. You can even instruct your AI to “fail loudly” and refuse to guess when it’s missing something, and you should.

That only catches what the machine can detect. Whatever information you hand a model, the model treats as correct. So a skill pointed at an ideal customer profile you retired last year doesn’t throw an error. It runs beautifully, on the wrong thing, and your content sounds faintly dated for four months while everybody blames the writer (usually behind their back).

Expired spices don’t taste wrong. But they aren’t as strong as if they were fresh, so the dish you’re making comes out “meh,” and you blame the recipe and likely never make it again.

Two things make that more expensive right now than it used to be. First, agents run on their own, so a bad reference file doesn’t produce one wrong answer, it produces two hundred before anybody reads one closely. Second, the newest models are being built as doers rather than as libraries, carrying less knowledge of their own and leaning harder on whatever you hand them. Claude will tell you it has “the ground truth” now, and what it means is whatever you put in the folder.

This means your performance measure can’t be whether the skill ran. Somebody who actually knows the subject has to read the reference files and read the output, on a schedule, with a date next to it. That’s the human-in-the-loop part, and it’s more critical than ever.

What to do next

Document the process the skill replaced. Every skill stands in for something a person used to do by hand, so keep that standard operating procedure current even after you’ve automated it. Software breaks and vendors change their minds, and the documentation is what makes the rebuild survivable.

Make the list. A spreadsheet is fine: name of the skill, what it does, who built it, when it was created, when it was last updated, who’s using it, what it depends on. Have your large language model build the sheet, then fill it in as you go. This is a good use of automation.

Centralize the location where the skills live. This should be outside the LLM. Choose a place where everyone generally looks for the most up-to-date information. The location matters far less than everyone agreeing on it.

Delete the duplicates. I’m saying that I’m doing mine today, but if I’m being honest, I’ll probably forget again. Feel free to ask me if I’ve done it yet.

The moral of the story

This kind of governance isn’t a compliance exercise, and it isn’t something you graduate into once you’re big enough. It’s the difference between a spice cabinet you can blindly reach into and a bunch of loose spices taking up counter space. Start with a list and one shared location, and add structure only when you can’t find the right thing. You’ll know it’s working when you stop reaching for the wrong jar (or skill).

How are you structuring the governance of your skills?

Reply to this email or join the conversation in our Free Slack community, Analytics for Marketers!

– Katie Robbert, CEO

Weekly One Question Poll 🐶

Click or tap just one answer below — there’s no form, this is the entire thing. One tap and you’re done, with our thanks.

Do you know if AI search is sending you business?

Do you have a colleague or friend who needs this newsletter? Send them this link to help them get their own copy:

https://www.trustinsights.ai/newsletter

In this episode of In-Ear Insights, the Trust Insights podcast, Katie and Chris discuss the hidden friction of sharing AI tools across different platforms. You’ll discover how to organize your AI tools for smooth operation across different platforms. You’ll learn why unchecked plugins cause errors that damage your daily results. You’ll uncover a clear tracking method that aligns your team without added stress. You’ll build a reliable backup system that shields your projects from sudden platform shifts.

Watch/listen to this episode of In-Ear Insights here »

Last time on So What? The Marketing Analytics and Insights Livestream, we looked at automating content transformation with AI. Catch the episode replay here!

This week on So What? we’re digging into how to set up a Claude Marketplace. Are you following our YouTube channel? If not, click/tap here to follow us!

Here’s some of our content from recent days that you might have missed. If you read something and enjoy it, please share it with a friend or colleague!

Take your skills to the next level with our premium courses.

Get skilled up with an assortment of our free, on-demand classes.

You could be reaching 37,000+ marketers, analysts, data scientists, and executives directly with your ad. Want to learn more? Reach out and contact us.

In this week’s Data Diaries, the third of a five part series on “vibe coding” basics for non-coders. Katie and I have talked extensively about vibe coding in the past on the podcast, but we’ve never really dug into the basics of it. So in this series, completely unsurprisingly modeled on the 5P Framework by Trust Insights™, I’ll cover those basics.

The Process of Vibe Coding

This is the meat and potatoes of vibe coding, or AI-assisted coding. How do we get AI to spit out something useful that doesn’t take a million band-aids to fix and become a massive tangle of duct tape and baling wire?

The answer is scaffolding, where we build from big to small, from top down. We do this in three steps, the why, the what, and the how, and three accompanying documents that AI is superbly tuned to help us build.

The first is the why, and this document is called a Product Requirements Document, or PRD. PRDs generally contain a few items – user stories, which we covered last week, along with functional requirements (what’s it supposed to do), non-functional requirements (what the system’s values and priorities are), domain requirements (business rules), technical requirements, timelines, milestones, and KPIs. From our user stories and our purpose, AI can usually infer these especially well. Let’s take our Google Search Console example. We might prompt AI with something like this:

You’re a software project manager. Based on the following user story, help me build a product requirements document (PRD) for a piece of Python software to connect to Google Search Console’s API and extract both query and page level data. Remember that PRDs typically contain functional requirements (what’s it supposed to do), non-functional requirements (what the system’s values and priorities are), domain requirements (business rules), technical requirements, timelines, milestones, and KPIs. You are authorized to use web search tools to obtain the latest technical information. Ask me up to 20 clarifying questions so that you have enough information to succeed at the task. Build the PRD in Markdown format. Here is the user story: As a [marketing analyst] I need to [obtain query AND page level metrics from Google Search Console’s API] so that [I can help my SEO team understand what pages are getting the most traffic from specific search queries].

Once you’ve inspected the PRD to ensure that it actually meets your expectations, then you can move onto the technical specification, the what.

You’re a software engineer. Based on the included PRD {remember to attach it}, let’s develop a technical specification for this software. PRDs explain in great detail the “why” of an application, while the tech spec explains the “what”. You are authorized to use web search tools to obtain the latest technical information. Ask me up to 20 clarifying questions so that you have enough information to succeed at the task. Build the tech specification in Markdown format.

After you’ve built the PRD and the spec, it’s now time to build the workplan. A workplan is the how, the step by step process the AI should take to actually write the code. Once the workplan is done, only then are you ready to tell the AI, “okay, go and implement the workplan.”

Here’s why: every time AI writes something, it’s thinking aloud. The more times you give it to repeat the same idea over and over again, the more bugs it finds – and a cardinal rule of good development is that a mistake on paper (in planning) is ALWAYS cheaper than a mistake in production.

You’re a software engineer. Based on the included PRD and spec {remember to attach them}, let’s build a workplan for the implementation of our software. PRDs tell us the why, specs tell us the what, and workplans tell us the how. The workplan should adhere to these coding standards {attach them} and follow test drive development methodology. Identify dependencies between tasks and structure it to build from fewest to most dependencies. The plan must include 100% test coverage, and 100% passing tests, both unit and end to end – nothing less than 100% passing tests is ever acceptable. Ask me up to 20 clarifying questions so that you have enough information to succeed at the task, then build the workplan as a Markdown document.

Let your AI tool of choice generate the workplan, then inspect it. If it’s sane, you can tell AI to begin implementation.

Next week, we talk about WHICH platforms are better or worse suited to vibe coding. Stay tuned!

Almost every AI course is the same, conceptually. They show you how to prompt, how to set things up – the cooking equivalents of how to use a blender or how to cook a dish. These are foundation skills, and while they’re good and important, you know what’s missing from all of them? How to run a restaurant successfully. That’s the big miss. We’re so focused on the how that we completely lose sight of the why and the what.

This is why our capstone course, the AI-Ready Strategist, is different. It’s not a collection of prompting techniques or a set of recipes; it’s about why we do things with AI. AI strategy has nothing to do with prompting or the shiny object of the day — it has everything to do with extracting value from AI and avoiding preventable disasters. This course is for everyone in a decision-making capacity because it answers the questions almost every AI hype artist ignores: Why are you even considering AI in the first place? What will you do with it? If your AI strategy is the equivalent of obsessing over blenders while your steakhouse goes out of business, this is the course to get you back on course.

👉 Take this course now to become an AI leader

Here’s a roundup of who’s hiring, based on positions shared in the Analytics for Marketers Slack group and other communities.

Are you a member of our free Slack group, Analytics for Marketers? Join 4000+ like-minded marketers who care about data and measuring their success. Membership is free – join today. Members also receive sneak peeks of upcoming data, credible third-party studies we find and like, and much more. Join today!

Where can you find Trust Insights face-to-face?

LPA, September 2026
MAICON, October 2026
SMPS AEC.AI, November 2026
MarketingProfs B2B Forum, November 2026

Going to a conference we should know about? Reach out!

Want some private training at your company? Ask us!

First and most obvious – if you want to talk to us about something specific, especially something we can help with, hit up our contact form.

Where do you spend your time online? Chances are, we’re there too, and would enjoy sharing with you. Here’s where we are – see you there?

Read our disclosures statement for more details, but we’re also compensated by our partners if you buy something through us.

Imagine a world where your marketing strategies are supercharged by the most cutting-edge technology available – Generative AI. Generative AI has the potential to save you incredible amounts of time and money, and you have the opportunity to be at the forefront. Get up to speed on using generative AI in your business in a thoughtful way with our workshop offering, Generative AI for Marketers.

Workshops: Offer the Generative AI for Marketers half and full day workshops at your company. These hands-on sessions are packed with exercises, resources and practical tips that you can implement immediately.

👉 Click/tap here to book a workshop

Some events and partners have purchased sponsorships in this newsletter and as a result, Trust Insights receives financial compensation for promoting them. Read our full disclosures statement on our website .

Thanks for subscribing and supporting us. Let us know if you want to see something different or have any feedback for us!

Need help with your marketing AI and analytics?

Leave a Reply Cancel reply

Pin It on Pinterest

Watch This Newsletter