A clear signal showed up on GitHub Trending today: agent skills are having a moment.

On the daily chart, obra/superpowers reached rank 2 with an agentic skills framework and software development methodology. K-Dense-AI/scientific-agent-skills reached rank 3 with ready-to-use skills for research, science, engineering, analysis, finance, and writing. The monthly chart is even louder: mattpocock/skills, multica-ai/andrej-karpathy-skills, ComposioHQ/awesome-codex-skills, addyosmani/agent-skills, NousResearch/hermes-agent, zilliztech/claude-context, and rohitg00/agentmemory all appear in the same cluster.

This is not just another batch of prompt templates.

I think it marks the second phase of AI coding.

The first phase was prompts: how you ask, how the model answers.

The second phase is skills: you give the agent a reusable way of working, so it can call the right process at the right time, check itself, and keep moving.

A prompt is a one-off conversation. A skill is an asset.

What is a Skill?

Different projects use different names, but the core idea is similar: take human engineering experience, workflows, constraints, checklists, and commands, then package them into units an agent can execute.

A useful skill usually answers a few questions:

  • when should this be used, such as planning, code review, debugging, testing, or release work;
  • what principles should guide the work, such as keep changes small, avoid speculative abstractions, and verify results;
  • what concrete steps should the agent follow, including which files to inspect and which commands to run;
  • what common traps should it avoid.

That sounds plain, but it matters. The biggest problem with coding agents is often not that they cannot write code. It is that they do not have stable working habits. One day they write tests carefully. The next day they skip them. In one repo they read the README first. In another repo they start editing immediately. This time they make a surgical change. Next time they rewrite half the project because they got excited.

Skills are an attempt to move those habits out of a human’s head and into a form the agent can repeatedly use.

CLAUDE.md, Claude Skills, Codex Skills: what is the difference?

The repos on today’s chart can feel confusing at first. I would separate them by layer.

1. CLAUDE.md: the project handbook for an AI coworker

A CLAUDE.md file is closest to an onboarding guide for an AI teammate.

The multica-ai/andrej-karpathy-skills repo is centered on a CLAUDE.md file with behavioral guidelines meant to reduce common LLM coding mistakes: think before coding, prefer simple solutions, make surgical changes, define success criteria, and verify the result.

I like this category because it is cheap, direct, and immediately useful. You do not need a complicated framework. If you write down the key conventions of a project, the agent’s behavior usually becomes more predictable.

But it has limits. A CLAUDE.md file is a global rulebook. It is good for telling the agent “this is how we work in this repo.” If you want code review, TDD, release work, debugging, and documentation to become separate callable workflows, one giant file will eventually become messy.

2. Claude Code Skills: reusable task modules

Claude Code Skills are closer to modular capability packs. A skill can cover a specific scenario, with its own instructions, steps, constraints, and sometimes scripts. The agent does not need to load every rule into context all the time. It can load the relevant skill when the task calls for it.

That matters.

Context is not a trash can. If you dump every piece of advice into it, the agent becomes more confused, not more competent. Skills point toward a cleaner structure: project-level rules go into CLAUDE.md, reusable workflows become skills, and temporary decisions stay in the current conversation.

That looks much more maintainable.

3. Codex Skills: the same need in another agent ecosystem

ComposioHQ/awesome-codex-skills represents the same pattern for Codex.

That tells us skills are not a Claude Code-only feature. Every coding agent that can read files, modify code, and run commands needs a working method. Otherwise, stronger models simply make mistakes faster.

A powerful model is like a car with more horsepower. Skills are the steering wheel, brakes, and driving habits. If you only chase horsepower, you eventually hit a wall.

4. Agent Skills: packaged senior-engineering process

addyosmani/agent-skills is explicit about its goal: production-grade engineering skills for AI coding agents. It maps the development lifecycle into commands such as /spec, /plan, /build, /test, /review, /code-simplify, and /ship, each with its own principle.

The point is not to make the agent produce more code. The point is to make it follow a software engineering rhythm: define the work, plan it, implement incrementally, test it, review it, simplify it, and ship it.

That sounds like common sense. Common sense is exactly what agents forget first.

What I learned from reading these repos

I see three changes behind the hype.

First, developers are no longer satisfied with “it can generate code”

Early AI coding demos were mostly about whether a model could produce a feature in one shot. Now the questions are different: can it make fewer mistakes, follow repo conventions, verify its work, and avoid getting lost in a large codebase?

That is the line between a toy and a tool.

A demo can run on vibes. A real project runs on process.

The README for mattpocock/skills says these are skills he uses every day for real engineering, not vibe coding. That phrasing is sharp, and I think it lands because developers are losing patience with agents that simply produce a pile of plausible code.

Second, engineering experience is becoming productized

In the past, many team habits moved through people: a senior engineer pointed out missing tests in review, a tech lead pushed back on a premature abstraction, and a production incident turned into a new checklist item.

Now those habits can be written into skills.

That is more important than it sounds. It makes engineering taste more repeatable. A new agent does not have to learn by luck. It can know from day one how the team scopes tasks, writes tests, handles risky changes, and decides that something is actually done.

There is a catch: the team has to write the knowledge down. Many teams do not have an AI problem. They have a “new humans also cannot understand our project rules” problem. AI just makes that visible.

Third, the competition is shifting from model choice to workflow

Model quality still matters. But when models get close enough, the difference moves into workflow.

The team with better context management repeats itself less. The team with better skills gets less rework. The team with better verification can trust agents with larger tasks. The team that connects permissions, tools, tests, and review gets closer to real automation.

That is also why claude-context and agentmemory are trending near the skills repos. Skills answer “how should the agent work?” Context and memory answer “what does the agent know?” and “what does it remember?” Together, they make the agent feel less like an intern who wakes up with amnesia every morning.

How should individual developers use this?

My advice is simple: do not start by installing a giant bundle of fancy skills. Start with the most painful repeated failure.

1. Write a project-level CLAUDE.md first

Put the practical repo rules in one place:

  • tech stack and startup commands;
  • test commands and common failure modes;
  • code style and directory conventions;
  • files the agent should not casually touch;
  • database, production, secrets, and permission boundaries;
  • checks required before a change is considered done.

Keep it short and concrete.

“Maintain high code quality” is useless. “After changing an API, update openapi.yaml and run npm run test:contract” is useful.

2. Turn repeated workflows into skills

If you keep telling the agent the same thing, it probably belongs in a skill.

For example:

  • debugging: reproduce first, write a failing test, fix the bug, run the relevant tests;
  • code review: read the requirement, inspect the diff, check security, compatibility, and test coverage;
  • blog writing: research sources, form a point of view, write bilingual drafts, verify the Hugo build;
  • release work: inspect changes, run tests, update the changelog, create the tag.

None of this is magic. The most useful skills are often just the things a senior engineer says when a junior tries to skip steps.

3. Maintain skills like code

Skills are not write-once documents.

Projects change. Commands change. Tools change. New traps appear. If a skill becomes stale, the agent will make old mistakes consistently and confidently. That is worse than having no skill at all.

So treat skills as code assets: version them, review them, update them after failures, and delete the ones that no longer help. Do not let them become another knowledge-base graveyard.

The traps are real too

I am bullish on skills, but I would not worship them.

First, skills do not replace engineering judgment. They can remind an agent to run checks, but they cannot guarantee that the design is right. Architecture, security, data migration, and permissions still need serious human review.

Second, too many skills can backfire. More rules mean more conflicts, and agents are very good at pretending they understood all of them. Good skills should be small, precise, and verifiable.

Third, do not copy someone else’s skills wholesale. Matt Pocock, Addy Osmani, and Karpathy have useful instincts, but your project has its own constraints. Copying a huge pile of rules often ends up like forcing the agent into a suit that does not fit.

Fourth, writing skills exposes the real maturity of a team. If you cannot write a good skill, the problem may not be phrasing. The process itself may be unclear. That stings a little, but it is useful.

My take

Claude Code Skills are not just advanced prompt templates. They are workflow assets for the AI coding era.

In the future, I do not think the best AI coding teams will be defined only by whether they use Claude, Codex, Cursor, or something else. I would look at three things:

  • do they have clear project context;
  • do they have reusable task skills;
  • do they enforce quality gates and verification.

Without those, an agent is just a fast temporary worker. With them, it starts to become an asynchronous teammate you can actually trust.

Today’s GitHub Trending chart amplified that signal: the valuable thing is not the perfect one-line prompt. It is the judgment, process, and taste that a team has built over years.

Turning those into skills may be the most boring and useful next step in AI coding.

References