JSDev Space published a guide to 30 AI agent skills on October 23, 2026, covering workflows including planning, debugging, code review, frontend design and browser automation. It includes installation examples and short descriptions that help developers connect a skill to a specific job.
The guide also supplies an important warning about its ranking: GitHub stars belong to repositories, not individual skills. Several entries inherit the same repository’s popularity, and most of the listed counts are provisional figures that the guide says need a fresh GitHub API audit.
That makes the collection more useful as an onboarding map than a quality leaderboard. My view is that its strongest contribution is the combination of task descriptions, installation commands and a warning to inspect instructions and scripts before giving an agent access to sensitive resources.
Use the List to Identify a Missing Workflow
An agent skill is typically a package of instructions and supporting resources that guides an agent through a particular task. It can shape how the agent plans work, investigates a bug or checks a result. It is not a new model, and adding one does not guarantee correct output.
The guide’s early entries illustrate several distinct ways to organize development work:
| Workflow need | Example skill | Intended role in the guide |
|---|---|---|
| Clarify an idea | brainstorming | Ask focused questions before implementation |
| Prepare implementation | writing-plans | Create steps with relevant files and checks |
| Investigate a defect | systematic-debugging | Begin with reproduction and structured investigation |
| Check completion | verification-before-completion | Prompt verification before declaring success |
| Continue work across agents | handoff | Record decisions, progress and next steps |
These are the guide’s descriptions, not independently measured improvements. They still provide a useful way to choose a starting point: identify the step your current agent workflow handles poorly.
For example, an agent that starts editing before requirements are clear presents a different problem from one that makes plausible changes without checking them. A planning skill addresses the first gap; a verification-oriented skill targets the second.
I’d start with one recurring failure and one relevant skill. Adding several overlapping planning, implementation and review instructions at once makes it harder to tell which instruction is helping, which is redundant and which might conflict with your project’s conventions.
Repository Stars Cannot Rank Individual Skills
The guide states the central measurement problem plainly: “GitHub awards stars to repositories, not to the skills inside them.”
Its first six entries all come from obra/superpowers. Each therefore carries the same approximate repository-level star count, despite covering different jobs: brainstorming, executing plans, coordinating subagents, debugging, verification and writing plans.
Those are six candidate workflows sharing one popularity measurement. The number cannot reveal which skill attracted attention, which is used most often or which performs best on a particular task. Even a perfectly current count would retain that limitation.
A comparison with the Git of Anton skills tracker shows a separate problem: published snapshots can disagree.
| Published page | Displayed stars for obra/superpowers | Measurement caveat |
|---|---|---|
| JSDev Space guide | Approximately 304,000 | Cites a third-party snapshot dated October 23, 2026 |
| Git of Anton tracker | 306,000 | Displays repository stars and weekly growth figures |
The difference is not evidence of a verified growth rate between two known observation times. The guide identifies a date for its cited snapshot; the opened tracker page does not establish a matching collection time for this comparison.
Git of Anton also explicitly ranks skills using the stars of their underlying repositories and limits its display to at most three skills per repository. That produces a different selection from a guide that includes six entries from one project. Position can therefore change with the directory’s selection rules, even before anyone assesses the skills themselves.
Refreshing the figures would improve their currency. It would not turn them into skill-level usage data, maintenance evidence or safety scores. Stars can help developers discover a project worth examining; the documentation and contents must answer whether a particular skill fits the job.
List Available Skills Before Choosing an Installer
The guide provides a discovery command for repositories compatible with the Skills CLI:
npx skills add obra/superpowers --list
This example asks the CLI to list the skills available from obra/superpowers. It is useful for checking the available names before selecting one.
The corresponding installation example for the guide’s debugging skill is:
npx skills add obra/superpowers --skill systematic-debugging
Here, the repository identifies the collection, while --skill selects the named skill. These commands reproduce the guide’s documented pattern; they have not been executed for this article.
The qualification matters: the guide says some projects use their own installers or plugin systems. A repository appearing in a collection is not enough to establish that it supports this installation route.
The examples also do not pin a CLI version. Check the repository’s current setup instructions and supported agent environment before proceeding. Listing available skills helps with discovery, but it is not a review of the instructions or scripts you may subsequently install.
Inspect Instructions Before Granting Access
The guide advises readers to review repository documentation, SKILL.md files and scripts before granting an agent access to files, a shell, a browser or credentials.
That warning deserves as much attention as the installation command. Instructions can influence how an agent uses tools it already has. A mostly Markdown package can still change which files an agent reads, which commands it chooses or when it attempts an external action.
A practical inspection should cover three layers:
- Repository documentation: Confirm the intended use, supported setup, dependencies and installation method.
SKILL.md: Check when the skill activates, what workflow it prescribes and whether its instructions fit your project’s boundaries.- Supporting scripts: Examine commands, file writes, network destinations and any requests for secrets or additional permissions.
Those are inspection targets, not findings that the listed projects contain unsafe behavior. This article analyzes published documentation; it is not an execution test or security audit of the skills.
Frequently Asked Questions
3 questions
1Can Every GitHub Repository Be Installed With the Skills CLI?
No. The guide says some projects use their own installers or plugin systems. Check the repository’s documentation before using its example commands.
