▲ Community Session: Vercel plugin for Claude Code
Chapters9
Host introduces the session format, how to participate, and the guest who will demo the Verscell plugin.
John Linquist unveils the Vercel plugin for Claude Code, showing how session hooks, pre/post tool steps, and a live knowledge graph keep agents up-to-date with the latest Vercel tech.
Summary
John Linquist walks through the first draft of the Vercel plugin for Claude Code, explaining why plugins matter even as skills grow. He frames plugins as the next evolution beyond simple skills, with hooks that define a session lifecycle from start to end. The demo emphasizes how session start injects a Versell knowledge graph (a “table of contents”) to orient the agent to the latest Vercel ecosystem docs, AI SDKs, and workflows. Linquist also highlights pre-tool and post-tool hooks that let you inspect and diff file changes or tool outputs, preventing outdated or risky edits before they land. He discusses handling versioned libraries (Haiku vs Opus) and how the plugin can point to current docs rather than rely on a model’s cached knowledge. The live comparison between a vanilla Cloud Code session and one with the Versell plugin demonstrates how the plugin injects updated guidance, catching outdated references like generate object and replacing them with current equivalents. Throughout, Linquist emphasizes a philosophy of agentic-driven development: talk about concepts, not code, and let the plugin handle the heavy lifting of keeping agents aligned with Versell updates. He also touches on cross-tool compatibility, the idea of scope-sensitive (one-shot) skills, and the practical realities of testing and telemetry. The session ends with an invitation to contribute via the repo and a reminder that this is a work in progress, iterating toward a smoother, more magical developer experience.
Key Takeaways
- The Verscell plugin injects a knowledge graph at session start to orient Claude Code to the latest Versell ecosystem items (AI SDK, gateway, workflows).
- Hooks define a session lifecycle: session start, pre-tool, user prompt submit, post-tool, and session end, enabling structured control over what the agent can load or modify.
- Pre-tool and post-tool hooks allow inspecting and diffing files or tool outputs before/after commands run, preventing unwanted or outdated changes.
- The plugin aims to keep agents up-to-date with the latest Versell docs and SDK changes by referencing current docs rather than relying on model knowledge cutoffs.
- Version pinning and local project inspection help the agent choose the correct docs/skills based on installed libraries (e.g., AI SDK v6) and project context.
- The end goal is an ergonomic, task-focused plugin experience that minimizes the need for developers to manually manage model knowledge or API changes.
- Plugin architecture is designed for cross-tool compatibility, with ongoing standardization to support Cloud Code, Cursor, Code ex, and more.
Who Is This For?
Developers and teams building AI-assisted workflows who want their agents to stay current with the latest Versell platform updates without manual retooling. This is essential for anyone migrating to Claude Code or shipping agents on Versell for real-world projects.
Notable Quotes
""the goal of the Verscell plugin is to stop the agent from uh writing kind of outdated code, outdated practices, and bring it up to here's everything that's the absolute latest on the Versell platform.""
—Core motivation: keep agents current with Versell tech.
""The concept of a table of contents. It's like the beginning of a book when you start a conversation.""
—Metaphor for the knowledge graph injected at session start.
""Pre-tool is your friend. It is your best defense against things you don't want to happen.""
—Highlighting the protective role of pre-tool hooks.
""you shouldn't have to worry about version numbers.""
—Idea that the plugin abstracts away environment/version concerns.
""Haiku 4.5 versus Opus 4.6""
—Demonstrating model/version differences and the plugin’s role in steering to current docs.
Questions This Video Answers
- How does the Claude Code Vercel plugin keep models up to date with latest Versell docs and SDKs?
- What are session hooks in a Cloud Code plugin and how do pre-tool and post-tool work?
- Can I use the Vercel plugin with editors beyond Cloud Code like Cursor or Code ex?
- What is Haiku vs Opus in this context and why does version matter for plugins?
- How do I contribute bugs or feature requests to the Vercel Claude Code plugin?
VercelClaude CodeCloud Code pluginPlugins vs. skillsSession lifecycleHooks (session start, pre-tool, post-tool, user prompt submit, session end)Pre-tool and post-toolKnowledge graphHaiku vs OpusAI SDK workflows
Full Transcript
Hello everyone. Welcome to this week's Burcell community live stream. I'm Amy and this is Jacob. We are on the community team here at Burell. Uh just a reminder, we are streaming this on X and YouTube, but if you want to make sure that we see your questions and comments in the chat, go to the community and sign in. It's at community.forsell.com/live and you'll see that as the first event. At the end of the session, we'll have little time for some uh questions. So, if you're going to if you're going to participate in the chat uh while you're watching the session, just remember to follow our code of conduct and uh yeah, you can drop in any questions you have along the way and we'll make sure to ask.
I'd like to introduce our guest. We have uh John Linquist here uh to show us the new versel plugin for Cloud Code. Hey, John. Hey, Jacob. Hey, Amy. Thanks for having me. All right, let's just go ahead and start sharing my screen right away so we can show what's going on here. So, for a while now, skills have been all the rage and everyone's talking about which skills to use to uh to level up your projects and to uh enable your agents to do things they normally aren't able to do. Um, now emerging from skills, the kind of next evolution of that is what we call plugins.
And this is something that's still um really catching on. There's not a lot of plugins out there and people are still exploring exactly how to build them. Um, I built the first draft of the Verscell plugin. And what I'd like to talk about is why build a plugin, when should you build a plugin, um, why a plugin instead of skills and how they complement each other and all all those sorts of questions. So if you have any questions around um what is that I'll I'll be talking about it but what what a plugin can enable for you if you should build one internally or personally um I would love to discuss that and and we'll talk about that during the session today.
So first of all, a plug-in is um initially kicked off by uh cloud code and and Gemini as well, but took very different approaches and the standardization of plugins is an ongoing effort and that's something that we hope to have can talk about more soon where a single plugin can work across all the editors. So right now we are talking about cloud code and cursor supports as well. Codeex is coming very very soon. um if not already today and uh many of the others as well. Um there is a plug-in standard being worked on. So um we can expect plugins to be something that you can package up and share across whatever tooling you're you're using.
So that being said um you may be familiar with skills as they are markdown files which can be loaded by your agent to give it like additional instructions. Um if one you manually invoke it like you do a slash and invoke your skill or the agent detects based on the description that the skill should load in. So it's very user invoke or agent decides based on like a condition in the description. Now the the level up of a plugin is they have something called hooks. And if you think of a plugin or you think of a session you have with claude code or with any of the agent harnesses um you can think they have life cycles.
So right now I'm in the uh versel plugin directory. If I spin up a disclaime code here, I'm going to ask it are uh what are the hooks that this uses? And this is going to list out uh the the hooks kind of like define a life cycle. And a life cycle is the whence when your session starts um when tools like before tools get called after they get called when a user pushes text into it and when your session ends. There are a whole bunch of other hooks in there but um for our purposes in the Versell plugin these are the ones we are currently using based on our like initial goals.
So to be clear, the the initial goal of the Verscell plugin was to help people ship agents on Verscell. So the idea is how are we going to make agents aware of the Verscell ecosystem like everything on the platform that has to do with uh the AI SDK, the AI gateway um and uh our workflows are are almost J here. So anything around workflows and essentially the Verscell CLI has updated a lot and all of these things around the a the agent SDK or sorry the around shipping agents on Versel they're all things that have been released within the past days past weeks past months and any of these uh agent harnesses like clawed code they have these knowledge cut offs from probably like 6 months to a year ago.
know some it depends on the model, depends on a whole bunch of variables, but they're all things that uh all of these agents don't know about all of the latest like amazing stuff that we shipped. So, the goal of the Verscell plugin is to stop the agent from uh writing kind of outdated code, outdated practices, and bring it up to here's everything that's the absolute latest on the Versell platform. So that's like the huge win there is models are smart but they just don't know about all this stuff and instead of asking them to do research every single time or asking ask asking having a huge bundle of skills for every single thing like if we can find some way of essentially forcing an agent to load in the best stuff about the Burcell platform then that's a huge win for us.
So if you look at these hooks and the life cycle of an agent um and again there are many many more hooks that we can leverage um in the future or that you could leverage but the key ones for now are session start and we use that a few different ways u pre-tool use user prompt submit post tool used and session end. So session start and session end are you know the beginning and end of a uh conversation with an agent. And you can think of your uh agents MD your claude MD file is typically the thing you do at session start.
So what can we do at session start for the versel platform and what we could do is load in a versell platform file. meaning that uh if we look at I'll just say describe uh versel MD. Um so this file is something that we can um include in session start alongside a claude MD. Essentially you could have a plugin that is if all you wanted to do is have like share a cla MD file and have someone have an easy way to install it. Um, you could build a plugin that all it does is just like inject a this is a knowledge graph of versel and this is something that we're continuously tweaking.
Um, we're looking for ways to compress it and make it as small as possible but still have good performance and a a balance of uh what should be in there and what shouldn't be in there. It's very difficult to run eval against all the different models and all the different harnesses. Um, but we're we're slowly figuring those things out. So what's in there is essentially relationships in the versell ecosystem around AI when to use uh when to use which products when to call which things um and yeah like a structured understanding of the entire versell ecosystem.
So the the concept of a uh I like how it calls this a table of contents. It's like the beginning of a book when you start a conversation. Um, and the way that we structured this and thought about this is if you think of how do I talk to an agent about things, I have a certain vocabulary, they have a certain vocabulary, and if you can if you can give it a glossery of terms, map those to docs, map those to skills, map those to things that it should load in. Once you hit those things, you can think that what are the things I'm going to say and what are the things that um that the agent should load in and call and try and develop that like mind map up front so that I can just talk naturally to it and not have to worry about talking about like even mentioning uh the AISDK at all and even mentioning any of the features at all.
Uh, and if I can just find some way of saying just build me this app and ship it. Um, and then it just handles everything in the plugin, excuse me, uh, handles everything in the plugin so that it gets a a beautiful app gets shipped on Verscell and then you can iterate from there. Um, similar to like how Vzero and um, some other projects work for us. If we can just make it so that you can have a wonderful experience, but you don't have to think about the ecosystem, then that's a huge win. Um, does that make sense, Jacob and Amy?
Any any initial questions about that or anything in the the chat? Well, Jacob, I think you have a question, but you're muted. Sorry. So, sorry. I had a question for you, John. Yeah. Um, since this plug-in operates as a table of contents, is that why it doesn't need to um why the plug-in doesn't need to constantly update every time a new new documentation comes out because it's basically a collection of URLs that the agents can then follow to find up-to-date the docs or do does the plug-in have a like a immediate update system? Um, how how does that approach work?
Yeah. So, so essentially if you think of the uh the the knowledge graph up front, um a lot of what it can do is just point to the latest docs. So if you if you think of um this is a question that comes up a lot with uh the skills and how we manage skills per libraries. Um, and if you have someone on the version five of whatever SDK and someone else on the version six of the SDK and you try and influence them with skills from different versions that are uh conflicting like how do you do that?
And a lot of it is um like based on what somebody has installed. Uh you can check their package JSON file, you can check the version and based on that come up with a smart way to look at um which doxy rails it should look at and uh which skills it should load and all those sorts of things. And so that that's another part of the um kind of the preload phase that the session start is just like inspecting the person's project. Uh and again this is all local. Uh it just it just looks at the project sees what are the libraries you're using, what are the setups you're using so that it knows to point you in the right direction.
Um one of the most common errors is like trying to use you know generate object on the latest version of AI SDK when you know that API changed. Um, so, so yeah, there's really no the the plugin should just handle that. Like you shouldn't have to worry about um if you're using this on a legacy project or if you're using on the apps, it's a green field latest project, the plug-in should be able to handle that. You shouldn't have to worry about version numbers. You shouldn't have to worry about package names. You shouldn't have to worry about anything because um just let uh just let Verscell do that for you, right?
And we're we're continuously working on way we have lots more ideas of how to do this better and um the plug-in will continue to update and and push this forward. So any other questions? Um yeah, so what what's the total I'd say scope of the plug-in? Does this handle say just Versell services? Um anything I might find in the dashboard or is it also like the the open source libraries that we support like Nex.js s AI SDK workflows and so on. Yeah. So the initial scope um what what we decided initially is to uh cover as much as possible and uh like have every uh library, everything in the platform like just everything in there.
See what gets used the most. Like internally we have everyone turn their telemetry on and you can like opt in to share telemetry and um we'll find which skills are actually being used and which ones aren't. So that way we can um remove some things in there that uh we might not need as much information on or add more based on um what seems to be used the most. Obviously NexJS AI SDK and you know the most popular downloaded things should have the most information. Um, and so that's a it's a balance um upfront where we intentionally uh went pretty big with the initial release and we will pair it down to something much more uh spelt I guess uh going forward.
So yeah. Yeah, that makes a lot of sense. Thank you. Yeah. All right. So, so yeah, if if you're building a plug-in, um, and and one of the reasons I I talk about this in kind of like loose general terms is because I'm very much into like agentic driven development. And rather than show you exactly uh how everything works, I think it's much more important to like learn how to talk about it and uh take some of the terminology away from it. So, you can just ask your uh AI assistant to do this similar stuff.
Um if you tell it if you tell cloud code to build a plug-in for cloud code and you give it you give it the docs like it can do that. Um so it's much more important to discuss the concepts and ideas around this than like dig into the code too much. Um with with that being said, so session start is a great place for uh injecting a like a table of contents, a platform like this is all the things that are out ofd based on like the things that are important to me that are out ofd uh based on the models or for most models.
Uh, so that is what brings everything up to like here's what Versell looks like today. And so that even if that's the only thing that happens in the plug-in, it's it knows that um it should go and check on things going forward. But what we're also able to do um and just just kind of a side note a reason you do uh like each session in cloud code uh has its own unique ID which allows you to uh like as this goes through the session it makes sure it has like a a skills budget and it has the skills that have already been loaded and things of that nature.
So we can put we can write things to uh like the the sessions environment or to like a session uh storage place where throughout that session as you're going through that session we make sure we don't load things that have already been loaded or um like duplicate any efforts because we can keep track of things that have already happened. So that's another great thing great part about the session is gives you gives you a chance to grab a session ID so that throughout through any of the future hooks anything that anything that gets run inside of the session you have an ID to like latch on to and uh store things about the session for your individual plugin um cloud code also does that if you look in their uhcloud directory with their projects you can see sessions and uh things in there so you you take that same concept for your own plugins and own tooling Um, all right.
So, with that all being said, uh, what pre-tool use, and we'll talk about pre-tool and post tool at the same time. What these give you a a they give you a chance to see file changes. So, in pre-tool, you can get the content of the file like that's about to change. Um and so this is around like uh reading files, writing files um or sorry reading files, editing files, creating files uh and pre-tool also covers a lot of other uh any of the other tools that we used uh such as like running things in bash.
So you get this chance of like before this thing happens um is there anything I want to do? And so say for example if we see someone running trying to do a specific Verscell CLI command um and we notice that there's a better way to do it now in the Verscell CLI such as like Versel CLI now has an API option where we can do much more advanced queries. Um and the Versel CLI has been updated if you haven't updated it recently. It has a lot of great new features. um we can hint at those things and say you're trying to do this or even check like is your Versell CLI out of date?
Uh it would be great to update it. So you have a lot more options here. So it gives you a chance to like check to see if it's going to make some sort of uh tool call whether it's a CLI call. Uh this is super important for uh the sandbox CLI, for the workflow CLI, for all these brand new CLIs that um the models don't know anything about yet because they've just released after the knowledge cut offs. Um to make sure that they're doing things correctly. Um so that's for for tool calls like bash calls.
Uh it's for file edits. It gets really interesting with file edits. Something we're exploring more is um diffing files like this file used to look like this. The agent's trying to make it look like this. Is that the correct uh ba based on our libraries? Is that correct change or is there something that smells in there? Um and that gets into I'll I'll just lean back on the example of say you have the uh V6 AI SDK installed and it tries to use generate object as an API which is a common one. And if you see that in at that moment like I see you're trying to use generate object, let's stop and remind them of what the AI SDK is actually like so that before you even get to testing or deploying or anything like you've caught it at the exact moment that um that the agent was trying to change the file.
And this is uh this is one of those things where if you try to rely on a skill where skills are like textual hints of if you ever try to write um into your cloud MD or into a skill like never uh never commit whatever files or uh never push without uh uh never push unless uh I'm in a branch or something. uh you've probably experienced that like those don't always uh protect you protect you from those pre-tool use gives you a chance to like literally like it can stop those things from happening in a programmatic and like engineered sort of way and you can give it different instructions and different examples of ways it can do it.
So that's the the the huge difference here between skills between uh your your cloud MD agents MD's files is that you actually can control what's changing and if or what's what's happening and if you want it to happen or what's changing and if you want that to change um that's that's the point where it gives you um it's great. Um so from there uh you get similar capabilities on post tool. It's another chance to check uh what exactly had changed after like a bash file had bash command had run. What are things that are different now that a tool has been called.
Um so the this is it doesn't allow you to prevent something from happening but allows you to see the result of something that's happened. And if that if uh if if it changed something or did something unexpected, it's it's another chance to get a diff and say this looks kind of weird. let's uh tell the agent that this smells weird to us. Um so those are like two huge life cycle hooks to know about when building. And for us it's again it's a lot of that like it's all about that uh that knowledge cut off.
That's the thing that Verscell has to uh kind of fight against because we ship fast, we ship often and we're just like pushing uh all this new technology so quickly and it's just this amazing stuff we want to surface to people. Um, and that's where like a plug-in can really um really come in handy. Um, any questions about that? Yeah. So if it's using like file paths um to decide which skills to inject, does that mean we we actually stand uh to gain a lot from scoping the files in our projects down to be a little more single purpose so it can more accurately determine uh which which skills it needs to uh which skills it needs to add?
For example, if I have a big file and maybe it's using five or six of our libraries and now it can only add three uh up to three skills there or it might not know based on the based on the file path. Um should do you think that should be a consideration when building software with these tools? I would say you shouldn't have to care about the code that the agent writes. Um, and that it is up to the the plug-in authors. It's up to the harness authors to to make those things work well like the people who are actually running evals and seeing if um seeing if that makes a difference or not.
Whereas I I think it's very it's very easy to get back into engineer mode and think I'm going to solve this because this is what a human would do and um it's definitely what an agent would want. Um like that's one of the greatest temptations of developers right now is problem solving like finding problems that aren't problems. Um because yeah, it's if if you're if you're trying to fix something and you don't know how to test it, like if you know how to test that against against an agent, then go for it. Um if you have no desire to do that, then um then just let the the people who are building the the plugins and the harnesses take care of it because the the testing and eval takes it cost a lot of money to run all these models against those changes.
it takes a long time and um it's a huge pain. So like it's it's one of those things I hope nobody has to care about that. Um and I would spend uh I think I just spend my effort on other things for now. Yeah. I see. I see. So, no point changing the way I build things if the next version of the model is going to be built in a way that would make all those alterations unnecessary essentially. And and I think I mean the end goal for um all the harnesses and for VEL is that um that you really don't have to think or look at the code that much.
I'm not saying that that's the case right now. I'm saying that that's like that that's the end goal. That's that's what we're pushing towards is that you want to ship beautiful software. You want to be able to think, you want to uh kind of free flow ideas and uh get variations and see which ones really resonate with you and then like really pair it down to something that is uh beautiful for you or your family or for your customers. Um, like that's just you just want a a beautiful experience where you're not you're not thinking too much about how big your files are, if you're writing, you know, the right design patterns, um, which libraries you're choosing and it's I I I totally agree like that the temptation to say like let's let's use all these patterns because agents are better with them.
Let's do all these things. And um it's definitely something we're we're experimenting experimenting with the plugin and testing. Um but again, if you can't test it, then I it's it's it's so tempting to say, I made this change and it's obviously working better now. And that that's one of those like um foot guns where well now that you've made this change you're not looking at how it used to work and what what that impacts in other places and yeah maybe it worked well for that one session and like so engineering is different now. Sorry this I'm getting philosophical I guess.
Yeah. Yeah. Yeah. I think I think we understand. Yeah. All right. Um, so another hook is uh user prompt submit. Uh, this is a a really important one because it allows you to take the text of what the user typed and if they mention a library, if they mention a concept, if they mention, you know, if they mention the word schedule, let's let's bring in the cron skill. if they This is very much similar to how like skills work like if the user or um if there's something in conversation detected that matches the description, but this actually gives you a chance to like run a reax against a user prompt and um if you detect certain keywords or or patterns or whatever, load those skills, do these things, hint back to the agent like maybe you should ask more follow-up questions.
Um, this this is the interactive part of it where it's it's your chance to say this the user said this, maybe we should get more clarification or we should just load all these things and and push it forward. Um, you get to do uh there's some really fun things you can do with user prompt submit where if you want to have your own custom like glossery or language of uh commands for yourself and you want to like prefix things with dollar signs and if something starts with a dollar sign then do this. or if something has, you know, uh it's it's kind of like writing like little bash scripts or something inside of user prompts submit that, um if you detect this, then you can run a tool right away and it doesn't like it can run it inside of the um you can run whatever bash scripts, node scripts, whatever inside of that hook um that's outside of the context of the session.
So you can do all sorts of um just wild quick things in there if you want to like detect the word uh commit and then uh avoid having the agent uh take a few steps to commit something and instead you just have a script that commits based on whatever. It can do that like right after the prompt submit. You can tell the agent I, you know, I ran my I I ran this commit thing. You don't have to worry about it. Um, and you can save the agent a few turns. And there's like some really interesting little tricks you can do in there to um really accelerate if there's a lot of things that you do that are repetitive um rather than asking the agent to do it every single time.
That's it's kind of a fun project if you want to like build a little user problem submit for yourself and come up with your own like language of how you want to talk with the agent. Um but for us it's more like if they said this this talked about this concept what does that mean in versell terminology. So it's like matching words against um like specifically the like scheduling is crowns and workflows and um you know words like parallel or performance or whatever like you can find and direct the agent to specific things that that you know about.
Um very very fun to play around with user prompt if if you have a a weekend to to mess around with that. And again, I'll just I'll just reiterate. It is totally possible to come in here and say, "Help me build a cloud code plugin with user prompt submit that will detect, you know, dollar signs." And if it shows dollar sign, then run commit inside of the uh user prompt submit. So that I like with that prompt, you know, I could have built out this. So don't worry too much about the code. You can just start playing around with it.
Um all right. So now that you have all this uh buttoned up, uh session end is a chance to clean up any files or anything that you wrote during the session. So if you uh started collecting which skills have been run, if you started collecting uh any information about uh results from tools that were called or any sort of like budget or thing you're tracking throughout the session, it's a chance to go in there and clean it up. Um there's some fascinating things you can do in session end. Um because it runs on essentially like the control C like the exit of the session.
Um you can spin up other agents to say okay look at all the files that have changed in the session. Do they match what everything? We don't we don't do that. It's just um there's some really interesting things you can do with session end where my session is done. Does that session represent progress in this project? Does it represent Croft? Does it like look through all the files that were changed? Uh is this duplication of things that are already in the project? And if it is, like go through and clean it up and um and alert, you'd have to alert the user some way like through a system notification or through um some other like means since your session is is gone.
Uh but really interesting interesting things you can do in there. All right. So, um, with all that being said, if I just I'm just going to run a quick little demo here. Um, so I'm going to spin up a version of Claude Code running the Forcell plugin versus one that's not running the Verscell plugin. Um, I'm going to use um, claw dangerly skip permissions. I'm going to leave debug on. I'll show that in a second. And this model is going to be set to uh, haiku. So that's the fastest kind of dumbest model in for for cloud code.
Um, and I'm going to say like just uh write a tutorial about the AI SDK. Um, and just like we'll we'll see what happens there and going to compare it kind of side by side. You can see already it starts loading in the skill and this has the plugin um loaded in. If I want to start a session without um without any plugins loaded, there is a setting sources flag which uh gives you a chance to disable like user level sources or yeah user level settings or project level settings essentially just ignore any settings. So this way I can load it without plugins.
Um the no flicker Whoops. Uh this no flicker is new as of like yesterday. It's a nice way to um do smooth scrolling inside of Cloud Code. So, I'm enabling that as well. And then I'm going to set the model to Opus being the smartest model. And um if I just do the same prompt of I do a tutorial about the AI SDK. Um and this is like the vanilla version over here. And we'll kind of compare the results. Um oh, whoops. I need to I didn't delete the previous one. Let me start that up again.
Uh let me fire up this and run that again. This is a I I was running this this morning and didn't clean up before this started. So, let me just launch this again. Got to make an effect comparison. Yeah. Um, all right. So, um, the the huge difference here is this is Haiku 4.5 versus Opus 4.6, right? Like the most this is a million times cheaper and much much faster and it's just loaded with um a lot more versel information. So, um, even if you compare like the the budget cost of, um, the extra tokens we're including including versus, you know, Haiku versus Opus.
Um, while this is going into I should have just said a markdown file. I guess it's going into actually writing code, but that'll be interesting enough. Let's see. So this is um one thing to note about the uh one of the approaches we're taking for a lot of our skills is as mentioned before because of version number uh because pack the different skills might change for we need version number pinning that the skills let me rephrase that. Wow. uh different versions of our libraries have would require different skills. A lot of our skills say please um look at node modules where we'll bundle a lot of the docs so that the docs are kind of version pinned as well.
So uh looking in here you can see it was actually reading through the local docs and um it's going through here and putting together this tutorial. Um, all right. Now, let's give this This really didn't do any research at all. So, this will be interesting. Last time I did a lot more research and I can already see already like it's using um an outdated model, Sonet 4 instead of like 4.6. um it's using an outdated um it mentioned generate object which is not what we want to use. We use V6 and um there's already a bunch of things that are just outdated.
I wouldn't say they're wrong but they're like very very outdated for what the latest if you want the best performance and the best practices um from the AISDK. So, all right. This was Did this catch something in here. Yeah, it looks like Yeah, the ASDK skill caught looks like it wrote a tutorial initially in here and then the skill caught that it wasn't updated to V6 like without me saying anything at all and now it's going and updating. It went from generate object to generate text and it's going and updating everything to make sure that it's um on the latest versions.
All right. So, um we I can compare these two. I'll just start a new session. Um, let's go in here and um compare the tutorials from uh no plugin versus the tutorial um in versel plugin for accuracy. And this will be interesting to see like but every time I've run this before Opus wrote a markdown file. This time it did code snippets. Um it'll be fun to see the difference when you're doing this. Especially if you have other skills maybe working alongside this plugin. Is there a risk of them having a conflict and like resulting in outdated uh stuff being preferred or is the plug-in going to kind of take like higher priority?
Uh the plugin will uh essentially I would say forcefully inject skills based on its patterns. Okay. Um, so if there is there's kind of always that risk like it's all it's all just kind of context like all those they're just text files that get shoved into a session. Um, so I would always say only use the things you want for the the project you're on. um as a like very excuse me very rarely install a skill at the uh user level unless you know you want that with every single project. Um and even for the uh versell plugin we're we're working to find the best ways possible to like only only load what you need for the project you're in and we have a lot of ideas around that.
Um, but one of the one of the like most probably controversial ideas is where like when would a user say they they install the Versel plugin. So what assumption could you make about that? If they install the Verscell plugin and they're on a competitor's platform and they open a project in the competitor's platform, should we tell them about our stuff? Like that's it's very like it's a very controversial thing, right? And if if one person sees that and they didn't want and they're not actually uh interested on migrating uh whatever to Verscell, they'll get very upset.
If another person is, they'll be very happy. like it's so there's some really fascinating um if you take the if you subscribe to the theory that everyone's just going to interact with agents. Um like what is the etiquette in a plug-in or in uh informing agents of like the new great thing on your platform without like stepping on the feet of the other platforms. And so like there's a lot of things. Um this is very uh relevant to what I'm doing right now is we're going GA with uh workflow pretty soon. And so I'm writing migration guides if someone wants to migrate from one of Workflow's competitors.
Uh that you know directly uh could use a skill to say migrate from this over to Workflow. This is how you this is how you do it if you want to do that. like at what point in an agent would I inform someone of that? And that gets that stuff gets really really interesting to me. Um especially it's like super top of mind since it's what I'm working on my like right now. Um but yeah, like context conflicts like it's it's going to be a problem going forward. I don't know what um trying to infer what the user wants based on the context of their project of what they've asked so far.
It would be great like we could technically look at past conversations and see what they've done. We could look at commit history. Uh like we could uh tell the GitHub CLI to like go look at the uh anything in the project. Like there's lots of things you could do to go gather context, but that's also crossing some boundaries like calling tools they didn't need for you to call. lots lots of really interesting stuff that um if it it's it's much easier just to do everything in versel and just have like just rather than and like provide one agent with specific set of rules and a plugin that just like ships everything beautifully there and like not have to worry about uh all those conflicts.
Anyway, um I hope to be Um outside of a plug-in context, when are skills like at what point in this process are skills normally added? For example, if I had like a a migrate uh create react app to Nex.js skill and that was just sitting in my skills folder. Is that more likely to just automatically be invoked anytime I'm on a create react app project? um versus say if I have the versell plugin here, I can then decide when it's going to be invoked and I can if if I built that same migration as a plugin, I can make it kind of only happen if the user is explicitly requesting it.
Is is that the right mental model? I I think so. like uh we've been talking about um the concept of like oneshot skills or like single use skills that are more like I want to do the a thing like a migration which is like that's something that's a task you have or like a a task related skill that you don't want to load in any other time except for that task like you want it uh you want it scoped to the task you don't want it scoped to the project you don't want it scope to the user want scoped to the task Um, and those are discussions we're having and I think that's um I don't have a great answer because right now if you have a skill like that loaded then uh it's going to influence it uh a harness in the models based on the model and based on other skills like it's so it's so hard to say w without um knowing exactly what else is in the project.
But yeah, like that's definitely a um that's also top of mind is like that task scoped um task scope skills. Um another question on my mind here is how much of this um plug-in architecture is cla specific? Um so if I wanted to get similar behavior in cursor or codeex or any of the others, do they have their own plug-in format? Do I need a plugin for each of them? uh how does that work? Yeah, so uh we should have some announcements soon on the kind of the the spec around plugins and everyone agreeing on like finally having plugins that will work universally uh and cross cross compatibility.
Uh pretty much everyone's on board with that. I wouldn't say today today if you build a plugin in the cloud code format you can I would say you could expect it to work um with the others in a short amount of time. Um but yeah it's fantastic way too many skills folders already. I I'm really happy we're finally starting to standardize on something here. Yeah. Once the the idea like I I love when I was talking to Anthropic about plugins and the reason they chose the word plugin versus the word extension is that plugin implies that it's something you can plug in and something you can plug out.
Like so if you build a plugin with a set of skills and you only want to use it again for like a single task, um that's that's something that should be very doable. Um, if I'm in my project and I'm a designer and I want I don't want all of my design skills to be interfering with all of the developer skills or whatever, like you want to be able to plug in just those pieces. And I think like I strongly agree with those concepts is that individual people are going to have like their individual tasks and roles and projects.
Um, and they're going to want plugins more than skills because they're going and they'll probably want to curate their own plugins as well, like build their own set of thing skills and and hooks and everything that um are fully customized to the way that they work. Does this mean that I should be thinking of maybe disconnecting the Versell plugin if I'm working on a non-versal project? I would I would say like as of today yes because of how like it's very aggressive for sale forward and hopefully I don't get in trouble from someone by saying that but um like the the full intention of the V forcell plugin is like this is something if you want to load up your agent and say build me this thing and then that thing just kind of almost magically appears on Verscell.
like that's the the initial goal and we're seeing how that works and if that um based on the feedback we're getting we're pulling it back a bit seeing that um we definitely need to do more detection of like what's in the project to disable and and all these sorts of things and that's that's coming very very very soon. So you know pro probably keep it in like keep it installed and enabled because we're like it's we're actively working on that like we were just talking about this morning. So, um I see. So, it's it's kind of a trade-off where maybe in the future it'll understand a little better uh when it should invoke itself.
Uh but right now, the way the user controls whether this plugin is invoking or not is by plugging it in or unplugging it for a different session. Yeah. And right now, if you just type in uh slashplugin, you can go over to your installed plugins. Just tab over. You can go down to whatever plugin you want to disable and you can update, you can uninstall, you can do whatever. Um, so you can disable it that way. Um, and there's there's other like more advanced tricks of like setting up custom um uh customs functions or whatever that load specific sets of settings for whatever user.
Like it's it's all very weird of like the the concept of a profile of the person who sits down at the computer and like what are all the plugins they want based on what they're looking at and um there there's not a perfect solution for that. Um hope to be able to figure one out though. It's like when a Whimo pulls up and it adjusts all the seats ready for you the moment you walk in. Yeah. Yeah. Um, and I do think like at at a at a certain point I imagine we'll see agents asking you more about yourself.
I feel like that's a huge like the the concept of profile, identity, role, whatever. Um, to me feels like a missing piece. Um, unless you want to assume that everyone is now like the full project manager for an entire thing. I just don't I don't see that anytime soon. I just I feel like some people are just have better ideas about some things than others. Um so, uh yeah, let's let's review this though. Um so what's what's interesting? Let's see. These are Yeah, it's interesting that I'm having Opus review opus and it's still wrong, right?
like it's still recommending generate object in V6. Um let's do verify against the docs outline. so it's trying to verify and it's saying that you know my uh the one that I wrote um is incorrect. This is still showing um valid but dated. So like our haiku recommended uh the most the latest models and that's to me that's super important. I don't know how many times you've tried to use an agent to write a uh write something with AI and it's like let's use GPT40. You're like no that's like really old now and it's nowhere near the quality that we need.
Um which is just one of those like things you can detect capture and say like check the latest models in the AI gateway and like you could say detect the latest models and ask the user which ones they want and describe each model and all that sort of stuff. whereas right now these agents are always just like GPD40. Um it it has been interesting just as like a side note seeing cloud code recommending the anthropic SDK more and more recently where it didn't before. Um and you're like uh I think someone's tweaking some system prompts behind the scenes of like recommend our own SDK.
Um which I I don't blame them. It's a it's business, right? Um all right. Yeah. So generate object is still in there and so yeah good after checking the docs tutorial is more accurate. Uh several things I called fabric created actually exist. So yeah, this is Opus like realizing that these are actual things. Like this is Haiku with a plugin and Opus like writing tutorial trying to validate the tutorial. Like I had to tell it to go look exactly at the docs to to find that something that um Haiku with the plugin kind of one did in one shot, right?
Um and if you know the difference between Opus and Haiku, that's that's a big deal. Um, so here's a diff of like everything that I got right or the the challenges or changes. Um, anyway, so hopefully that like demonstrates in a a simple way. Um just like one of the scenarios the ASDK this is much much more um this for things like uh workflow and sandbox with the much much newer versel technologies that are incredible but not uh within the knowledge cutoff of models these distinctions become even greater because the models don't even know about them right um so so that's what the Versell plugin is for.
Um, if anyone has any questions, feel free to hit me up on on X or anywhere you can find me. Um, I love chatting about this stuff. Happy to like address any concerns or um, this is definitely uh, a work in progress and something, you know, we're going to iterate iterate and iterate and iterate until it's like this amazing magical experience. Um, and hopefully you can see the the beginnings of that today. Um, if anyone has any questions, I'm happy to answer them. If anyone has any plug-in ideas, they want to brainstorm, happy to talk about that as well.
So, uh, that's unless unless anyone wants me to dig in something else. That's, uh, what I have to cover for today. Really appreciate you taking the time. That's it's a lot to take in. It's a big shift. We've been moving so fast with all of these AI tools. Yeah, it's not going to slow down unfortunately. Um, one question I have is if people want to contribute in any way or if they find a bug and they want to report it, what's the best way to get that to you? Oh, yeah. The the repo for it.
Um, burcell uh is it burcellin or is it burcell plugin? Yeah,ell-ashplugin. All right. And I'll drop that in the chat as well so people have it. Thanks. Yeah, issues on there are great. Um, it will be rapidly changing. I I know I approved a big PR just right before this call. Awesome. All right, Jacob, any other questions from you? No, no, I think I think we covered everything on the stream. Yeah, thanks for going through such a in-depth and great demo. I feel like I'm set up to build kind of my own cloud plugins here now.
And um instead of just yelling at the agent when it decides to force push uh to main on me, I now know which hooks I should be telling it to use to make sure it doesn't do that again. So, uh that's that's super helpful. Pre pre-tool is your friend. It is your best defense against things you don't don't want to happen. So nice. Thank you so much, John. Of course. Thanks everyone. And thank you all for joining us. Uh you can find upcoming sessions at community.cell.com/events and we'll see you next time. Yeah. Um yeah, I'll see you in the community.
Have a great day everyone.
More from Vercel
Get daily recaps from
Vercel
AI-powered summaries delivered to your inbox. Save hours every week while staying fully informed.








