autoskills: one command to install AI agent skills from a curated registry

The problem autoskills targets: agent skills as a per-project chore

AI coding agents get better when they are handed skill files that describe the conventions of the stack in front of them. The awkward part is distribution. A React and Tailwind project wants different guidance than a Flutter one, and copying skill files by hand across repositories invites drift. autoskills exists to collapse that step: the README states that it scans your project, detects your tech stack, and installs curated AI agent skills automatically. The target user is a developer who already runs an agent in a repository and does not want to hand-pick files for every new checkout. The project is published by midudev and its homepage is autoskills.sh. The repository itself is an Astro site plus packages, with a pnpm lockfile and a scripts directory, so the CLI is one piece of a larger site and registry setup rather than the whole repository.

How detection and installation actually work

The README lays out four steps. You run the command in your project root. Your package.json, Gradle files, and config files are scanned to detect technologies. The best matching skills are selected from what the README calls the audited autoskills registry. Only the selected skill files are downloaded and verified before being written locally. The security model is the part worth reading twice. autoskills does not install directly from random upstream repositories at runtime. Maintainers sync skills into a repository-local registry, scan them for prompt-injection and supply-chain risks, and record SHA-256 hashes in a manifest. At install time the CLI downloads only the skills your project needs, verifies every file against that manifest, and writes a skills-lock.json entry containing the installed source and bundle hash. Two consequences follow. First, the package stays small because skill content lives in the registry, not the tarball. Second, the freshness of any skill depends on how recently a maintainer synced it, since there is no live fetch from the original upstream project.

Installing autoskills and running a first dry run

There is no install step beyond invoking the package. The README's entire quickstart is one command, and Node.js >= 22 is the stated requirement. Run it from your project root, not from a subdirectory, because detection reads package.json, Gradle files, and config files at that level.

npx autoskills

The README documents a confirmation prompt, so expect to approve the plan before anything is written. To see the plan without touching the filesystem, pass --dry-run, which the options list describes as showing what would be installed without installing.

npx autoskills --dry-run

For scripted or CI use, -y or --yes skips that confirmation prompt. The options block lists exactly four flags, and nothing else is documented.

npx autoskills --yes

After a real run you should find a skills-lock.json in the project, holding the installed source and bundle hash for each skill. That file is the artifact to review in a pull request, since it is the record of what the CLI decided your stack needed.

The registry model is the main trade-off, not a footnote

Curating skills behind a manifest buys a real property: a skill cannot change under you between installs without the hash changing too. It also means autoskills cannot be faster than its maintainers. If a framework ships a new convention and no one has synced a skill for it, the CLI will not invent one, and there is no documented flag for pointing it at a custom or private registry. The detection surface is narrower than the supported-technology list suggests. The README names package.json, Gradle files, and config files as the inputs, so a project whose stack is expressed only in, say, a Cargo.toml or a go.mod has no documented path to a match, even though Go appears among the supported languages. The supported list is also explicitly a list of what it was built to work across, not a guarantee that every entry has a skill today. Nothing in the README covers rollback, so removing installed skills and their lock entries is an operation you would have to perform by hand.

Where autoskills fits next to hand-written agent instructions

The closest alternative is not another CLI but a checked-in AGENTS.md or a CLAUDE.md file that you write yourself. That approach is versioned with the code, reviewable line by line, and needs no network access at install time. It is also entirely manual: every repository gets its own copy, and consistency depends on discipline. autoskills inverts those properties. You get consistency across repositories that share a stack and a verified download path, at the cost of a dependency on a third party's registry and its sync cadence. A team that already maintains a good AGENTS.md gets little from autoskills; a team that keeps starting new repositories in the same three frameworks gets the repetition removed. The repository does ship an AGENTS.md at its top level, which is a fair signal that the maintainers treat checked-in agent instructions as normal practice rather than something to replace.

Maintenance, licence and what CC BY-NC 4.0 implies

The last push to the default branch was on 2026-07-19, so the repository is not archived and has been touched within the last two months. Releases are tagged more slowly: v0.3.6 landed on 2026-05-04, after v0.3.5 on 2026-05-03 and v0.3.4 on 2026-04-28. Anyone planning an upgrade should note that the CLI version they run through npx is not the same as the site repository's package.json, which is named autoskills-sh and carries version 0.0.1 with Astro, Tailwind and Geist as dependencies. That file describes the website, not the installer. The licence is listed as CC BY-NC 4.0, and the README links to the LICENSE file. NonCommercial is the clause to read carefully: it restricts commercial use, which is unusual for a developer tool and may matter if you plan to run autoskills inside a company workflow. This is a description of what the licence identifier says, not legal advice; read the LICENSE file and talk to whoever handles licensing where you work.

Editorial conclusion

Adopt autoskills if you work in the Node.js ecosystem on a stack it lists and you want agent skills that arrive verified against a manifest rather than pulled live from upstream repositories. Skip it if your stack is not in the supported list, if you are offline, or if you need per-skill selection and version pinning, which the documented options do not cover. Before relying on it, run npx autoskills --dry-run in a throwaway branch and read the resulting skills-lock.json to confirm which bundles and hashes the CLI intends to write.

Frequently asked questions

Official sources

1. Issues
2. midudev/autoskills on GitHub
3. Project website
4. README
5. Releases