The 2,028-skill catalog solves discovery, not judgment
The current v16.1.0 catalog contains 2,028 reusable instruction sets and packages them for Codex, Claude Code, Cursor, Gemini CLI, Antigravity, and several other clients. The repository also includes specialized plugins, role-based bundles, ordered workflows, a browser-local Workbench, and AAS Core. That breadth is useful when a team has accumulated skills from several sources and wants one place to search them. It is also the first warning: this is a distribution system for other people's instructions, not a single method written in one voice.
The scale is physical as well as editorial. Our checkout at commit 50a74ca contained 20,986 files, about 573,234 source lines, and used 269.9 MB. Browsing the tree by hand is a poor default at that size. The generated catalog, stable skill manifest, filters, and focused plugins make the collection usable. Teams should begin with a narrow task and exact skill IDs. Installing the whole library gives an agent far more text and authority cues to sort through than most jobs need.
AAS Core records a choice but does not make it
AAS Core's local MCP exposes 7 read-only tools for catalog search, stack composition, inspection, comparison, and selection evidence. The CLI can persist aas-stack.json, validate it, and write an immutable plan. Workbench reviews those artifacts in the browser. This turns a conversational choice into inspectable state without letting the MCP change the target project. The manifest supports as many as 128 selected skills, though the documentation wisely avoids claiming that a large stack is a good stack.
The trust boundary is unusually explicit. Search has no relevance score, recommendation, or preferred order. Codex or Claude decides what fits, while Core checks identities and structure. It does not certify compatibility, setup correctness, semantic coverage, or operational safety. That limitation is easy to miss because the surrounding tooling looks formal. A valid manifest proves that named catalog entries exist and that the artifact is well formed. Even a 128-skill manifest does not prove that the agent picked sensible instructions for a multi-service application.
What happened when we ran it
Our sandbox install succeeded in 7 seconds, added 11 npm packages, and occupied 5 MB. The build failed after 6 seconds during the first validation step. The log shows the Node wrapper launching tools/scripts/validate_skills.py, then Python stopping at import yaml with ModuleNotFoundError: No module named 'yaml'. That is the complete evidence from the failing tail. We cannot say whether another undocumented package would have been needed later because the build never reached the remaining catalog and synchronization steps.
The test command ran for the full 900-second cap. Node's test reporter showed 12 passed and 0 failed out of 12 before the timeout, including checks that runtime promotion rejects unsafe cache-parent permissions. Since the command did not finish, those passes do not establish that the complete suite passed. The npm audit was cleaner: it reported 0 known vulnerabilities at every listed severity. These results came from an unprivileged Node 22 Debian container with 3 CPUs, 8 GB of RAM, and no secrets.
The audit checks 8 signals but cannot certify safety
The repository's audit checks 8 signal types, including commands, network access, credentials, privileged actions, destructive operations, symlinks, binaries, and filesystem use. Direct installation copies instructions without executing their commands, but the security boundary changes when an agent later follows them. The security guide tells users to review the exact revision and warns that automated checks can miss indirect behavior. The report is useful triage, especially in a collection that openly includes critical-risk and authorized offensive-security material. It is not a safety certificate.
Antigravity gets a specific guard because loading too much can exhaust context, slow startup, cause truncation errors, or enter a crash loop. The bare installer therefore requires selectors, filters, or an explicit --all override for that target. Our checkout's 20,986 files make the caution believable. Other clients retain broader legacy install behavior, so the operator has to supply the restraint. The safer path is a focused plugin or a reviewed list of exact IDs, followed by a dry run and the repository's own audit command.
v16.1.0 is active, while apply remains experimental
GitHub shows a last push and the v16.1.0 release on August 25, 2026. The repository's open count was 4, and the four open entries returned by the recent-activity request were pull requests adding more skills. That combination shows active maintenance more convincingly than the release tag alone. The repository also has 9 CI workflow files. It has no Dockerfile and no conventional tests directory, while its tests live under tooling paths and its release notes describe a much larger internal validation matrix than our capped run completed.
The 7-second npm install makes selected use approachable, but AAS Core still labels itself an agent-first preview. Its supported path ends after read-only search, composition, validation, evidence, and plan review. Apply and recovery require experimental opt-in. That is a reasonable boundary for a system that can place instructions into coding agents, but buyers should respect it. Start with one focused plugin or a few reviewed skills. If you need the project to choose the right instructions or prove they are safe, its own documentation says it cannot do either.