wondelai/skills ships 65 agent skills in four formats, and its own description is two journeys out of date

Three counts, and only two of them add up

The number of skills in this project depends on which part of it you read.

The repository description says fifty skills and twelve guided journeys. The readme's opening paragraph says sixty-five agent skills, made of fifty-one expert frameworks plus fourteen metaskills. Fifty-one plus fourteen is sixty-five, so the readme is internally consistent. Fifty plus twelve is sixty-two, which is neither sixty-five nor fifty-one plus fourteen.

So the description is behind the readme by one framework and two journeys, and the two numbers a visitor sees first are the wrong ones. This is the kind of drift that accumulates quietly in a project that adds skills in batches, and here it is visible in the two places a newcomer is most likely to look.

The release history is consistent with the readme rather than the description. The three most recent tags are one skill, then two skills, then a packaging format, which is roughly a skill or two per minor version. The versions are spaced days apart, not months.

What is not in dispute is the shape: expert frameworks that give the agent a method, and metaskills that orchestrate those frameworks step by step. That split is what the rest of the project is organised around.

Four install formats, three generated from one file, one with real copies

The distribution design is the most interesting engineering in the repository, and it is worth understanding before you install anything.

There are four routes. The first is a plugin marketplace for one agent, added by a slash command and then installed collection by collection. The second is a general installer that takes either the whole repository or one skill path, run through a package runner. The third is a second coding agent, which shares the same open skill file format and which auto-discovers a marketplace inside a clone, so a user with a git checkout gets the skills with no install step at all and manages them from a menu. The fourth is an open plugin specification at version 1.0.0, where a client is pointed at a plugin directory.

Three of those four are generated. The readme is explicit that the manifests for the second and fourth formats, and for the third, are produced by a single shell script from one marketplace manifest file, which it names as the single source of truth. That is a good design: change a collection once and three clients see it.

The fourth format is the exception, and this is the detail to notice. Each collection directory in it is self-contained, with a root manifest plus real copies of its skills underneath. Not references, not symlinks, copies. So the repository holds the same skill content in two places, and a fork has to keep both in step. There is also an all-in-one bundle holding every skill, which is a third copy in effect.

The readme names eight agent clients as targets, and the per-agent configuration directories at the root match that list one for one.

The last install command names a different marketplace

The marketplace installation block is the first thing a new user copies, and its last line is wrong.

# Add the marketplace
/plugin marketplace add wondelai/skills

# Install plugin collections
/plugin install product-strategy@wondelai-skills      # Jobs to Be Done, Negotiation, Mom Test
/plugin install ux-design@wondelai-skills             # Refactoring UI, iOS HIG, UX Heuristics, Hooked, Improve Retention, Web Typography, Top Design, Design of Everyday Things, Lean UX, Microinteractions, Steve Jobs Design Review
/plugin install marketing-cro@wondelai-skills         # CRO Methodology, StoryBrand, Scorecard Marketing, Contagious, 1-Page Marketing
/plugin install sales-influence@wondela

The block has four install commands. Three of them end with the marketplace name spelled out in full. The fourth ends with a shorter form of it, missing the suffix the other three carry. Copying that line as printed will not resolve to the collection the three above it came from.

The general installer block has a different problem. Its last example is cut off partway through a skill name, missing the final letters, and its all-skills form is a single flag pair on one path:

npx skills add wondelai/skills --all --global

The same skill appears complete in the table further down, so the fix is to copy it from there rather than from the list.

Neither is fatal, and both are exactly the kind of thing that only survives review by a reader who runs the commands. The blocks are prose-formatted examples rather than tested ones, and there is no manifest in the repository to check them against, because the only executable file in the whole tree is the script that generates the other manifests.

It is worth naming that last point plainly, since it explains the other two. With one shell script, four install formats, sixty-five skills and no test directory, the copy-paste path is the documentation. So the documentation has to be read rather than trusted.

Guided journeys keep their state in your project's docs folder

This is the part of the project with real behaviour behind it, and it is also the part with consequences you should decide about in advance.

A metaskill does not answer in one pass. It asks you its decision questions phase by phase, and it keeps its state in the docs folder of your project. The stated benefit is that a journey survives across sessions, which is true and is the whole point: you can stop halfway through an architecture exercise, come back tomorrow, and the journey knows where it was.

The mechanism is the finding. State lives as files in a directory you already use for documentation, inside the repository you are working in. So the tool writes to your project tree, and the files that make the journey resumable are the same files a reader would expect to be prose.

That has two practical implications. First, decide where you want this before you start, because the location is not configurable in anything the readme shows. Second, treat those files as output rather than as documentation you wrote, and check them into version control deliberately rather than discovering them in a diff. A repository whose own readme ends with a list of skill directories is not a repository that expects stray state files in its docs folder.

The alternative design would have put this in a tool-owned cache directory, which would be less convenient across machines and less visible. This one is a deliberate trade and the readme states it plainly.

Every bookshop link in the attribution table carries the project's own tag

The readme has a table of skills with a column headed Based On, and that column is where the provenance lives. It is also where something else lives.

Each row that links to a bookshop carries a query parameter at the end of the URL identifying an associate account. Every such link in the table carries the same one. The links that do not go through a bookshop, which means the platform interface guidelines, the usability heuristics article and a design reference site, carry no such parameter.

So the column that credits Clayton Christensen, Nir Eyal, Donald Miller, BJ Fogg, Daniel Priestley, Steve Krug, Jason Santa Maria and the authors of the conversion methodology book is simultaneously the column that earns the project a commission on buying those books.

That is legal and common, and it is also a conflict of interest in a table whose purpose is attribution. It matters more here than it would in a blog post, because a reader who installs the skills is being pointed at the same list twice: once to learn the framework, once to buy the book. The readme does not disclose the parameter anywhere in the visible text.

One attribution is worth noting as a different case. The platform guidelines row names a company rather than an author and links to a free developer page, and the heuristics row credits two separate sources, a book and an article, for one skill.

The directories are named after books that are still in copyright

The repository's top level is one directory per skill, and the naming convention is legible once you see it. The guided journeys carry a verb prefix: there are create, grow and improve families, covering applications, businesses, websites, code quality and retention. The expert frameworks carry no prefix and are named after their source.

The source names are book titles, and several are still in copyright. There is a directory named after the book on everyday things, one named after the chasm-crossing book, one after the made-to-stick book, one after the contagious book, one named for clean code, one for clean architecture, one for domain-driven design, one for high output management, one for good strategy and bad strategy, one for the blue ocean book, one for the hundred-million-offers book, one for the systems-design reference, and one named after a software consultancy. There is also one named after the interview methodology that shares its name with a possessive pronoun, which is the least subtle of the set.

So the packaging and the documentation both put commercial book titles in the directory names, while the attribution column links to the authors and the publishers. That combination is the interesting part: the project is a redistribution of methods, not of text, and it is careful enough to credit every source and specific about which ones are style guides rather than books.

What the visible tree does not show is a per-directory licence or attribution file. Each skill's own directory might carry one; the top-level listing does not tell you either way.

Seven agent directories, and one shell script doing all the work

The repository's primary language is reported as shell, and that is an accurate description of the codebase rather than a quirk of detection. There is no package manifest, no requirements file, no lock file and no test directory. The one executable is the script that generates the manifests for three of the four distribution formats.

The rest of the root is per-agent configuration. There is a neutral directory for agent skills, a plugin manifest directory for the first client, a Claude configuration directory and an agent instruction file, a Cursor directory and a separate cursor rules file, a pi directory, a Windsurf directory, and a worktree include file. That is eight configuration surfaces for eight named clients, and it means supporting a new host is a matter of adding a directory rather than writing code.

The recent release titles are the clearest statement of the project's cadence. One release adds a technical documentation skill based on a developer documentation style guide. The one before adds two optimisation skills, one for conversion and one for architecture. The one before that adds support for the open plugin format. So the version number tracks content additions rather than breaking changes, and a version bump is not a signal that anything in the existing skills changed behaviour.

The homepage is a browsable index of the skills, separate from the repository, so the readme functions as a summary of a catalogue that lives somewhere else.

Editorial conclusion

This is worth installing if you want a working set of product and design frameworks available inside your agent rather than as notes you have to paste in, because the guided journeys are the part with real engineering in them: they persist their state, they ask questions in phases, and they survive a session boundary. Three things to weigh first. The metaskills write into your project's docs directory, so decide where you want that before you start a journey, because the state files are the mechanism rather than a side effect. The collections are duplicated physically into one of the four formats, so if you fork this, you have four places to change a skill rather than one. And the attribution table that credits the books' authors also carries a commercial link on every bookshop entry, which is worth knowing before you point colleagues at it as a neutral framework collection.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wondelai/skills on GitHub