Do these skills actually provide much value? Like, how much better are they than something that I could tell Claude to generate based on a single API doc from Slack/Trello?

Zero. If a skill actually provides value, one of two things happens: it gets absorbed into Claude Code (or similar) within a week, or a company packages it up and charges real money for it. The "free skill that gives you an edge" window is essentially nonexistent. By the time you find it, everyone else has it too. You're better off learning to prompt well against raw API docs than chasing a library of pre-built skills that are either trivial to recreate or about to be made redundant.

From my experience, most are just some high level instructions on how to use CLI tools installed on the system. A lot of the CLI tools they're calling out to have 0 reputation on Github or don't work at all.

I've had more luck writing my own skills using CLI tools I know and trust.

That's a big part of the reason skills are exploding, people use them as stealth marketing in addition to being a malware injection vector.

Skills is actually what also Claude code uses internally, it's cool because the llm will load the whole context on how to use it only on demand and keeps the context cleaner.

>Do these skills actually provide much value?

IMO, yes. Gemini et. al. out of the box are good at composing, but are entirely passive. Skills enable you to - easily, with low code/no code - teach your AI to perform active tasks either upon direction or under any automatic conditions you specify. This is incredibly powerful. Incredibly dangerous, too, but so is a car when compared with a skateboard.

My understanding is that it's just an abstraction layer that feeds right into the context window. Might as well just feed it into the prompt. I think cursor even proved that skills aren't as good as direct prompts (or something to that extent, can't remember exactly)

GitHub is the new Internet Explorer 6. A Microsoft product so dominant in its category that it's going to hold everyone back for years to come.

Just when open source development has to deal with the biggest shift in years and maintainers need a tool that will help them fight the AI slop and maintain the software quality, GitHub not only can't keep up with the new requirements, they struggle to keep their product running reliably.

Paying customers will start moving off to GitLab and other alternatives, but GitHub is so dominant in open source that maintainers won't move anywhere, they'll just keep burning out more than before.

It's all cool as long as you keep all of this up to date, and that requires a lot of scrutiny and discipline.

Once I had to go through a security audit at a job I had. Part of it was to show managing secret keys and who had access to them. And then I realized that the list of people who had access to one key was different than the list of the code owners of the service I was looking at, which was yet different than the list of the administrators of that service. 3 different sources of truth about ownership, all in code, all out of sync.

> 3 different sources of truth about ownership

I see only 1.

Admin, access <> ownership.

I always thought of this as authority, accountability, and responsibility of a thing. Ideally one group or person has all three. In practice you’ll have many entities with some combination of the three.

I am sure mere access does not imply any kind of ownership.

Isn't the point that this is the source of truth?

If someone needs access to a secret, you would implement it in this DSL and commit that to the system. A side effect would run on that which would grant access to that secret. When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.

From my experience, there is always a parallel process. But if you make the system painless enough, most of it will be in there, yeah.

> When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.

For this to work, you’d need to also rotate the secret, or ideally issue one for each person (so that others don’t have to update their configs).

...but sometimes you can’t reliably automatically rotate the secret, because they could have used it for something in production.

I used Oh My Zsh for years, but there were literally 3-4 features I relied on: autocompletion, git plugin, history search, and one theme.

For some reason it was slow to load which I found annoying, so I used Claude Code to optimize it. In the end I ended up removing Oh My ZSH entirely, now I have a single .zshrc file that contains everything, and it became much faster.

Similarly I moved from Packer to Lazy.nvim and updated a number of libraries, and from iTerm to Ghostty, Claude Code essentially converted my configs in a matter of minutes

The difference is that jQuery was replaced by other libraries, while Tailwind grows in popularity, but due to AI its creator doesn’t benefit from this popularity as much as before

jQuery was essentially replaced by JavaScript (and browser compatibility) getting better, but it continued to exist and grow because it was the de facto way to DOM manipulation, especially if you had to copy and paste off of Stack Overflow, or roll out a framework based UI.

Tailwind being the default choice for AI UIs is not that different, it can continue to grow in usage but the fundamental need for Tailwind has passed.

The difference is jquery went away because better things replaced it (in javascript). If the fundamental need for tailwind has passed why is it's usage growing? It's more that the problem solved by the paid portion of tailwind is now solved by AI.

I don’t think the language itself is Japanese centric. In the past the discussions among the language development often happened in Japanese, but I don’t think it’s the case anymore (though I don’t follow it closely) since there are a lot of international core language contributors now

Historically - like, way back - a lot of the Ruby core chatter happened on a japanese mailing list, and that's where a lot of decisions ended up taking place, or it wasn't uncommon to have sudden hard subjects bombdrop on the english side while a lot of discussion already happened on the mailing list already so it was hard to catch up.

These days it seems like bugs.ruby-lang.org has most of the chatter.

A lot of bootcamps taught Ruby and Rails in the mid-2010s, so it hasn’t been stagnant for 15 years, maybe since 2017-2018. Then Python (with DS and ML domains exploding) and JS/TS (with Node and React) left Ruby far behind.

That's not the definition of stagnant I would use. Its mostly on the lines of people learning the language, starting new projects, discussions etc.

There are more discussions on Perl being dead, than Ruby being alive.

You can’t have it all at once. Hopefully one day there’s an alternative OS that’s not owned by and American company, but that shouldn’t stop us from building other things in the meantime

We already have Sailfish OS but no one is using it.

I have a Jolla phone preorder. I'll become a user next year (probably)

Years ago I wrote article on this topic: https://www.notonlycode.org/why-python-has-won/

In short (all below is my opinion): it was popular in academia and got some corporate adoption, so when ML exploded in popularity it was a natural choice as the scripting language for ML tooling. On top of that it’s easy to pick up as a language, and it’s a general purpose language - there are lots of scientific tools like pandas written in it, there are web frameworks, etc.

Perl was too quirky for wide adoption and it stopped developing (Raku/Perl 6 took to long to develop), PHP was focused purely on the web, similarly JS. Ruby could have won, I like it more than Python, but outside of Japan it’s also mostly been associated with web development (because of Rails), it also lacked libraries that Python already had.

> Ruby could have won,

Seems unlikely. Its got its own fair share of Perl-inspired quirks.