Posted by sshh12 2 days ago
Just to not confuse, MCP is like an api but the underlying api can execute an Skill. So, its not MCP vs Skill as a contest. It's just the broad concept of a "flexible" skill vs "parameter" based Api. And again parameter based APIs can also be flexible depending on how we write it except that it lacks SKILL.md in case of Skills which guides llm to be more generic than a pure API.
By the way, if you are a Mac user, you can execute Skills locally via OpenSkills[1] that I have created using apple contianers.
1. OpenSkills -https://github.com/BandarLabs/open-skills
My current project I have a top level chat , then one chat in each of the four component sub directories.
I have a second terminal with QA-feature
So 10 tabs total . Plus I have one to run occasional commands real quick (like docker ps).
I’m using qwen.
So now you need to get CC to understand _how_ to do that for various tools in a way that's context efficient, because otherwise you're relying on either potentially outdated knowledge that Claude has built in (leading to errors b/c CC doesn't know about recent versions) or chucking the entirety of a man page into your default context (inefficent).
What the Skill files do is then separate the when from the how.
Consider the git cli.
The skill file has a couple of sentences on when to use the git cli and then a much longer section on how it's supposed to be used, and the "how" section isn't loaded until you actually need it.
I've got skills for stuff like invoking the native screenshot CLI tool on the Mac, for calling a custom shell script that uses the github API to download and pull in screenshots from issues (b/c the cli doesn't know how to do this), for accessing separate APIs for data, etc.
I think if it literally as a collection of .md files and scripts to help perform some set of actions. I'm excited for it not really as a "new thing" (as mentioned in the post) but as effectively an endorsement for this pattern of agent-data interaction.
So if youre building your own agent, this would be a directory of markdown documents with headers that you tell the agent to scan so that its aware of them, and then if it thinks they could be useful it can choose to read all the instructions into its context? Is it any more than that?
I guess I dont understand how this isnt just RAG with an index you make the agent aware of?
The skills that I use all direct a next action and how to do it. Most of them instruct to use Tasks to isolate context. Some of them provide abstraction specific context (when working with framework code, find all consumers before making changes. add integration tests for the desired state if it’s missing, then run tests to see…) and others just inject only the correct company specific approach to solving only this problem into Task context.
They are composable and you can build the logic table of when an instance is “skilled” enough. I found them worse than hooks with subagents when I started, but now I see them as the coolest thing in Claude code.
The last benefit is nobody on your team even had to know they exist. You can just have them as part of onboarding and everyone can take advantage of what you’ve learned even when working on greenfield projects that don’t have a CLAUDE.md.
I use Claude all the time, and this is probably my biggest issue with it. I just workaround by manually supplying context in prompts, but it’s kind of annoying to do so.
Does anyone else struggle with this or am I just doing something horribly wrong?
But I dunno. I kind of wonder how I would have acted with tech like this available when I first started years ago. As a young engineer and even now I live and breathe the code, obsessing over testing and all the thing that make software engineering so fun. But I can't say whether or not I would have overdepended on an LLM as a young engineer.
It's all kind of depressing IMO, but it is what it is at this point.
Or I could just tell Claude Code to do it and then spend some time cleaning it up afterwards. I had that thing working quite robustly in days! D A Y S!
(Then I had the bright idea of implementing a "track changes" mode which I'm still working on like a week and a half later, haha)
Even if you were already familiar with all that stuff, it's a lot of code to write to make it work! The stylesheets alone... Ugh! So glad I could tell the AI something like, "make sure it implements light and dark mode using VueUse's `useDark()` feature."
Almost all of my "cleanup" work was just telling it about CSS classes it missed when adding dark mode variants. In fact, most of my prompts are asking it to add features (why not?) or cleaning up the code (e.g. divide things into smaller, more concise files—all the LLMs really love to make big .vue files).
"Writing most of the code"? No. Telling it how to write the code with a robust architecture, using knowledge developed over two decades of coding experience: Yes.
I have to reject some things because they'd introduce security vulnerabilities but for the most part I'm satisfied with Claude Code spits out. GPT5, on the other hand... Everything needs careful inspection.
If theres enough interest, I might replicate some examples in an open source project.
To see if it is easy to digest, no repeated code etc or is it just slop that should be consumed by another agent and never by human.
Code is no different! You can tell an AI model to write something for you and that's fine! Except you have to review it! If the code is bad quality just take a moment to tell the AI to fix it!
Like, how hard is it to tell the AI that the code it just wrote is too terse and hard to read? Come on, folks! Take that extra moment! I mean, I'm pretty lazy when working on my hobby projects but even I'm going to get irritated if the code is a gigantic mess.
Just tell it, "this code is a gigantic mess. Refactor it into concise, human-readable files using a logical structure and make sure to add plenty of explanatory comments where anything might be non-obvious. Make sure that the code passes all the tests when you're done."
I think we'll be dealing with slop issues for quite some time, but I also have hopes that AI will raise the bar of code in general.
This feels like a false economy to me for real sized changes, but maybe I’m just a weak code reviewer. For code I really don’t care about, I’m happy to do this, but if I ever need to understand that code I have an uphill battle. OTOH reading intermediate diffs and treating the process like actual pair programming has worked well for me, left me with changes I’m happy with, and codebases I understand well enough to debug.
It is why I am a bit puzzled by the people who use an LLM to generate code in anything other than a "tightly scoped" fashion (boilerplate, throwaway code, standalone script, single file, or at the function level). I'm not sure how that makes your job later on any easier if you have even a worse mental model of the code because you didn't even write it. And debugging is almost usually more tedious than writing code, so you've traded off the fun/easy part for a more difficult one. Seems like a faustian deal.
It's much easier to review larger changes when you've aligned on a Claude generated plan up front.
I have started experimenting with a skills/ directory in my open source software, and then made a plugin marketplace that just pulls them in. It works well, but I don't know how scalable it will be.
My concern with hardcoding paths inside a doc, it will likely become outdated as the codebase evolves.
One solution would be to script it and have it run pre commit to regenerate the Claude.md with the new paths.
There probably is potential for even more dev tooling that 1. Ensure reference paths are always correct, 2. Enforces standard for how references are documented in Claude.md (and lints things like length)
Perhaps using some kind of inline documentation standard like jsdoc if it’s a ts file or a naming convention if it’s an Md file
Example:
// @claude.md // For complex … usage or if you encounter a FooBarError, see ${path} for advanced troubleshooting steps
Most of the time I'm just pasting code blocks directly into raycast and once I've fixed the bug or got the properly transformed code in the shape that I aimed for, then I paste it back into neovim. Next i'm going to try out "opencode"[0], because I've heard some good things about it. For now, I'm happy with my current workflow.
I recommend using it directly instead of via the plugin
This is how we are doing it too, for the same reasons. For now, much easier to administer than trying to figure out who spends enough to get a real Claude Code seat. The other nice thing about using API keys is that you basically never hit rate limits.