Every Popular Claude Skills System, Compared — and the Simple Loop They All Share

Module objectives

• Understand why dozens of competing skill libraries appeared at once.
• See why their sheer popularity can be misleading for a beginner.

Skills are just natural-language prompts saved to a file, so anyone with a good process can package and share theirs. Over the last year, experienced builders did exactly that, and it became a land grab. Some repos are enormous: Everything Claude Code is cited at roughly 182,000 GitHub stars (a "star" is GitHub's bookmark/like button) in the source video, and Superpowers has climbed past 200,000 (per its repository, checked mid-2026; counts grow daily) — numbers some 20-year-old projects never reach.

The honest takeaway: huge star counts prove a library is popular, not that it is right for you. Popularity rewards being comprehensive and impressive — the opposite of what a beginner needs.

Here is what almost no one says out loud: after you read enough of these libraries, they rhyme. Strip the branding and most encode the same handful of moves — describe what you want, sketch it, plan it, build it in small pieces, then check it. Module 3 names that loop. For now, hold the suspicion that you do not need six libraries because they are six accents of one language.

---

Module objectives

• Match each popular system to the kind of work and team it suits.
• Borrow the one or two standout ideas from each without adopting the whole thing.

Addy Osmani (an engineering leader at Google with a widely-followed blog) advocates a clean, spec-first loop. A spec is just a written description of exactly what you want built — his thesis is that the spec, not the AI, is usually the bottleneck. His open-source agent-skills package turns that loop into slash commands: /spec, /plan, /build, /test, /review, /ship, and a /code-simplify clean-up pass. One full lap of development, captured as six or seven prompts. Matt Pocock — a well-known TypeScript educator and AI engineer — preaches the same shape with an emphasis on real simplicity. His skills overlap heavily with Osmani's: "diagnose" (mirrors specify), "grill-with-docs" (loads your project's domain knowledge so you stop re-explaining it each session), test-driven development, "vertical slice" (break a big job into one handleable chunk), and prototype (design the front end before any back end exists — the highest-leverage move, covered in Module 3).

Gary Tan, CEO of startup accelerator Y Combinator, ships a far more opinionated stack — a touch over-engineered to adopt wholesale, per the video's reviewer, but with one genuinely original skill: office-hours, where the agent grills you with six forcing questions about your startup idea, like a session with the YC partners. The point: now that anyone can build fast, knowing what to build is the real edge. Worth stealing even if you ignore the rest. BMAD sits at the enterprise end. It role-plays a whole team — business analyst, product manager, and senior architect working together (it calls this "party mode") to nail down requirements and follow a disciplined development life cycle. For a large organisation it earns its complexity; for a solo beginner building a weekend app, it is far more machinery than the job needs.

Everything Claude Code (credited in the video to a maintainer named "Afan") is the kitchen sink — the largest of the bunch. It reaches well beyond a build loop into agent memory, continuous learning, verification loops, sub-agent orchestration (one agent coordinating several helper agents), and a heavy security focus. Treat it as a reference for a maximalist setup, not a starter kit. Superpowers, built by Jesse Vincent (the obra/superpowers project), is the reviewer's favourite among the spec-based systems: lighter-weight, good results, and it runs across Claude Code, Cursor, Codex, Gemini CLI, and more. Its skills auto-activate when relevant — its test-driven-development skill kicks in when you start a feature. If you want a packaged system that does not feel bloated, start here.

You do not have to crown a winner. The next module shows the shared loop all of these implement — so you can start with zero libraries and add one only if you outgrow the built-in tools.

---

Module objectives

• Walk the Research → Prototype → Plan → Build → Test loop end to end.
• Run each step using features already built into your agent, no library installed.

Strip every library down and you get this iteration loop. The source video states it plainly: "Research, prototype, plan, build, and test — that's your iteration loop." Here it is, with the plain-English version of each step:

1. Research (ask first). Have the agent interview you before building. Literally tell it: "Ask me questions about what I want to build before writing anything." That turns the fuzzy idea in your head into clear requirements. Cursor has a dedicated Ask mode; in Claude Code the same thing happens inside Plan Mode, where the agent asks clarifying questions first. Not a fancy skill — one sentence.

1. Prototype (front end only). Ask the agent to mock up just the look of the app and skip the back-end plumbing. Fast trick: ask for an ASCII wireframe (a rough screen layout drawn with text characters) to agree on the shape in seconds. Then say: "Prototyping mode — front end only, placeholder data for anything from a server, wire up navigation, don't connect any back-end logic." Designing the interface first gives the agent a clearer target before the slower back-end work. Skip this for small features where you already know what you need.

1. Plan. Use the Plan Mode built into Claude Code, Codex, and Cursor. In Claude Code, press Shift+Tab to toggle into plan mode mid-session (or launch with claude --permission-mode plan), per the official docs. It is read-only — the agent studies your code, asks questions, and writes a plan as a markdown doc broken into phases with a to-do list and checkpoints. This is the headline change of the last year: the planning we used to hand-build with skills is now baked into the agents.

1. Build. Let the agent work the plan one small slice at a time, not the whole app at once. Small slices are easier to verify and far easier to fix when something breaks.

1. Test (with a human in the loop). The agent runs the basics — lint (an automatic style/error check) and a build to confirm the code compiles — and can drive a real browser to click through your app: Claude Code does this through Playwright, a browser-automation tool whose own Planner, Generator, and Healer agents Claude Code can drive to write and fix tests (overview). But automated testing is hit-and-miss, so the final check is always you — a quick smoke test, clicking through the main flow yourself.

Want test-driven development (writing the tests before the code)? You do not need a special skill — just say so during the Plan step and the agent will build tests as it goes.

After the loop, one bonus move pays off: a simplify/polish pass. Have a second agent (or a different model — build with one, review with another) read the finished code and suggest simplifications. This is what Addy Osmani's /code-simplify command automates. Fresh eyes catch the convoluted bits the building agent talked itself into.

---

Module objectives

• Understand why a personal, hand-grown skill set beats any off-the-shelf library long term.
• Learn the discipline that keeps a small skill library from becoming a liability.

Here is the conclusion that surprises people: the best skill system is the one you build yourself. You will not find it in someone else's repo, because it has to fit your codebase and your habits.

The practical path:

• Start with plain prompting. Run the Module 3 loop with the built-in Ask/Plan/Build modes. Lean on the agent's native ability and your own judgement first.
• Write a skill only when there's a real reason — the agent keeps repeating a mistake, or you have bespoke project knowledge you are tired of re-typing, and it is a step you repeat often.
• Keep skills tiny. A few short paragraphs. Long, over-detailed skills bloat the agent's limited working memory (its "context window") and confuse the model. Smaller is better.

A skill is just documentation, and documentation rots. We have all hit comments and docs that quietly went stale and started lying to us. Skills do the same: every one you add is something you must keep current, or it becomes a trap that misleads the model. So be ruthless — before adding a skill, ask whether it is genuinely necessary or just future confusion.

For teams, sharing matters too. Services like skills.sh from Vercel let you store, update, and share skills through private repositories so an organisation stays in sync. The traditional software development life cycle now has an agentic sibling: managing your harness and skills is part of the job, especially across multiple developers.

The differentiator going forward is not which famous library you cloned. It is the small, sharp, personal set of skills and habits you grow by working with your own code.

---

Closing Checklist

Before you go chasing the next trending skills repo, run this:

• [ ] Can you state your idea as a spec? If not, do the Research/Ask step first — let the agent interview you.
• [ ] Did you prototype the front end (or consciously skip it because the feature is simple)?
• [ ] Did you use built-in Plan Mode (press Shift+Tab in Claude Code) before letting the agent build?
• [ ] Are you building in small slices, verifying each one?
• [ ] Did you run a human smoke test, not just trust the automated checks?
• [ ] Did you do a polish pass to simplify the result?
• [ ] Before installing any library, did you try the loop with nothing installed? Add a skill only when a real, repeated pain demands it — and keep it to a few paragraphs.

Do that and you have captured the 90% every popular system shares — without losing a weekend comparing repos. The remaining 10% is the personal system you grow, one small skill at a time.

Source: "I Tried Every Popular Claude Skills System, Here is the Best" — verified against each system's repository and current Claude Code documentation (linked throughout).