Create Claude Skills for Data Tasks

Hello everyone and welcome to today's session. My name is Rhys and I'll be your host for today's session. We are going to get started in a couple of minutes at the top of the hour. We're just waiting so everyone has a chance to join before we get started. If you haven't done so already, please do register for this session. You can do so using the QR code that's on screen at the moment. You can also use the following link that I'll put in the chat as well. So yeah, please do register if you haven't done so already, although I'd imagine most of you are registered if you are here during the warm-up. Uh, Super Wombus has asked, will the video on demand be published to the channel after the session? Yes, it will be. Uh, if you do register, we will send you a copy to your inbox as well. If you do want to join in with today's session, everything you need is in the, uh, resources document that is pinned to the chat and in the video description. So everything you need is in there. However, you are obviously going to need, uh, Claude as well. To join in with us. However, I believe, uh, we should be able to do this in, uh, any other LLM of your choice, uh, considering these skills are markdown files that we're gonna be covering today. So bear with me, maybe ask that question during the stream and we can, uh, we can get Tom to answer that one. But yeah, everything you need to join in today is in the resources document that is pinned to the chat and also in the, uh, video description as well. If you have any questions or queries at any point throughout the session, let us know in the chat. We are gonna be answering your questions for the last 10 minutes of the session, so make sure you stick around for that. And also, uh, not to forget, we have another set of live events coming for you next week. Uh, on Monday we're actually doing a session on Open Claw, so I'll post a link to this in the chat. Um, but yeah, next week we are kicking off our AI Agents in the Enterprise series of events. So we have events running from the 27th of April, which is Monday, all the way through to May 8th. So there's quite a lot of crossover between what you will have been learning this week in our Anthropic Age series. Please go have a look at that. Check out the link in the chat. Whatever I Want says, double check your Claude resource limit. Yes. Good idea, good idea. Cool, this shouldn't be too heavy on your Claude system, so you're probably not gonna run out of usage, but we are gonna stick solely to Claude today, so keep your questions strictly to Claude. Cool, for anyone that's just joined, welcome. Thank you for joining the session. We're gonna be getting started in just about a minute or so. Everything you need to join in with today's session is in the resources document that is pinned in the chat and in the video description as well. So we've got all the links you'll need for today. We've got all the sessions that we've been running this week, and then we've got some extra content in there if this wasn't enough as well. If you have any questions or queries, let us know in the chat and yeah, we'll get those answered for you. We're gonna be saving the last 10 minutes of the session for your questions, so make sure you stick around. For that. And also check out the other links that I've put in the chat. Uh, if you've just arrived, this is the 5th and final session in our Anthropic Age, uh, campaign. We are kicking off a new series on Monday called Agents in the Enterprise. And tomorrow's, uh, not tomorrow's session, Monday's session is How to Build an Executive Assistant with OpenClaw. So please do, uh, yeah, join us for that one on Monday, same time again, 11 Eastern.

Brilliant.

I think that's it for now. So we will get started very shortly. I'll appear on screen and yeah, we'll kick things off. Okay. Hello everyone and welcome to today's session. Uh, I will kill the music and we'll get going. Brilliant. So, uh, welcome back. Welcome back to the 5th and final session of the Anthropic Age. A common theme this week has been building agents to partially or completely automate tasks using Claude Cowork or Claude Code. Each of these hands-on sessions has made use of a component called Claude Skills. Today, we're going to take a closer look at Skills with some applications to data tasks. So if you've attended any of the other sessions, you're still going to get something new today. And if you didn't, you're not missing any prerequisites. However, if you do want to go back, the other sessions are linked to in the session resources, uh, doc pinned in the chat and in the video description. The idea behind skills is straightforward. Writing prompts gets repetitive with you telling the AI to do the same thing and write the same way and use the same tools in many projects. Skills let you package prompts to reuse between projects and share with colleagues. Your presenter for today's session is Tom Farnschleider. He is a data scientist and technical educator at DataCamp. So I'll bring Tom into the studio. Hey, Tom.

Hi, Rhys. Thanks for having me.

You're very welcome. Yeah, very excited to get started. So Tom writes and manages our data science tutorials and blog content. And before DataCamp, he worked in data science at Deutsche Telekom. So you're in very good hands. Over the next hour, Tom is going to walk you through designing and building Claude skills for data tasks. He'll create skills for EDA and feature engineering and apply them to a real soccer dataset to generate insights and build analysis-ready features. So without further ado, over to you, Tom.

Yeah, thank you very much, Reece, for the introduction. And hi, everybody who joined in. I hope you're all ready for a nice session on Claude skills. While the weekend is approaching. And, um, yeah, let's get started. As, uh, Rhys already mentioned, I'm data blog and the tutorials. Um, so first of all, I want to encourage everybody to check out our blog. We have a ton of resources on many, many different topics such as AI, statistics, data engineering, business intelligence, and everything in between. We also have a lot of coverage of Claude, all the latest Claude models and how they compare to competitor models, and a lot of tutorials on Claude code specifically. So make sure to check that out. Another thing I'd like to mention is that I'm currently doing an MLOps project that builds a pipeline to compare 9 different models on how well they can predict the goal distributions of football national team matches and then use the best-performing model to predict all matches of this year's FIFA World Cup. So stay tuned on that one. There will be a couple of articles coming out closer to the tournament. And one thing I'm— one reason I'm also mentioning this is because we will be using the silver data of this project today in our live demo. But let's talk about Claude skills. So generally speaking, Claude skills are markdown files that contain sets of instructions for specialized tasks. They contain a name, description, and the instruction body. And the way it works is that whenever you open a new chat with Claude and you type in your prompt or like hit send, Claude will scan through the descriptions of all your skills, and whenever one of those, the skill description matches the intent of your prompt, it will then load those instructions into your prompt. For example, if you have defined a data cleaning skill and you drop in a dataset and ask Claude, "Hey Claude, can you please clean this dataset for me?" It will go through all the descriptions of the skills, will see, ah, okay, this one refers to data cleaning, then loads all the instructions, and in the end Claude will clean the data exactly how you defined it in your skill. Skills have a couple of advantages. For example, they are modular, so you can have one skill per task that you recurrently use, which is great to achieve consistent results throughout each run. And also enforce your quality standards and personalize the output however you want to use it. They fire automatically, which means you just have to write it once and then never again. Like, like Rich already said, you don't have to repeat yourself over and over again, which is a really big advantage, especially if you think back of the early days of AI tools when you had to repeat yourself all the time. Once the skill is defined, it always triggers when this description is matched in a prompt. That doesn't mean that they're like— that doesn't mean that they are set in stone. So when you have to reiterate, you can always update your skill. For example, if you're not happy with the results or your requirements change, you can always edit the skill, but you don't have to repeat yourself in the prompts itself. And finally, they are composable. So that means that you can stack multiple skills to a multistep workflow. For example, you can trigger multiple skills from the same prompt, or you can also do it sequentially. So you open a conversation, you first trigger one skill, and then later you trigger the next one. We will exactly do that in our demo, by the way, today. So you will also see that in action. Sometimes people get a little bit confused with how Claude's, like, agent skills in general, um, compared to system prompts or rule files, uh, which makes sense in some way because they are, uh, they are similar in that they add context to a prompt, additional context, but how they do it is quite different. System prompts and rule files are quite similar to each other, which means that in the sense that they are fully loaded every single time. So in, in contrast to skills that only are loaded when needed, like we learned now, um, they are always loaded, um, and just the scope between the two matters. So system prompts are always loaded in each conversation, for example, in the Claude AI browser user interface that most people use, um, quite every, every single day, I guess, and, uh, or per API call, um, and, uh, at the same time, rule files are more like per project repository. So This is something you would use in Claude code or also similar tools like Cursor that are not technically in the Claude environment. Some best practices for Claude skills, and the first one is maybe the most important one. You always have to write a clear description for your skill. Even the best skill in the world is pretty much useless when it's not matched in in your prompt by Claude. So you have to tell Claude what is the use case for this skill. It's usually a good start to have one very clear natural language sentence that clearly describes the use case you intend to have. But what is also additionally useful is to include some trigger phrases, and it doesn't need to cover everything in the book, but especially if you use some special terms personally or in your team, when you want to, I don't know, if you have some special internal language, you should include those so Claude successfully matches your prompt to the skill it should use. Another thing is that it might be tempting to create one giant overarching super skill that combines a few tasks in one skill, but in practice it's not really, not practical because you can't take a skill and decompose it into smaller units, but you can always take multiple skills and compose a workflow out of multiple of those skills. So smaller skills are easier to maintain and they're also more flexible. If you only need to use certain parts of this one giant super skill you wanted to build, then doing the full skill is not very efficient. Thirdly, you should always know what goes into the prompt and what should go into the skill. The skill should be able to use regardless of domain while the— well, so every kind of extra context that you have should go into the prompt. For example, in our case today, we will be building two skills, one for exploratory data analysis and one for feature engineering. And we want them to work on any kind of dataset. The football dataset is just an example. So we won't put any kind of football language or football logic into the skill. This goes all into the prompt. Those three ones that I just mentioned were more general things to keep in mind when building skills, but when your library grows, there's a few additional things to keep in mind. The first one is you should never have overlapping triggers. If you have two skills where the description overlaps enough and you hit a prompt that targets exactly this overlap area, then Claude doesn't know which one it should trigger. You can't really predict which of the two skills it will use, or it might even use both, which is of course not very efficient. And if you don't know which one it will choose, it also kind of counteracts this whole idea of getting consistent results. So you should always make sure to keep the descriptions distinct. One way to do this is, for example, to use negative trigger terms. So not only to tell it on which kind of terms it should activate a skill, but also on which it should not. If you have two skills that are very similar, you can, for example, use the trigger terms of the one as negative trigger terms of the other and vice versa. Secondly, you should always test changes in skills before you kind of commit. I say kind of commit because there's not really a versioning available in the Claude user interface. But you should make sure that the skill works, the new version of the skill works exactly like it should before you delete the old one. One way you can, for example, do this is by duplicating the old skill, then adding some suffix to the name, something like V2, like version 2. And then you edit the new skill like you want it to be and test it. Only one thing to keep in mind, which is very important, is that you deactivate the description of the old skill. Because like we talked about this overlapping triggers, of course, if you have exactly the same description, it's 100% overlap. So you should take the old version of the skill and while you're testing the new one, deactivate it, write something like, "This skill is archived, please do not use it," so Claude knows to skip it. And also one important thing is, especially if your library is growing a lot, you should have some kind of naming conventions. There's not really any folder or any way to make own folders to organize skills in the user interface, which is not really optimal. The only folders that there are is if you have an organizational account and you have the organization-wide skills and the ones that were shared with you and your personal ones in 3 different folders. But apart from that, you can't really create any yourself. This is why naming is very important. A good idea is to have some prefix. For example, if you have not so many data-related skills, you could let every single data skill start with a data prefix. Or if you have a lot of data skills, you could also use the medallion architecture and have gold, silver, and bronze prefixes, for instance. All right, what we are building today, as I hinted already on, is two different skills. We will first build the EDA skill and then use it to analyze the football dataset. We will then create another skill about feature engineering that turns the dataset into a goal dataset with exactly the kind of features we want to have to train the model and predict the, yeah, the goal distributions. And then we'll test it in the same chat or same conversation in which we already use the EDA skill. To kind of chain both together. Yeah, I already hinted at the Medallion architecture. This is good for illustrating, I guess, what we're about to do. For those who don't know it, the Medallion architecture describes different— it's a concept from data engineering and describes different levels of data. You have the bronze data, which is the raw, freshly ingested data where you didn't change anything yet. You have the silver data, that is the result of cleaning the data and validating the data and also merging different sources together. And then finally, you have the gold data, which I already mentioned, the one that gets fed into a model or that you load into your BI tool to do some data analysis with, whatever you want to do with the data, basically. So today we are automating silver to gold, but with the goal of prediction. Yes, as I said, the example is the subset of this Silver data from the project. So the data set contains all football national team matches from 2018 onwards. I chose to take a subset because otherwise the data set would have been a little bit big. It's about 7,000 matches in total. So we are working with a 10% subset of about 700 matches. I tried to keep the data as representative as possible, especially for the goal distributions and a couple of important variables. But it might not be 100% representative. But still, I think we will discover a lot of patterns that we would discover in the full dataset as well. And yeah, the real takeaway is that we could use the skills we build for any kind of dataset. It doesn't matter if it's football data or sales data. The skills we build should work for any kind of domain. OK, and with that in mind, we can get started with the demo. Just a second. All right, here we are. So this should look very familiar to everybody out there. We are in the Claude user interface in the browser. And now we will search for skills. It's a little bit hidden, so we go to the sidebar, Customize, and then Skills. What you will see here is all the skills that you have created. And if you haven't created any yet, you will at least see the Skill Creator skill, which is kind of the skill to rule them all by Anthropic. It has this structure that you would usually see if you work with Claude Code, for example, a little bit more thorough than in the UI. You have the name of the skill as kind of a folder and have the skill.md file, which is the actual skill. And then you have a lot of different things you can add. You can define some subagents, which are then in itself, again, markdown files. You can add references, you can add scripts. So that's very cool, especially if you're in software engineering and working with Claude code. Today we will keep it much simpler than that. This was just for reference. You will also see that it's not even possible to get this kind of structure if you create it through the user interface itself. But yeah, that's what we will do today. If you go on Create Skill, you see that there's still different options. If you go to Create with Claude, it will put you back to a normal chat window where you use this Skill Creator skill to, yeah, create a skill together with Claude. It's a little bit skillception here. But today we will do it manually. Of course, I have the skills already prepared, but we will go through everything step by step. So we will start with the exploratory data analysis report. Let me quickly copy that over. Here we go. And yeah, one thing to keep in mind for the skill name is that it needs to be in kebab case, so only small letters and connected by hyphens. So the description itself starts with a very general sentence that describes the intent. So use the skill when the user asks to explore, analyze, or profile a dataset, followed by a couple of trigger terms: EDA, data profiling, what does this data look like, analyze this dataset. Those are all different ways to phrase that you want to have a data analysis. And for this one, we also use a negative trigger term. Do not use for single question queries like how many rows or show me the columns, because you don't need a full multi-step report to answer one question like that. So this would be a little bit overkill. So when we go to the instructions themselves, a good way to start is with some structure. It's a good idea to always give it some different sections or steps, something that Claude can follow through. We will have 5 of such sections. And another thing you will notice here is some pattern you— I will use throughout, which is we first tell Claude what to do, and then we tell Claude what not to do. So we want, uh, to have the EDA report following the 5 sections, and we don't want it to add, remove, or merge, or basically deviate from the section structure. Um, this might look like it's not necessary, but, uh, I found that when you leave this second sentence out, then Claude sometimes deviates from the structure. So it's better to be very specific. Um, secondly, uh, you should always define how you want the output to be. I really like the HTML artifacts feature, but I sometimes had a little bit of trouble with, um, images not showing properly. So I decided that for today we should receive all the results directly in the chat and not use the HTML artifacts. So talking about graphs, we have to be also specific in the way we want to have the graphs displayed or created, because otherwise it might differ from run to run. We will ask for matplotlib figures. We want one multi-panel figure per section. To not have trouble with too many figures or have them scattered all over the place, but it should be nicely clean. Yes, and they should be also generated in separate code blocks within each section, not in one block at the start, so we can nicely section by section go through them. And the last thing before we go to the sections itself is one thing that Cloud should ask us before we start if we don't give the context in the prompt. So as I said, it's always good practice to add any kind of run-specific context in the prompt. But if you have any kind of context that's important to take into account for the workflow itself, and it would be a problem if you don't have this context, it's good to write something like this. Because one of our, 2 of our, kind of all of our sections kind of depend on the selection of the target variable that we will be using. So we have to tell Claude to ask us if we don't put it into the prompts before already. And again, we tell it what to do to ask us and we tell it what not to do, which is assume the prediction target unless the prompt has it already. All right, let's start with the sections. So section number 1 is more of a general overview. We will take a look at the shape of the, of the dataset, column names, data types, and we'll group the columns by the level of, yeah, how much data is missing and how many rows there's a missing value in each column. Oops, it's the same one. For the second section, we will do profiling of the target variable. This may be the most important step. We want to see the distribution of our target variable. We want to have summary statistics. We want to see outliers, all that kind of stuff. Section number 3 targets all the other features. So yeah, the possible— or all other variables which are possible features, their distributions, their relationship to the target variable. A little bit specific instructions dividing for numeric features and categorical features, because of course they are quite different or have to be treated differently. And we want to know which are the strongest and weakest predictors of the target variable. Yes, section number 4— ah, copying is faster. All right. Yes, section number 4 are temporal patterns. There are many datasets where this is maybe not the most important one, so this might not always be relevant. It's still good to include. I mean, worst case, we get a very short section that tells us that there's no patterns in the data. Which they will probably do for our dataset. And the final one is kind of an overlap with, with our feature engineering skill. Maybe it's just to make a point that the overlap in the instructions is not that, not that much of a problem, not a problem at all. It's only a problem when the descriptions overlap. Here it can kind of be considered a step towards the direction of that the context window already contains some reasoning by Claude about what are probable issues when we later construct the features and start the modeling process. All right, with that, we are complete. We hit Create. And we open a new chat. So we can keep it quite simple for the chat now because also I want to show you how it looks like when Claude asks us a question. So I will not tell it the target variable, which is, by the way, the home and away goals after 90 minutes. So let's just tell Claude to analyze this dataset. And that one row corresponds with one football national team match. And then we add the dataset. And we hit go. If it's taking too long, we can also go over to a previous run so I can show you the results there, but I want to at least stay here until it asks us the question. So we see it read the EDA skill, that's nice. So it matched successfully. It inspected the dataset shortly. And now it asks us for the prediction target and has a couple of suggestions. And we'll answer. This FT stands for full-time, by the way. So there's also halftime goals and extra-time goals and penalty goals— nothing we're really interested in. I think it's just relevant what is the score after 90 minutes. Yeah, let's maybe take a look at the earlier— oh no, OK, it's quite fast. Now maybe it's still better to take the complete one. Yes. So we see in section number 1, it gives us exactly what we asked for, the shape of the dataset. The groups of how complete the data is. Very nice. No graphs here because, yeah, I don't know what you— what would be good to put here. Not very graphic section. Probably in section 2 we do have one. Yes, we do. So yeah, both targets follow a Poisson-like distribution, just like we would expect it, because goals are generally Poisson distributed, maybe a little bit with overdispersion, so more like negative binomial distribution, but Poisson-like at least. We get all the summary stats for both of the target variables and some extra observations that we have a home advantage, that, yeah, there's usually— that the mean of the home goals is significantly higher than for the away goals. Yeah, and also this is quite expected that most results are in the 0 to 2 to 0 to 2 region, one of those 9 different combinations. And yes, we get a nice overview graphically. Those are the home goals. You can see the Poisson shape away goals as well. Yes, we have the goal difference between home and away, which looks pretty normal distributed. Yeah, and again, here's the home advantage in action. Here's this clustering around this kind of quadrant here. So yeah, looks very good. Section number 3. Okay, let's also open the figure here. Shows that ELO difference is also quite expected, is the by far single best predictor. To those of you who don't know what ELO score is, it's originally taken from chess and it's a measure of how strong a chess player, or in this case a football team, is. So The way it works is that when you win, your Elo score rises. When you lose, it decreases. But if you win against a team with a high Elo score, it rises higher. And if you lose against a team with a lower Elo score, it increases more. So it takes into account the Elo score of the other team as well. So it's a really, really good measure of how good a team is. So very expected that this is the best predictor. We also see that the EDO ratings itself are quite normally distributed with a light skew. What else is interesting? Maybe this one's interesting too, the mean goals by competition tier. The higher the stakes— this is the Football World Cup and those are friendlies— the higher the stakes, the closer, or like the less of a home advantage we have. That's how we should interpret it. But anyway, before I get sidetracked, let's continue. Yes, it also hints already that the in-game statistics, something like shots on goal, ball position, can't be used as predictors because they are not known before the match, obviously. I mean, this is something you could use them as some rolling averages from the last matches, but yeah, this is something that Claude now apparently didn't think think of. Maybe it would be something to keep in mind for some iteration. Yeah, temporal patterns we can keep very short. There's not really any temporal patterns in here. The only thing we can see is that there was a COVID gap here. But otherwise, yeah, pretty much noise. All right, yeah. The last section, I think, doesn't have any— no, yeah, doesn't have any figure. It's just telling us that there's no duplicates in the data. Leakage risk is a concern, yeah, with all those in-game statistics that I just talked about, or halftime scores, extra time stuff, everything that happens in the game, really. Let's see. Yeah, some correlations between the features. Yeah. OK, I think generally it looks good. Also, this is maybe the biggest one, that a lot of data is missing the in-game statistics. This was also a little bit of a problem in the project. The coverage was not great outside of Europe and South America especially. But yeah, I think that looks quite decent. Our skill did what it should in the way we wanted it to. So I mean, maybe quick scroll here. Maybe just like, let's take a look at the charts. Yes, looks very similar. Every block has one of those, one of those image with a couple of charts on it. Yeah, similar findings. And yeah, looks good. Let's define the second skill. We can go to Customize. Skills and write skill instructions. Okay, so the next one is feature engineering. Again, we have a very, uh, general sentence in the beginning, uh, use this skill when the user asks to engineer features, create model-ready data, or transform data from silver to gold "hot level," which are all ways to say the same thing. The trigger phrases are a little bit of a repetition here, but yeah, I think it should be more than clear from this description when this skill should fire. Again, we start the same way in the instructions like we did for the other skill. We tell it to to follow the 6 sections and not deviate from them. I think generally the instructions before the individual sections are very, very similar, so maybe I just paste them at once. Again, we want to have the results directly in the chat. We want to have charts in separate code blocks, and we don't want to have HTML artifacts. Here we have 2 things that Claude needs to confirm with us before proceeding, the prediction target, like in the EDA skill, but also now the model type. Because now when we want to engineer features, of course, it makes a difference what kind of model we choose. For example, a model like XGBoost can handle null values natively while other models can't. So this of course makes a difference for the selection. And again, we tell not to not assume either of those two things. And also in this case, we explain why. So yeah, basically what I just said with a different example. Let's go to section number 1, which is very similar to the last section of the EDA skill. We want to classify— this is maybe more leakage-focused. I think it's— maybe it's not— the overlap is not even that big. We want to know which columns are available for the prediction and which ones are only known after the event. And in this case, event means start of the game. Only the columns that are known before the game should be used for prediction and all the other ones should be dropped. Yes. Secondly, we will engineer new features. Something like differences, sums, ratios between related columns, or interaction terms, categorical encodings, you name it. I think this section in a more sophisticated version of this skill should be much, much more detailed. I kept it quite simple now for the demo, but here you could be much more specific. In which case which kind of encoding, for example, should be used. But yeah, we will leave a little bit of free hand to Claude for this one. Next, we will take a look at the missingness pattern again that we already had earlier. And yeah, this is, for example, something that's a little bit more specific. If a feature has more than 50% missing values, drop it rather than impute. Actually, we might— actually, I might remove this because we want to use XGBoost, and then it doesn't make sense actually. Yeah. But yeah, for all the columns that remain that are not prone to leaking, we want to apply an explicit strategy. So either the column is dropped. Or all missing values are imputed with median or mode, or, yeah, it's flagged with an indicator column that there's no data available. And the choice should always be justified. Very important to tell Claude to not silently drop rows because this is just about columns. Yeah, then we have a final dataset summary. With the shape of the output dataset, of the complete dataset with all the columns that are not leakage prone and the new ones we developed in step number 2. Yeah, and have their data types, summary statistics, a general overview over what we have in the output. But yeah, maybe also as a heads up, we will receive two different datasets at the end of this feature. Because we have the section number 5 where we ask Claude to recommend a selected subset of the features that we use for training. This is also another thing that could be way, way, way more specific. But, um, yeah, so here basically Claude has a free hand to, to recommend, um, what subset of the features it would use based on its own reasoning. Um, this is something that could be iterated on quite much. And then in the end, we have the export section, which gives us two CSV files, the complete one— sorry about that— containing all valid features and one with the selection that Claude recommended. So we hit Create. And we see it here. Yes, looks good. So let's start— no, not start a new chat, go to the chat that we now used. And this one we will keep very simple. Perform feature analysis— feature engineering, not analysis— feature engineering based on your findings. We can see it already read the skill, so it uses it. Now we wait for it to ask us what model should be used and what are the target variables. I think the target variables it might, it might take from our earlier chat because we basically told it here already. Yeah, I think it will probably only ask us for the model. Okay, it's already on it. Huh, interesting. And maybe while it's loading, we can go over, uh, normally it should, uh, ask us exactly this: what type of model are you planning to use? I thought I was very clear. Maybe, maybe you need to be even clearer. That's, uh, the demonstration effect, I guess. Um, so I answered XGBoost because this is the model that performed best in the prediction project. And then based on the information on the Based on the target we gave it earlier and the model, it starts the process. It drops all the in-game statistics columns, the halftime, extra time, penalty scores, post-match ELO— of course, it's after the match— a couple of metadata columns that are not important. They were just— important for merging the data in the silver step, so they are not needed for prediction. And we have 20 safe features. Next, we have a couple of new features that were created, uh, 6 new features that are based on the Elo scores: differences, sums, maximum, minimum, Absolute difference and the relative strength as a ratio. Okay, seems reasonable to me. A few date-derived features, not sure how relevant they are in our case. Maybe, maybe month for the different kinds of calendar windows for the national team matches because they're quite scattered across the year. Couple of competition context variables, configuration interaction, yes, and so on. Let's continue. I think I'm running a little bit late already, so let's speed it up a bit. So again, there was a few features that were dropped, rolling form features. Ah, yeah, okay. Yeah, and this one I still had this line in with drop everything that has over 50% missing. So this is not a feature, not a bug, this is a feature. Claude just used my instructions. There's a little bit of a problem of the small subset of the dataset. So there's about 200 different national teams and only 700 matches. So there's just not enough matches for any team to have a, form feature properly, properly without many missing cases. So for the first, I think the rolling features were for the last 5 matches, so if they don't have 5 matches then most of them are missing values. Still, 3 features are kept even though they have missing ones. And here it mentions that XGBoost handles them natively, so it takes the model successfully into account. Very nice. And yeah, we can see the number of rows is still the same as in the beginning, but now we have 33 columns. Uh, in the beginning I think it was 72, so significantly less even though we have a few new recreated ones. Um, so there was quite a lot dropped. We have 31 features and 2 targets. Yeah, home goals and away goals. A few remaining issues, there's still some, yeah, some features with high correlations, some flags for low variance, which is to be expected in those cases. I mean, there's not many finals, so is_final will be 0 almost all the time. Same for semi-finals or, yeah, knockout matches in general. Yes, so that's it. We have our final feature selection. Yeah, a lot of Elo-related stuff. Is neutral, which measures if there is a neutral venue, so that kind of is important to measure to kind of take out the home advantage because there is none in a neutral venue. Whether it's a KO match, the competition tier, whether it's an interconfederation or intraconfederation match, whether it's group stage, yeah, the confederation itself, the month, yeah, I guess for the seasonal scheduling patterns, yes, and the days since the last match. Perfect. So we hopefully now have two CSV files, yes. This is the full dataset. Yep. And the selected feature set. I think it only shows until t anyway, because this is just the preview window limit of Plot. But yeah, OK, this one's smaller, so this one I think shows completely. Nice. Yes. I think with that the demo is over and I would hand it back to you, Rhys.

Perfect. Thank you so much, Tom. We will— I'll leave your screen share going, but I'll just hide it backstage for the moment and we'll run through a couple of questions. We'll bring the screen share back if we need to. So yeah, we've got a couple of questions from the audience. We may cover a couple of ones that we've— you've already covered, but we'll just make them abundantly clear for everyone. So we've got this first one from Nicole. So Nicole asks, does each skill have to have a specific trigger?

It has to be clear from the description what the use case is. So it doesn't have to have exactly the term that you will be using in the prompt, but I think you have to think of it the other way around. If you, if you open a new window and you start your prompt, is it clear to Claude that this means the use case that is described in the description of the skill? So it can be kept quite general and still work, but the more specific the better, I would say.

Yeah, I think there's also the other thing where you can kind of— you can use multiple skills in, let's say, one prompt, right? And you don't necessarily have to trigger it. Um, for example, I work in marketing, so I've got maybe a skill for copywriting, but really the task that I'm looking for is maybe generating some slides. So I'll have a slide generation skill running, but also I want another skill to be prompt, to be checking the copy that's going into the slides. So yeah, it doesn't necessarily have to be specific, but if you're, um, starting a project or starting a chat and you include multiple multiple skills, they will run wherever they're needed.

Yeah, maybe one more note on this is the more skills you have or the more similar skills you have, the more specific it needs to be. But yeah, sorry, go ahead.

Yeah, cool. We'll move on to the next question. If you do have any questions as well, please drop them in the chat now. We're gonna run through the best ones. There was this one from Veronica that came through. So Veronica says, is our Claude skills similar to tool calling? So yeah, for anyone that's getting a little bit mixed up between what tool calling is and using a skill, what, what's the difference there?

Okay, that's a really good question. Actually, skills use tool calling a lot. So the difference is that tool calling is something external, like a web search or running a script. And Claude skills are basically just, I mean, like I said, they're just a markdown file, right? So they're just a set of instructions that are loaded. But whenever those instructions are added to the prompt, it usually leads to a lot of tool calls that are made on top of that. So I think if we take a look at, I mean, maybe you can go back to the screen sharing, maybe it gets a little bit clearer if we look at the traces. Let me see. Oops. Ah, yeah, here. So running this script, for example, is a tool call. We see that first Claude thinks, it reads the skill, it matches it, and then based on it, it goes through all those different subsections and runs scripts. In this case, I mean, it might be a web search for a different skill that is more research-oriented. But yeah, they are separate, but skills use tool calls a lot. Yeah.

Cool. And then we've got a similar one as well. So what's the difference between a skill and project context?

A skill is completely outside of a project context. I mean, I don't know if you now mean I don't know if you mean the context window of a conversation. In that case, like everything that is now in this conversation window is basically in the context window for this specific conversation. And this is just, I don't know, I'm searching for a right way to put it. But skills are persistent files, so they are completely outside of the context window and just get loaded when they're needed. So, um, I think— I feel like this is not a satisfactory answer, but, uh, searching for the right way to put it.

No, the way I think about skills, and I'm not sure whether this is strictly the best way to think about it, but I think of it as almost like an intelligent recipe. Like we have our steps for our process, the things that we can do, but it can also be slightly reactive depending on what the ask is and how we do it at the beginning. And with like project context, like say if you have like a Cowork project, then you've— you're say adding documents to your project folder. That's something that a skill can reference, but it's not necessarily going to be baked into the skill and what you're doing. Skill is like saying, go play tennis. Playing tennis requires several different things, but the context is, I don't know, watching tennis and reading some lessons from your teacher or something else like that.

And what you remember about it. Yeah, I think that's a really good analogy.

Okay, let's move on. So We've got one from Mary. So Mary says, could you use a skill to create a representative 10% of a total smaller dataset? So yeah, could you create a skill that creates like a smaller dataset for you?

Oh yeah, I mean, I could have created one, but because I don't see myself using that so often, I think having a skill for something you do one time is kind of overkill, but because you might, you know, you might use it in the prompt directly, right? But you could for sure. You could set up a few different rules. I mean, there, of course, you would again need to specify which columns are important enough to keep them representative. Because if you have a dataset like this with 72 columns and you want to get it to 10%, it's basically impossible to keep all of them representative. So you need to make some selection and— In this case, you would need to help Claude make the selection in the way you want it. But yeah, sure, that would be a use case.

And I guess another similar one along the same line is, can we use Claude skills to create ETL or ELT data pipelines? And can Claude skills handle other apps and tools? So yeah, maybe a good opportunity to maybe talk about connectors outside of tool usage.

Yeah, sure. For example, you can, like you, like you already mentioned, you can use connectors to, yeah, connect Skills to other tools. Like, I think also NHN and dbt are mentioned in the question. So yeah, for sure, that's a possibility.

A good one just came in from Lou Wanley. Not really sure on your name. Data processing can involve many steps. Should I put each step as a skill and then build an AI agent to use and monitor these skills?

Yeah, that's a good question because I think I earlier said that you shouldn't use one overarching super skill that comprises many tasks, but then each task has some substeps. So each skill should have some kind of structure in my opinion. You should just for yourself identify what is, maybe it's even a philosophical question, but what is a task? What is this one unit that you want to have together no matter what, which then probably still can be divided by different steps. So it's maybe also not very satisfactory, but this would be a classical, it depends on what you want to do. Cool.

This is an interesting one from BiberB1. So they ask, I have a habit of getting too detailed with my instructions. Do you have any advice on providing enough detail without providing too much that it doesn't generalize?

Oh, that's a really good question. Yeah, I think a good idea is just to start small. I think one mistake that many people make is they try to predict every possible edge case in the beginning. I'm sometimes guilty of that myself. So you, you try to construct this super complicated if-else structure in your head. I would just not do that. And maybe if you have one specific run in mind, just use all the instructions you would put into the prompt normally and save it as a skill. And then when you use the task again, you just add what you at what you would have liked in the last run, and then you add on top of it, add on top of it. At some point you have to abstract and, um, generalize it a little bit, but, uh, that's how I would approach it.

Cool. Um, we'll move on to, uh, well, actually another one for BBB1 because I think this is quite useful even though I did respond to it in the chat. So, um, Yeah. Can you define the Claude model to use within a skill or to instruct a skill to ask? So basically, when you are thinking about your token usage and you, you're using your skills, can you still define which, which model you're using?

Actually, I'm not sure about that.

Okay.

If you answer in the chat, then, then maybe you answer this one.

Okay.

Okay.

Fine then. The, the skill is a set of instructions and it, it doesn't matter which model you use, essentially. You're calling the skill from a markdown file, which is essentially your recipe, but it doesn't matter which model you use. The model is only going to affect how the skill, how effectively the skill is used for your particular task. So the skill doesn't change, but the skill is just a recipe that the model is using. So yeah, you define the model in your little chatbox and then You obviously type slash to get up your skills and then you're away. So yeah.

It makes sense. I think I just thought if there's some feature that I'm not aware of that maybe changes the model within a conversation or something, but yeah, makes sense.

That's a good point. If anyone's aware of that, let us know in the chat. And we're all learning. Okay. Hopefully a little bit more of an easy one from Marty. So Marty says, Dumb question, but does your dataset count towards your token usage?

Yes.

Yes. Another one from Nicole. Nicole says, do you have to use one prompt per skill or can you have asked Claude to conduct the data analysis and the feature engineering in the same prompt?

Oh yeah, that's a good question too. Yeah, that's totally possible to call it from the from the same prompt. You could, for example, say, yeah, conduct an EDA and then do feature engineering on this dataset. And maybe if you call both, I would be sure to add the context it needs in the prompt as well, because I'm not exactly sure how it then works with the asking. I think usually Claude reasons about the order and I think it would also work without it, but just to be sure, but yeah. You can do that.

Yep. We've got another few that are— another few questions that are pushing us towards finishing the demo example that we had on screen. One final note that I would like to add before we wrap up and before I let you know about what's kicking off next week here on DataCamp is that when I first got introduced to skills, I had quite a lot of processes that I used to work through in my job. And quite often it would be maybe a series of prompts, getting something together and then having specified inputs, certain steps, and then we'd get to a result. With Cowork and being able to build skills now, you can do that in one chat and then get to the end of the chat and say, Claude, 'Can we build this process out as a skill?' And it will use the skill builder to then go back and get everything and build the skill for you. So if you can do your workflow or your process in one chat window and you can do it in a relatively clean fashion where you're not doing loads of debugging and troubleshooting in there, then at the end of the chat you can say, 'Can we make a skill from this?' And then you're good to go next time. You just need to define what inputs you would give to Claude on the next run. And then say if it's just to do something with like a link or in my case, maybe a transcript of a webinar, like one of these sessions, then it just makes it super easy next time. And you've only got to build it once to constantly reuse it. But that is the crux of skills in general and today's session. So that's a closing note from me. I think we're about at time. So Before we go, Tom, thank you so much for sharing your insights today. As I mentioned at the start of the session, I'll put the QR code on the screen. From Monday, we have another series of events running, and that is AI Agents in the Enterprise. The session that we've got on Monday is Building an Executive Assistant Using OpenClaw, which is very, very similar to what we've been covering this week. So yeah, please do join us on Monday and throughout the rest of April and May for that. You can sign up via the QR code that's on screen now. You can also head over to events.datacamp.com/aiagentsintheenterprise. So yeah, hopefully see you there soon. Have a look in the chat for the link. But yeah, hopefully we'll see you on Monday and again in the near future. So yeah, thank you everyone for watching today. Tom, thank you so much for your insights and