Everyone Is Prompting Better. Almost Nobody Is Packaging Work.

What do you do when you get underneath an agent's skin and understand how it works? It's not just an LLM. I talk a lot about these other components and it feels really abstract. I talk about prompts and skills and MCPs and connectors and hooks and scripts and all of this stuff. And if you're deep in the engineering world, these are shortorthhands. These are words that you understand that it's easy to make sense of. But for most people, it feels like a foggy middle layer between the model is smart and the work got done. And how do you set up your model to do that is one of the most common questions I get. Not because codeex in particular can connect to lots of apps, although that is certainly a useful thing. Claude does that too. Not because everybody suddenly needs to become a plug-in developer, although you can if you want. It's never been easier. And not even because the plug-in directory is the most exciting part of codeex. The real reason why you should care about this is because you need to understand how the secret sauce for an AI agent works. What is the scaffolding that you put an AI agent inside of? So, it actually works. It's like Darth Vader has a mech suit, right? And that's how Darth Vader works. Or Transformers have these huge metal suits and that's how they get the job done. This is how LLMs work. They have these suits around them that help them get work done. And codec plugins are a really handy way to understand that. And so the story is not that 5.5 GPT 5.5 suddenly got smarter, although it did. The story is not just that codeex happens to have extensions. The story is that agents are becoming capable enough to do very rich work and we are now at a point with simplicity and understanding of these tools that we can actually confidently not even as engineers build the scaffolding around the agent. ourselves, which means we can customize what they can do. We can customize the mech suit, right? A little prompt engineering here, a local script there, a little work on an MCP server, maybe. These are all real things that I know lots of people who are not engineers are able to do. So, in this video, I want to give you a product handle on this whole rich scaffold. I want to make the map clear for you. What's a prompt for? Why and when do you use it? By contrast, what's a skill for? What do you use a skill for? And when how does that contrast with a prompt? Right? It's often confused. What's a plug-in for? Why do we care about plugins? When do we use plugins and not skills? When do we use plugins and not prompts? What do MCP servers and connectors do? Why why should we care about those? To be honest, for most of us, we don't understand the relationship. We can't name that. And if we can't name those things, it's really hard to build strong, stable agentic systems. And so this is about how you customize your agentic system so that you understand what you want done and are confident your agent can do it and can actually get it done. The super practical do it now workbook version is going to go on Substack. So it has the workflow audit and the decision tree for prompt versus skill versus plug-in versus MCP. Uh, it'll have examples of what belongs in a skill.mmarkdown file, a starter plug-in structure, a testing checklist, and the trust questions you should ask before you install or build something so you feel safe doing it. OpenAI describes Chat GPT 5.5 is better at messy multi-art work like planning and using tools and checking its work and navigating ambiguity. Did you hear it? This is the part messy multi-art work. if you want to do the real frontier work. What I'm finding is most people get stuck not because they don't have the tool, but because they don't have the understanding of the harness to use it, there's not been a clean, clear instruction set that says this is what all these things are for. So that's why we're doing it now. So here's how we're going to tackle this video. We're going to go through in order prompts, skills, plugins that package up a workflow, right? And then after plugins, we're going to also tackle as a bonus MCPs and connectors. so you understand how agents access tools. And in addition, no, we're not done yet. We're also going to tackle hooks and scripts and how they work and how they relate to all the other things I just named. And then last but not least, we're going to talk about how marketplaces work because marketplaces are becoming the mechanism by which we distribute all of this. So, it's a busy video. Let's jump into it. First, prompts. A prompt is what you do when you want to do something once. That is where we're at in 2026. If the task is temporary, if it's small, if it's highly specific to the moment, you probably don't need any of the rest of the infrastructure. But a prompt is not a great home for anything that you repeat constantly or consistently. A prompt can describe a process, sure, but it doesn't really package up a workflow in a way that's repeatable. It doesn't really carry tools with it. A prompt is just a single piece of text you stick in, right? It doesn't carry permissions. And so a prompt is really useful when you have those one-off asks, but I find in general most people index really highly here. And they they don't realize that they're putting so much into the prompt that generates hours and hours and hours a week of wasted effort because too much is going into the prompt. Can you share your prompt with your team? Well, there are little tools for that. So a prompt doesn't carry most of what we need it to carry if it's going to be reusable. And that is where we start to think about skills, right? So a skill is where you teach a tool. It could be codecs. It could be claude a very reusable process. For example, your team might have a particular way of reviewing pull requests or a particular way of writing marketing documents. You want to be clear about what that is and how you do it. It is your house style and you want to make sure that whatever LLM you use always uses that across your whole team. That is what a skill is for. Now, a skill, amazingly enough, is just a clear markdown document that describes in good detail how you do that work. And yes, there's skills to write skills. I've made skills to write skills over on the Substack. It's absolutely something where you can get AI to help you. But my suggestion for you if you're trying to understand the prompt versus skill difference is to think of prompts like one-offs and to think of skills as anything that you want to reuse and reinvoke. And because skills are so universal, you don't have to worry really, oh, is this a codec skill? Oh, is this a Claude code skill? You just write the skill and then you use it with whatever tool you end up using it with and it's going to be great. You don't have to worry about it from there on out. So, the thing on skills, if you're looking for a concrete example of skill versus prompt, think of it as I would prompt if I had a oneoff note to a client that was complicated and I needed to put some custom backstory in. I would skill if I knew I was sending a bunch of cold outbound notes with particular content I wanted to pull in from a particular set of documents and I needed to be customized to that individual, but I needed a consistent skill for how to do that. I would write the skill that basically says this is what a good structured outbound email looks like. These are the paragraphs in it. These are the data we want to pull in. Uh and this is the beginning, middle, and end and how you write a strong close. Just a just a quick example. You can write skills for marketing, for customer service, for success. Literally anything that you think the LM can do more than once. All of those engineering tasks, those are skills, too. Skills are super flexible. And actually what I find once people get the idea of skills, the biggest issue is that people write so many skills it's hard to keep track of them. And yes, there are tricks for that too. I would encourage you to think about how you divide and conquer with your skills, right? Think about your skills as essentially having a power law relationship, which is a fancy way of saying that 20% of your skills are going to be worth 80% of the value. and you have to find the right 20% that are going to be repeated often constantly with high sensitivity to what goes right or what goes wrong and just jump in. So that's a little tidbit on skills. Uh and now let's jump right into to plugins which is the next thing. So if a skill is a way to do a thing consistently, a plug-in is a bigger package around that. So we've gone from prompts to skills, now we're at plugins. A plug-in can include skills, but it can also include app integrations, MCP servers, hooks, assets, commands, metadata. It basically takes a whole workflow and gives it a name and sort of wraps around it and makes it installable. And so if you want to add like an entire workflow in one go and it's much bigger than a skill, that is a plugin. And what's beautiful about it is that plugins are extremely sharable. A plugin is something that your team can use without everyone manually reconstructing the setup. In my outbound email example, let's say you had to have a live connector to data to pull from Salesforce to pull in the right name and the details about the client. Fantastic. That is something that would work in a plugin that would not work in a skill. So a skill says here is how to do the work. A plugin says here is the workflow package that you can install and all of it will just get magically done for you. And then everything that you need to get that whole workflow is completely accomplished in that one plugin. And so yeah, there's real work that gets done with plugins. It's real work to set them up, but once you set them up, they're incredibly powerful. And this is why real work rarely lives entirely in the prompt. It lives other places, right? It lives in the connectors that we pull in live. So it might pull in from Slack or from Figma, from GitHub, from other data sources. Real work can live in where we put our revisions to. So we review them. Real work can live in the technical skill that we apply as we go through the process of doing this work with an AI. The thing that we need to get to is we need to understand that basically everything I'm describing is like training wheels that help the LLM understand how to do the work that matters. And so the more we're clear about that, the easier it becomes to get the AI to do that real work. And plugins are a fantastic way to wrap up a bunch of individual components of work and say, "Hey, here's the whole thing in a nutshell. It's in a neat little package. All you have to do is copy it and get it into your app." And then you'll have the whole workflow there at your command whenever you're ready. And by the way, if you think a a I can't do this, or b it's too hard, I've got news for you. If you're any kind of serious AI user, you are already doing the plug-in work. You are literally the human plugin cuz you copy from one app. You paste into the chat, you ask the model to reason, you go and get data from somewhere else, you check the result, you come back. It goes on and on and on. You are the human plugin. If you don't want to be the human plugin, consider making an actual plugin. And no, you don't have to be an engineer to make an actual plugin. Not in 2026. You can absolutely do it without that. So, we've talked about at a high level what skills are. We've talked about what prompts are. We've talked about what plugins are. And you can think of these as three sort of different scales, right? Where plugins are the biggest. What are MCPs and app connectors? This is how an agent gets access to the systems where work actually lives. So when you remember when I said, "Oh, we'll plug into Salesforce for outbound." That's an MCP. That's an app connector. It plugs in. It figures out where to go to get live data and comes back with that real data. And most apps are better when they have real data. And so you can think of those tools as like internet plugs. So, they plug in and they get data back out, right? And I'm old enough to remember when we literally had to plug into the internet. It wasn't just Wi-Fi anymore. That is what you were doing with an MCP. It's like a universal plug to the data that you can put in and you can get it back out. And yes, you can absolutely build an MCP, but increasingly so many different SAS tools and places where work is happening are aggressively building their own MCPS and building data connectors so you don't have to. And one of the reasons I am doing a plug-in video is because I think that people misunderstand and they think, well, an MCP connector is just the same as a plugin, right? It's like there we're all plugging into something. No. And the reason why it's confusing is that a plugin can contain an MCP, but a plugin typically has more to it. It is not just an MCP server. there's a whole piece of workflow that you're tackling with that plugin which may include a call to live data and then have a bunch of other things that you're doing with the data along the way. So a plugin is more more of a larger package. So we've talked about prompts, we've talked about prompts versus skills, prompts and skills versus the whole package with the plugin, how the plugin is different from MCP and app connectors. Now let's talk about hooks and scripts. Those are big points of confusion. Hooks and scripts are for the parts of your workflow where you should not rely on the model remembering to be careful. So if the code needs formatting, run a formatter, right? If the schema needs validation, don't ask the model to think about it. Actually validate the schema. If the tests need to pass, run the test. Don't ask the model to imagine running the test. It has to actually go and run the script and run a test. If a generated file needs to meet a particular structural contract, like it has to be good JSON, actually check it and see if it's good JSON with a script. If a review should happen before the agent stops, build that review into the loop. This is one of the most important parts of doing good work with agents, but it's really misunderstood because people think that it's the same thing as an MCP connector. It's not. People think it should be left to the model's best judgment. It should not. Some things ought to be deterministic. By which I mean some things should not be left to the model. A good agent workflow is designed so that the parts that are deterministic are correctly framed as scripts or correctly framed as hooks into services that are deterministic. And if that feels really confusing, don't let it. Because hooks and scripts actually fit right inside our best friend, plugins. Think of a plugin as like a grabag present where you've got like 10 things in the box for your buddy and the plugin is the whole present around it. A plug-in can contain scripts and it can contain hooks into other services as a part of the overall workflow. It you're not limited to just having a prompt and an MCP connector or something inside a plugin. A plug-in package is big enough that it can hold the whole workflow to make it reusable. And that is why I think the app store analogy is too small. We think of plugins as, oh, they're apps in the App Store. No, they're not really. And it's not even as simple as saying, "Well, now Codex has extensions." It's not that that's wrong. It just really underells the power of what I am talking about. Because if you think of plugins as add-ons, you ask, "Well, what can I install, right? And I'm going to go passively shopping like I do on the app store." If you think of plugins as workflow packaging, you're going to ask a much sharper question because you're going to ask yourself, "What part of my work has enough repeatable structure that the agent should be able to inherit it and use it?" And maybe that's something that my whole team wants to use. That's the real question. Think of your work as repeatable structures and then think of how you build plugins to support it and you're going to be in much better shape than if you're messing around with these individual things. And that's one of the secrets in this video, right? Don't think of each of these things I'm describing and defining as like individual battle bots that are all in competition with each other to find out who's going to be the best and serve your AI. That's not how it works. Think of these as Lego bricks that taken together make something bigger and more useful in terms of your workflow. And by the way, in that analogy, a plugin is a bunch of Legos all built up together into a structure. A plug-in has lots of these components like scripts and hooks and connectors all inside it. And so you can ask yourself, do I want to have a plugin for architecture review? Do I want to have a plugin for how I handle marketing documents? Do I have a plug-in for how I handle customer service requests? Those are all large workflows. Some of them are bundles of workflows. And part of our job as humans as we start to think about the serious work these systems are capable of, is to ask ourselves, well, what's the right unit of work here? Do I want to make customer service in my tiny company one plugin? Or is it actually smarter to say, well, there's a refund uh plugin that we're going to need to invoke, and there's also a plugin for adding and activating customers who somehow aren't activated. We'll make that a separate plugin. And then there's a plugin for making sure that customers are able to upgrade when they want to, and we'll make that a separate plug-in. Totally just examples, but you get the idea. Your job is to understand the semantic meaning of the workflow and to say this is a good unit of work that has a neat edge and boundaries around it that we can make into a plug-in. That's a great example. By the way, here's another secret in this video. That's a great example of the kind of skill that is worth a lot of money these days because very few people know how to look at a workflow and say, "Here's how I draw edges around it. Here's the boundary around this workflow. And once I have the boundary around this workflow, this is how I would turn it into a plug-in that I can then repeatably share across the team. That's gold. That's an incredible skill to have. If you don't know how to explain that the work has value in a particular bounded space, you're going to always be tempted to make a workflow too big and too wide and subject to problems. Right? Because in the analogy I gave you on customer success, if all of that was one plugin, could it technically work? Yeah, maybe if you were a small company and you put a ton into the plugin. Is it a good idea to do it that way? No, probably not because a workflow has one job and what I described in my little example was three jobs and probably in reality there's like eight jobs. So, no, you probably need more than one plugin for customer success at this imaginary little company. And that's okay. Once you get into the habit of figuring out the plugin, and I've got lots in the Substack on that, you can make that stuff, right? You can you can stamp out plugins and actually go to work. If we zoom back out, the difference here is really significant because a generic model that doesn't have a plug-in, doesn't have scaffolding as I've been describing, can say something useful at a high level. And maybe if you prompt it and repeat your prompts and waste a lot of hours, it will be specific to you, but only because you prompt it all the time with lots of heavy prompts. But a truly scaffolded agent can review all of your work according to your standards, use the right tools, and do so effectively to get real work done, which is like a 10x bigger deal. And it's the same intelligence. It's it's not different LLMs on the inside. This is a great example of how we are a big part of the answer to making AI smarter. And I don't mean that in some dark way. They're all watching us. I mean in the sense that literally if you want smarter work done, you got to do the part to put the scaffolding in place. And you can. It is not that scary. And part of why I'm making this video now is that I really do believe because I have seen story after story after story of people who build these that it's not as hard as it used to be. In 2025, I couldn't make this video. In 2026, I can make this video because plugins are now something where I have literally seen people who do not have coding knowledge figure out how to build a plug-in to support their work. I saw someone do this for editorial work where she needed to have a plugin to help her take a first pass, an editorial review. And there's a specific workflow for that. Here's how you read the text. Here's the three different ways you read the text. Here's the comments that you want to think about adding and the places in the text that are rough. Did it do all of the work for her? No, it did not do all of the work for her because you still need a human to have that sort of editorial perspective. But did it save her a lot of time because it gave her a first pass with a review on where the text is rough, where the text was incoherent, where there are factual inconsistencies in some ways much better than a person. Yeah. And it was faster, too. And she could totally build that without having to go back and reprompt every time. And it was much bigger than a skill because it involved actually understanding more information sources than just one piece of text. And by the way, another great example for non-technical folks is around design. You can plug into Figma. You can plug into your design tool of choice and you can actually pull down a bunch of the details of how a current design looks, but also how the design language looks. And you can start to build a workflow that accounts for all of that and pops out new work. And if you're wondering, does this align to sort of how we're starting to think about things with cloud design in the mix? Absolutely. We are moving to a world where the hyperscalers are putting in place more and more tools, more and more plugins that help you do this work effectively. Arguably, Claude design, which dropped just a couple of weeks ago, is a fancy plugin with a UI for claude for design. It's like the plugin was so important they made it a product. That's how much plugins matter. And if you think that you can just sit around and wait and Claude or Chat GPT will eventually launch all of your dream plugins, I got I got a bridge to sell you. I got news for you. It ain't going to work that way. You have got to be in a place where you can take proactive action and say, "No, I want this plugin for this thing." It's not perfect. It's not right the way it is now. It's too much manual work. I waste too much time in custom prompting. My skills aren't enough. I want something that has a data connector. I want a script inside there that checks and validates and make sure it works. I'm going to have to have a a little skill as well. That's a plug-in, people. And you can totally do that. A weekly business report is a great example, right? Maybe you need spreadsheets and Slack context and docs and dashboards and past reports and charts. That's that's a plugin, right? I could I could give you a bunch more examples. That's the idea. And if you're wondering, I do have a ton more examples. They're all in the Substack. I have a customer brief, uh, how you handle that with email and CRM, etc. I have a hiring readout and how you handle that as a plugin. Tons and tons of these. And I think it's really important to have starters for this because if you see the start of a plugin, it's easier to customize than if you're just trying to go from a blank page and you've never done a plug-in before. So that's why I made the Hulk. Ultimately, and I get very passionate about this, agentic scaffolding must not stay vague. If scaffolding just means some engineering stuff around the agent to most of us, then only engineers can ever participate in designing it. That is an old 2022 era problem. But now we're in 2026 and if the workflow is real, the people who understand the work must be the ones who put that knowledge in. And I have talked to person after person after person who comes from a non-technical background who figured that out and they're now stamping out work because they know what good looks like. I talked to two of them this morning and they're working on like complicated retail scale workflows because they figured out what works for them. They know which sources matter. They know when the output is wrong. They know what steps are always forgotten. That domain knowledge that you have as a non-technical person, quote unquote non-technical, that's always blurry in 2026. That's what matters and that's what you can then leverage to create the custom plugins that work for you. And I think the issue is the way to encode all of this has become more unclear, not less in the last 6 months, right? Like do you write a better prompt? Well, now we have skills. Is it a skill now? Do I ask my engineers to make an MCP? Is it an MCP server? I don't know. And I have people ask me these questions all the time, right? Uh is it a connector? Do we need a connector? No, maybe it is a plugin after all. Disamiguate it. Understand what each thing does. A script helps you to do predictable, deterministic things every time. A skill helps an LLM to follow a process in a way that is clear and that you can share across teams and that's consistent. A prompt is good for one-off work. And yes, it still matters to write good prompting. It does. All the work you did in 2025 paid off if you worked on your prompting. And a plugin is like a bundle around a bunch of things, right? It includes the script. It includes the skill. It includes pieces of the prompt that matter and that are reusable. And yes, it also includes MCPS and connectors because those are connectors to live data. This is the mental model I wish people had because engineers know this stuff, but it's just not getting explained to the rest of us. And then when an engineer says something like, well, this should be a skill and this needs an API and you waited two weeks to have this meeting, right? No, this should be a prompt. I've had these conversations where engineers basically go through and this is the level of understanding they have in their heads. They never explain it to you and they lay all of this out. It should not be a mysterious middle layer. There should not be a mysterious middle layer between the LLM and the work that gets done for you. And that is what I want to make sure that you have. And that is why I've laid this video out the way I have so that you understand the mental model of how this works. And when you're ready to go deeper, the Substack is there and you can go deeper and actually look at all these practical use cases that I'm laying out. You can look at a guide that gives you a way to build plugins for what you want done and gives you starter plugins for a bunch of the workflows I've talked about and gives you a way to audit your workflow and develop a plug-in. So, all of that practical stuff is there, but everybody should know the mental model. And that's why I'm putting this here for all of us to see and watch and talk about because even CEOs need this. Now, I don't want a CEO saying, "Should it be a skill? Should it be an MCP?" If your CEO is confused about this harness stuff, show them this video, right? Because one of the things I get really passionate about is that seuite, especially anyone but the CTO, tends to be non-technical enough in most companies that they don't get this stuff. They don't understand that a script is a deterministic check and you shouldn't just trust the model to check itself. And then they get confused and they say, "Why aren't you using AI?" And you're like, "I am using AI. I just want a deterministic script at the end." I've had that conversation. It's a real conversation. You need to give your leadership enough context on this stuff that they can actually be useful in supporting the organ AI transformation. And that starts with understanding what is in the box when it comes to a harness so that people don't get confused. When we're talking about the difference between an LLM, even an agentic LLM in codeex or in clawed code and truly useful personalized workflows, we're talking about this, right? This difference between skills and plugins and and connectors and and how they matter. Please, please, please make sure that the people who need to see this see it in your world so you get the support you need because I have had to have enough conversations with senior leadership that I know for a fact most organizations there are very senior folks who don't have any clue about this like none zero clue they don't get it don't be like that share this with the people that that need to hear it make sure everybody has the same mental model uh if you do it once it's a prompt if you do it repeatedly it's a skill if the workflow needs to travel or other people need to install it. If it needs tools or assets or connectors, guess what? It's a plugin. If it needs access to another system, it's an MCP or app connector. And yes, that live data can come inside a plugin and nest inside. It's just like one brick in the larger Lego brick model. If the workflow has to be verified, you got to add a check. All of that together, if you understand that, will prevent you from wasting work because not everything needs to be a plugin. I hope you're getting that. I'm not saying everything needs to be a plugin. Some things should stay prompt. Some things ought to ought to stay skills, right? You don't need extra data. You don't need a bunch of other stuff. It just ought to stay skills. Some things should be normal scripts and never touch an LLM at all. Some things should stay human. As I hope you know, the the judgment to know what's good or not at the end of it, it's going to be human judgment. The goal is not to turn your workspace into a gigantic museum of plugins you never use. The goal is to simply understand the parts of your work that are repeated and valuable and structured enough to package and figure out the right solution so that you can do that. It's one of the most powerful ways you can do practical AI automation today. It's where the leverage is living in 2026 and that's why I get so passionate about it. I hope you've had fun following the story here of how we got to plugins from scripts and from skills and from prompts. I hope you have a clear mental model now and uh I will see you next time and as always there's more on the substack there so jump in if you want to build those today.