sickn33/agentic-awesome-skills: AAS Core Turns Agent Skill Selection Into a Reviewable Plan

What AAS Core Solves, and Who It Is Actually For

The repository is a catalog of reusable SKILL.md playbooks, and the README puts the count at 2,098+ skills spanning development, testing, security, infrastructure, product and marketing. That breadth is also the problem it creates: a coding agent asked to improve a project has no reliable way to know which of two thousand playbooks apply, and a human scrolling the catalog has the same trouble. AAS Core is the answer the project settled on, and it is a narrow one. Codex or Claude inspects your project, searches the complete local catalog, and chooses exact skill IDs. AAS itself does not rank, recommend, exclude or hide anything. The README states this plainly: "Core does not rank, recommend, exclude, or hide skills."

The intended user is a team that already has an agent in the loop and wants the resulting decision to be inspectable. The output of a session is aas-stack.json, a manifest of agent-selected IDs, plus an optional evidence sidecar. That is a different artifact class from a one-shot installer: it can be diffed, reviewed in a browser, and re-validated later. The project is explicit that it is a community project and not affiliated with Google, and that the GitHub repository is canonical while the hosted catalog and Workbench are companion surfaces rather than a hosted control plane.

How the Agent, the MCP Server and the CLI Split the Work

The README lays out the data flow as a text diagram, and the ordering matters. A project is inspected by Codex or Claude, not by AAS. The agent searches and reads the complete local catalog, reaching it through a local stdio MCP server that is read-only. The agent then chooses exact skill IDs. Only at that point does AAS enter: the compose_stack tool validates the selection in memory, still read-only. A client or the aas CLI persists aas-stack.json and optional evidence into an artifact-dir, and the CLI runs validate and an immutable plan preview. Human review can happen in Workbench, which the README describes as importing stack and plan JSON in browser memory without filesystem access or installation.

The MCP surface is small and named in the README: search_skills, get_skill, compose_stack, inspect_stack, diff_stack, plus read-only export_selection_evidence and inspect_selection_evidence. Two design choices stand out. First, validation is structural and identity-based. The README carries an explicit warning that structural and identity validity does not certify semantic fit, compatibility, setup correctness, operational safety, or safety to apply. Second, manifests have a technical maximum of 128 skills, which is a real ceiling for anyone tempted to select the whole catalog.

MCP session instructions push the agent toward coverage rather than a shortlist: evaluate the full project surface from architecture and data through testing, security, deployment and maintenance, search each applicable capability, compare candidates, and either cover it with a non-redundant skill or report a catalog gap. The README is honest that Core records and validates the selection but does not certify semantic completeness.

Installing AAS Core and Producing a First Stack

The README points to the published npm package as the current release and to the AAS Core guide under docs/users/aas-core.md for the Codex and Claude setup model and the CLI lifecycle. The repository root also carries START_APP.bat, and package.json defines the validation scripts the project itself runs over the catalog, including npm run validate and a stricter npm run validate:strict.

The package.json name is agentic-awesome-skills, and the aasCore block records includedFromMajor as 15 with status agent-first-preview. Installing the package is the starting point:

npm install agentic-awesome-skills

The README does not print the exact MCP registration snippet, so the authoritative source for wiring the local stdio server into Codex or Claude is the AAS Core guide rather than this article. Once the server is attached, the agent searches the catalog and proposes IDs. The CLI side of the lifecycle is where the artifacts appear. According to the README, validation checks the proposal and the plan command produces an immutable, per-target plan without applying it:

aas stack validate
aas stack plan

What you should see is a validated manifest and a plan document, not changed target skills. The README states that stack validation and plan preview make no target skill changes, and that a client or the CLI writes aas-stack.json and the separate aas-selection-evidence.json sidecar into an artifact-dir. If you want the project's own catalog checks rather than stack checks, the package scripts run them:

npm run validate
npm run audit:skills

Where the Preview Status Bites: Apply, Recovery and Semantic Fit

The status table in the README is the most useful page of the project. Catalog search and inspection are supported preview. Agent-owned composition is supported preview, with Core validating IDs and structure but not semantic suitability. Stack validation and plan preview are supported preview with no target skill changes. Workbench is browser-local review of stack and plan artifacts. Selection evidence is exported and inspected through MCP and CLI contracts, but the README notes it is not yet reviewed in Workbench. Apply and recovery are experimental, explicit opt-in, and outside the supported safety claim. Semantic suitability certification is not provided at all.

That last row is the limitation worth taking seriously. A plan that validates cleanly tells you the IDs exist and the manifest is well formed. It does not tell you the chosen skills will work together, that their setup instructions are correct, or that applying them is safe. The README repeats this warning in a callout rather than burying it, which is the right instinct. The practical consequence is that the human review step is not ceremony. It is the only semantic check in the pipeline.

The second constraint is the 128-skill manifest maximum. It is a technical bound, not a quality signal, and it means a stack covering every capability the agent identifies will eventually hit a wall. The third is the split between the supported path and the experimental one. Anyone reading "apply and recovery remain experimental and outside the supported preview path" should treat the project as a planner, not as a deployment tool, until that row changes.

How This Differs From a Plain Skill Installer

The obvious alternative is a direct installer: pick a plugin or bundle, run the install, and let the skills land in your agent's configuration. The repository still ships that path. The README describes specialized plugins packaging proven sets for web, security, data, docs, DevOps, QA, OSS and agent/MCP workflows, plus bundles, workflows, direct installers and the full catalog. Those are described as the content, curation, distribution and compatibility layers around AAS Core, not as competing products.

The difference is where the decision lives. A direct install commits the choice at install time and leaves no manifest describing why those skills and not others. AAS Core moves the choice to the agent, records it as aas-stack.json, and inserts validation and an immutable plan before anything changes. If you want a known-good curated set and you trust the curation, the plugin path is faster and has fewer moving parts. If you want to know which skills were selected for a specific repository and be able to re-check that selection later, the manifest and plan are the point. The two paths are not exclusive, but they answer different questions.

Maintenance, Releases and the MIT Licence

The repository is not archived, and the last push was on 2026-08-28, which is recent enough that the release cadence is worth noting. Three releases landed inside four days: v16.1.0 on 2026-08-25, v16.2.0 on 2026-08-26, and v16.3.0 on 2026-08-28. The version strings carry themes rather than bare numbers, with v16.3.0 titled "Delegation Workflows and Reliable Operations" and v16.2.0 titled "Security Operations Expansion and Safer Integrations". That cadence cuts both ways. Fixes arrive quickly, and so does surface change, which matters when your workflow depends on a manifest schema and a set of MCP tool names.

There is a visible version skew to watch. The README registry line reports version 16.3.0 with 2,098 skills, the release notes stop at v16.3.0, and package.json declares version 17.2.0 with a description citing 2,121+ skills. The catalog counts in the README and in package.json do not agree, so treat any specific skill total as approximate. The licence is MIT, and the repository also carries a separate LICENSE-CONTENT file alongside LICENSE, which suggests the skill content may be licensed differently from the code. This is not legal advice; if you plan to redistribute or vendor the skill playbooks, read both files rather than assuming the MIT terms cover the catalog text.

Editorial conclusion

Adopt it if you already run Codex, Claude Code, Cursor or a similar agent and want skill selection to leave a reviewable artifact instead of an opaque install. Stay away if you need apply and recovery, since those remain experimental and outside the supported path, or if you want the tool to recommend skills for you, which it deliberately refuses to do. Verify first that your client can attach the local stdio MCP server, that aas stack validate accepts a manifest you wrote by hand, and that the 128-skill manifest ceiling fits your project.

Frequently asked questions

Official sources

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