You know that I'm a hands-on type. I like building stuff and that means I like blue days the most.
Blue days, building days. Welcome to the culmination of week two. Welcome to week two,
day five. Let's get cracking. This is the day that we're going to build out a SaaS platform.
I'm working on one that is going to be a legal document drafter called PreLegal that we started
yesterday. You might be working on that too or you might be going in a totally different direction,
maybe inspired by the idea of having some template documents, having an AI chat that
lets you add commercial value. That's what we're doing. Let's get into it. And don't hate me,
but repetition is important sometimes. And we're going to repeat for one more time the MCP skills
plug-in stuff. Just at a high level, there are these three ways to give Claude capabilities.
You're pretty familiar with MCP now, the way to stitch together models and tools,
skills, which are just these text files, these markdown files that allow you to add in
information to Claude in a way that is progressive and which is efficient use of context,
and then plug-ins, which is a sort of package of all of the above and other stuff too,
like agents that you're now getting a good handle on. And all of this together, it has pros and cons.
And the pros for MCP is, again, about the adoption, the ecosystem, the flexibility.
The con is that it can be something that uses up lots of context and then they can be complex.
And we saw the Jira one can do things like losing its authentication and stuff,
which is really annoying. Skills, simpler, easier, very efficient with the context,
maybe less powerful. And plug-ins, something of the best of both, very easy to set up,
but they are strictly for Claude code. That is the lay of the land.
And when you're looking for new functionality, of course, the first place to start is with
plug-ins. And you go for things like MCP when you want to get very detailed and specific,
as we did with Atlassian's Jira and with the GitHub one too.
All right. And then the other thing to recap is going to be the thing that we built yesterday,
which began by reading in a Jira issue using the Atlassian MCP server. And based on a Jira
issue that had been written and was out there on Jira, we then used the feature dev plug-in,
which took us through the seven step process, step six of which was skipped.
And that then was used to create a PR using the GitHub MCP server. All of this,
running inside Claude code, all kicked off by that one command. That command is part of
the feature dev plug-in. We just said, implement Jira issue PL3 with a Next.js app in a directory
called frontend, raise a PR when you're done. That's it. Go do it. And it went and did it.
And so the thing that's missing from here that you might be like, Ed, you said that
we were going to do skills. We didn't use a skill. So we'll make up for that today
and recap a reminder on how skills fit into the picture. They can be included in plugins,
of course, but basically it's this idea of having a metadata, which describes at some very simple
level what this skill is about. And that always gets read into context. And then progressively,
the model decides, do I need to use this? And if so, then it reads in the instructions.
And in reading the instructions, there are references potentially to other files and
even to scripts that can be run. And only if it needs to, the model decides to read them in as
well. So there's this sort of three level of depth of information that the model can read.
It always reads the top, the metadata, and it chooses what else to read in. And the metadata
and the instructions all sit together in one file called skill.md together. The metadata is at the
top. You may remember it has like a special way of symbolizing it with some hyphens that we will
do in a second. So you've got that. And yeah, they're implemented using this fancy thing called
a file system architecture, which is just saying, hey, it's just use folders with a particular name.
And so the structure is shown right there. You have a .cloud in your home directory,
and you also have one in your project directory. And if in there, you put a skill with this kind
of folder structure, then lo and behold, that will be a skill that Cloud Code can use.
That's all there is to it. Okay, so here I am back, back in VS Code, back in the pre-legal
repo. It's time for us to get on with today's project. I'm just going to do a quick git status
to understand where things stand. Check we're in branch main. And actually, in submitting all the
PRs, Cloud Code did not automatically submit the .cloud directory because it felt like it wasn't
actually associated with any of the work that it was doing. So let's just do a git add to bring
that in and commit that, the cloud settings, and push that to the repo so that we have now made
sure that we have everything consistently in our repo and that other people in the project
will also be using the same plugin as us. All right. Now, in starting up our project for real
work based on where we are with pre-legal, there's a few things we might want to do. One of them is
something that maybe we should have done yesterday, but I thought we'd wait until the real project
kicked off. And what is that? What do you normally do at the start of a project like this? You
normally make a good cloud.md file. But first, there's something that I've not even mentioned
to you, which is that there's more than one cloud.md file. And I'm not referring to the fact
you can have many of them in different subfolders. I'm saying that not only is there one in your
project directory, but you can have a cloud.md file somewhere completely different. And you've
probably already guessed this. You know the way that there's this .cloud folder right here,
which is where you have settings. And you remember I told you, you can have skills in here as well,
and that you can also have skills in your home directory. Well, you can also have a cloud.md
file in your home directory. And that means it's not associated with any project. It's associated
with you, the user. It's for your work with Cloud. And of course, I have one in my home directory,
and you should too. And it's something which should tie to your style and to what matters
for you when you're working with Cloud Code. And back in the day, there was always people
all had the sort of the cloud.md that you should have. And of course, Anthropic has been catching
up. And it's been incorporating common things already in Opus. So there's less need to have
something that's boilerplate. Nonetheless, I have some things that are my pet peeves.
And so I will show you right now. I have just gone to VS Code to new window. And then I did
like an open. And then I just opened in my home directory. And this is what I see. So this is my
entire home directory. There's lots of dot folders in here. There's one called .cloud.
And this contains all of Cloud's own folder structure that you shouldn't touch. That has
lots of things that are the stuff that it looks at, like it's telemetry. It's got some project
information that it stores, lots of stuff. And then it has a cloud.md. And that's what we're
looking at right here. And I've just got a few instructions in here. And if you Google, you'll
find that people have all sorts of tips about things to put in here. As I say, generally
speaking, Anthropic has added a lot of this in by default. So you should just use this to add in
extra nuggets of information that you want to add to Cloud's context every single time.
So the key is to keep this super short and concise and make every word count because
every token count. Open a preview because this goes in every single context you ever have.
So I've just got like very important. Be simple. Approach tasks in a simple,
incremental way. Work incrementally always. Small, simple steps. I know I'm repeating myself,
but when you really want something to be remembered, that's not a terrible thing to do.
Validate and check each increment before moving on. Use latest APIs as of now. Mandatory code
style. Do not over-engineer. Do not program defensively. You'll recognize some of this I've
also been using in my cloud.mds within the project for your benefit. But I have this stuff in as the
standard. Use UV as the Python package manager. Always UV run, never Python 3. Always UV add,
never pip install. Favor clear, concise docstring comments. And by the way, that's because I love
UV and it works really well for everything I do. And I recommend the same, but you may not. You
might prefer to use a more vanilla Python and pip. Favor concise docstring comments. Be sparing with
comments outside docstrings. Favor short modules. Important debugging and fixing and so on.
All right. And I'm going to add in here a few things here. Why not, since we're here,
let's come here and let's say never use emojis. No emojis. We'll put it twice. No emojis. Never
use emojis in code or in print statements. Print or log or log. Print statements or logging.
Let's make that super clear because that causes problems on PCs and it causes nothing but trouble.
And Cloud Code loves emojis. And keep readme concise. And avoid and clean up
old files. That will probably do. Maybe that's a bit. We'll just say keep readme concise. That
seems fine. That's enough. That's enough. Two more things that we have added to the general
Cloud.MD. A great practice to have. You don't need to copy what I've got here. You should do
whatever matters to you. Maybe you like emojis. Maybe you like long readmes. In which case,
keep it. But if you're like me, then put it in here. And then I've got some important debugging
stuff that's just, again, the really key points here. Always identify root cause before fixing.
Prove the problem first. Don't guess. Test one test at a time. Be methodical. Don't jump to
conclusions. Don't apply workarounds. That sounds good. And let's also add reproduce consistently.
Let's put that in there. Keep it short and sharp. But that is the point. Okay. And with that,
I've saved that file. That's given us a good Cloud.MD in our home directory that will always get used.