AAS Core will validate 128 skill IDs and tell you nothing about fit

A green validation says nothing about whether a skill fits

The project's own warning is the first thing to read, because it bounds everything else. Structural and identity validity, which is what the supported Core path checks, does not certify semantic fit, compatibility, setup correctness, operational safety, or safety to apply. Add to that a flat refusal: Core does not rank or recommend skills, so nothing in the pipeline will tell you which of the 2,917+ catalog entries belongs in your project. The agent picks, the validator checks shape, a human decides. Two consequences follow for anyone wiring this into a workflow. A passing validation is not a safety review, and treating it as one puts unvetted third-party instructions one command away from a production agent. And because ranking is out of scope by design, the quality of the selection is bounded by how well the agent was told to inspect your project, which is the step with no tooling behind it.

compose_stack stays in memory while aas-stack.json becomes the record

The read-only tool in this pipeline is compose_stack, which validates the chosen IDs and structure in memory. Persistence is a separate step: a client, or the aas CLI, can write aas-stack.json plus optional selection evidence, and that file is what `aas stack validate` reads back. Planning sits one step beyond, where `aas stack plan` writes an immutable preview. The manifest carries a technical maximum of 128 skills, which is a ceiling on how much one selection can hold rather than advice about how much context your agent can absorb. The immutability is the part worth relying on. A plan that cannot be rewritten after the fact is a reviewable artifact: you can diff it, attach it to a pull request, and point at the exact list that was approved. The cost is that changing the selection means producing a new plan rather than editing the old one.

No single command takes you from a plan to installed skills

There are two install routes and the README is explicit that they do not connect. One configures the local MCP so Codex or Claude can search the catalog, with the first configuration command previewing its change and returning an approval digest. The other is the direct installer, which takes explicit IDs and writes into a host's skill directory:

npm exec --yes --ignore-scripts [email protected] -- \
  agentic-awesome-skills --release 18.10.0 --path .agents/skills \
  --skills brainstorming,systematic-debugging --dry-run

The direct installer does not consume or apply a Core plan, and `aas stack install-preview` only prepares a dry-run preview rather than applying a plan either. So the handoff from a reviewed selection to files on disk is a person copying IDs, which is the step a workflow diagram tends to hide. Consequence for a team: your approval record and your installed set can drift apart with no error raised anywhere, so diff what landed in the skill directory against the manifest you signed off on.

npm exec pins the version and refuses to run install scripts

Both documented commands share one invocation shape: npm exec with --yes so the package is fetched without a prompt, --ignore-scripts so no lifecycle hook runs during install, and an exact --package version instead of a range. The direct line also carries --release 20.4.0 and a --path such as .agents/skills, so the version appears twice and the destination is explicit rather than inferred. Three properties come out of that. The version is fixed in the command itself, so a behaviour change is a visible edit to a line in your scripts rather than a surprise on a schedule. Ignoring install scripts means nothing executes at fetch time, which matters for a package whose purpose is handing instructions to agents. And since the package is not written into your project, the same command on a laptop and on CI resolves the same version for as long as the registry serves that tag.

Every Python validator is launched through a Node shim

Python is the primary language of this repository, and yet every tool in package.json starts with node tools/scripts/run-python.js followed by a Python file. One entry shows the shape:

"audit:skills": "node tools/scripts/run-python.js tools/scripts/audit_skills.py"

The same shim runs skill validation, reference validation, plugin compatibility, index generation and README updating, each carrying its own mode flag such as --strict or --check. One entry in the list is a shell script rather than Python, which is the exception to know about when you write a wrapper around it:

"validate:glossary": "bash scripts/validate-glossary.sh",

For a contributor that shape means a checkout needs both a Node runtime and a Python interpreter. For a reader of the catalog the script list shows tooling that checks and repairs the catalog: it includes fixers for missing sections, missing metadata, truncated descriptions and synthetic sections, alongside the strict mode that turns findings into failures.

The GitHub repository is canonical, the Workbench reads in browser memory

Two surfaces sit beside the repository and neither replaces it. The README states that the GitHub repository is canonical, with the hosted catalog and the browser-local Workbench as companion discovery and review surfaces, and the Workbench reviews stack and plan artifacts in browser memory without accessing your filesystem. That boundary is sensible for reading a manifest, and it also means a plan gets reviewed somewhere other than where it will be applied, which is worth remembering before you paste selection evidence into a hosted page. The same paragraph carries a disclaimer about names: this is an independent community project, not affiliated with or endorsed by Google, and names such as Gemini or Antigravity describe compatibility and install targets rather than authorship. One versioning trap closes the section: the README tracks main, features under Unreleased need a later release, and the Core guide is pinned to the v20.4.0 tag.

2,602 playbooks, nightly releases, and skills that carry advisories

Scale and cadence are the two facts that shape the decision. The catalog holds 2,917+ installable SKILL.md playbooks, and the registry sync line at the top of the README carries skills=2917 against version 20.4.0. Releases landed every couple of days, v20.2.0 on 2026-10-29, v20.3.0 on 2026-10-31 and v20.4.0 on 2026-11-02. That is the honest shape of the risk here. A playbook is a third-party set of instructions for an agent. Snyk is credited as security tooling support and a .snyk file sits at the repository root. An update can change what an already installed skill tells your agent to do, which is why the 128-skill ceiling and the immutable plan are worth the extra step.

Editorial conclusion

Adopt Agentic Awesome Skills if you want a searchable local catalog with a plan artifact you can put in a pull request, and if your team is prepared to read each SKILL.md before it reaches an agent. Do not adopt it as a way to get vetted instructions, because Core ranks nothing, certifies nothing about fit, and leaves apply and recovery outside its supported path. Verify three things before the first install: that the plan you reviewed matches the files that landed in your skill directory, that the skill IDs came from the pinned version 20.4.0 rather than from whatever main carried at the time, and that the repository's last push on 2026-11-02 and its frequent releases still leave you a version you can reproduce.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes