opencode-skills-collection 4.0.5 → 4.0.6

package/bundled-skills/.antigravity-install-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "updatedAt": "2026-07-19T01:23:41.256Z",
+  "updatedAt": "2026-07-20T01:28:12.515Z",
   "entries": [
     "00-andruia-consultant",
     "007",
@@ -1162,6 +1162,7 @@
     "marketing-ideas",
     "marketing-plan",
     "marketing-psychology",
+    "markstream-install",
     "matematico-tao",
     "mathguard",
     "matplotlib",

package/bundled-skills/antigravity-maintainer-batch-release/SKILL.md

@@ -95,11 +95,12 @@ For AAS CLI, MCP, stack, catalog-cache, or Workbench changes:
 
 1. Use the current scripts declared in `package.json`; do not resurrect retired evaluator, benchmark, tuning-gold, transaction-fault, race, or frozen-matrix gates as routine prerequisites.
 2. Run the focused Core tests with `npm run test:aas-v1`, the catalog integrity check with `npm run check:aas-v1-catalog`, and the relevant Workbench tests/build when its contracts or copy change.
-3. Keep MCP local, offline, read-only, bounded, and non-mutating. The coding agent inspects the project and sends an explicit profile; MCP searches, inspects, recommends, and compares without scanning the repository or writing to it.
-4. Keep the supported public path at manifest validation and immutable plan preview. Planning may write only the requested plan artifact; it must not materialize skill payloads or AAS managed state in the target.
-5. Treat apply and recovery as experimental opt-ins outside the supported preview claim. Do not add apply/recovery, benchmark, fuzz, crash/race, or synthetic verifier work unless the user explicitly places it in scope.
-6. When the task asks for end-to-end client proof, use a real supported client that discovers and invokes the local AAS MCP tools; direct stdio probes and automated tests do not substitute for that evidence.
-7. Do not tag, publish npm, deploy Pages, or write real user MCP configuration without the separately required publication approval.
+3. Keep MCP local, offline, read-only, bounded, and non-mutating. The coding agent inspects the project, searches and reads the complete catalog, and chooses the exact skill IDs. MCP searches, reads, validates agent-owned composition, and compares without scanning the repository or writing to it. Core must not rank, recommend, exclude, or disable skills; metadata is informational only.
+4. Keep `aas-stack.json` free of Core selection policy. It pins catalog identity, targets, goals, and the exact IDs selected by the agent. `compose_stack` validates and records that selection; missing or cautionary metadata must never make a canonical skill unselectable or unusable.
+5. Keep the supported public path at manifest validation and immutable plan preview. Planning may write only the requested plan artifact; it must not materialize skill payloads or AAS managed state in the target.
+6. Treat apply and recovery as experimental opt-ins outside the supported preview claim. Do not add apply/recovery, benchmark, fuzz, crash/race, or synthetic verifier work unless the user explicitly places it in scope.
+7. When the task asks for end-to-end client proof, use a real supported client that discovers and invokes the local AAS MCP tools; direct stdio probes and automated tests do not substitute for that evidence.
+8. Do not tag, publish npm, deploy Pages, or write real user MCP configuration without the separately required publication approval.
 
 ## Protected Release
 

package/bundled-skills/docs/integrations/jetski-cortex.md

@@ -1,11 +1,11 @@
 ---
 title: Jetski/Cortex + Gemini Integration Guide
-description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,968+ skills."
+description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,969+ skills."
 ---
 
-# Jetski/Cortex + Gemini: safe integration with 1,968+ skills
+# Jetski/Cortex + Gemini: safe integration with 1,969+ skills
 
-> **Custom-host integration:** This guide documents a low-level, direct-manifest lazy loader for Jetski/Cortex and similar hosts. For Codex or Claude Code, the recommended path is [AAS Core](../users/aas-core.md), which provides verified local catalog discovery and deterministic recommendations through a bounded, read-only MCP server.
+> **Custom-host integration:** This guide documents a low-level, direct-manifest lazy loader for Jetski/Cortex and similar hosts. For Codex or Claude Code, the recommended path is [AAS Core](../users/aas-core.md), which provides neutral, deterministic catalog retrieval and validates exact agent-selected IDs through a bounded, read-only MCP server.
 
 This guide shows how to integrate the `agentic-awesome-skills` repository with an agent based on **Jetski/Cortex + Gemini** (or similar frameworks) **without exceeding the model context window**.
 
@@ -25,7 +25,7 @@ Never do:
 - concatenate all `SKILL.md` content into a single system prompt;
 - re-inject the entire library for **every** request.
 
-With 1,968+ skills, this approach fills the context window before user messages are even added, causing truncation.
+With 1,969+ skills, this approach fills the context window before user messages are even added, causing truncation.
 
 ---
 

package/bundled-skills/docs/integrations/jetski-gemini-loader/README.md

@@ -1,6 +1,6 @@
 # Jetski + Gemini Lazy Skill Loader (Example)
 
-> **Custom-host example:** This is a low-level, direct-manifest integration for Jetski/Cortex-style hosts. Codex and Claude Code users should start with [AAS Core](../../users/aas-core.md), which exposes verified local catalog discovery and deterministic recommendations through a bounded, read-only MCP server.
+> **Custom-host example:** This is a low-level, direct-manifest integration for Jetski/Cortex-style hosts. Codex and Claude Code users should start with [AAS Core](../../users/aas-core.md), which exposes neutral, deterministic catalog retrieval and validates exact agent-selected IDs through a bounded, read-only MCP server.
 
 This example shows one way to integrate **agentic-awesome-skills** with a Jetski/Cortex‑style agent using **lazy loading** based on `@skill-id` mentions, instead of concatenating every `SKILL.md` into the prompt.
 
@@ -23,7 +23,7 @@ This example shows one way to integrate **agentic-awesome-skills** with a Jetski
 - How to enforce a **maximum number of skills per turn** via `maxSkillsPerTurn`.
 - How to choose whether to **truncate or error** when too many skills are requested via `overflowBehavior`.
 
-This pattern avoids context overflow when you have 1,968+ skills installed.
+This pattern avoids context overflow when you have 1,969+ skills installed.
 
 Manifest contract references:
 

package/bundled-skills/docs/maintainers/aas-agent-first-control-plane-preview-profile.md

@@ -1,141 +1,63 @@
-# AAS Agent-First Control Plane Preview Profile
+# AAS Agent-Owned Selection Profile
 
-Status: approved intermediate release profile
-Date: 2026-07-17
-Certified design: `docs/maintainers/aas-agent-first-control-plane-v1-design.md`
+Status: active product profile
+Updated: 2026-07-19
 
 ## Purpose
 
-This profile validates whether Codex, Claude Code, and comparable agents can
-use AAS to compose useful local skill stacks without implying the retired
-certified-v1 benchmark or transaction-verifier guarantees. The certified-v1
-design and goal documents are retained as historical architecture records;
-their verifier corpus and routine workflow were removed on 2026-07-18.
-
-The permitted preview claim is:
-
-> AAS Agent-First Preview helps Codex and Claude compose a local, explainable,
-> reproducible skill stack. Full-catalog recommendation quality and
-> transactional apply/recovery safety are not yet certified.
-
-Preview output must not use `implementationVerified`, `releaseReady`,
-`released`, `certified`, or an equivalent unqualified claim.
-
-## Included preview surfaces
-
-- Minimal, schema-validated `aas-stack.json` with pinned catalog identity,
-  targets, approved intent and policy, and exact skill IDs.
-- CLI `stack init`, `stack recommend`, `stack validate`, `stack plan`, and
-  `stack doctor` from the packed npm candidate.
-- The local stdio MCP with exactly `search_skills`, `get_skill`,
-  `recommend_stack`, `inspect_stack`, `diff_stack`, and
-  `aas://skills/{id}`.
-- Deterministic recommendation with structured factors, two visible lanes
-  (`recommended` and `discoveryCandidates`), explicit unknowns, stable
-  tie-breaking, and fail-closed policy decisions.
-- Essential packed-product coverage on Linux and Node 22 from one exact
-  content-addressed tarball.
-- Workbench schema/import/render tests and a local production build. A live
-  Pages deployment remains outside the preview until separately approved.
+This profile defines the supported boundary for AAS Core after semantic skill selection moved to the coding agent.
+
+> Codex or Claude inspects the project, searches and reads the complete local catalog, and chooses exact skill IDs. AAS Core validates, pins, compares, and plans that agent-owned selection; it does not recommend skills.
+
+The earlier deterministic recommendation design and goal documents are retained as historical architecture records. They are not current product policy or release gates.
+
+## Supported surfaces
+
+- A complete, integrity-verified local catalog in which every canonical skill is searchable, readable, selectable, and usable.
+- Local stdio MCP tools `search_skills`, `get_skill`, `compose_stack`, `inspect_stack`, and `diff_stack`, plus `aas://skills/{id}`.
+- Minimal, schema-validated `aas-stack.json` with pinned catalog identity, targets, goals, and exact agent-selected skill IDs.
+- CLI manifest validation, immutable plan preview, and read-only diagnosis.
+- Workbench import and review of the agent-owned stack and immutable plan.
+
+## Selection contract
+
+1. The coding agent owns semantic selection. It may inspect the project with its normal local capabilities, search broadly, read full skill content when useful, compare alternatives, and choose exact IDs.
+2. AAS Core does not rank, recommend, promote, demote, exclude, or abstain on skills.
+3. Catalog metadata is informational only. Missing, incomplete, cautionary, or manually reviewed metadata must never make a canonical skill unsearchable, unselectable, or unusable.
+4. `compose_stack` validates catalog identity, target shape, goals, exact IDs, and structural limits, then returns the pinned stack shape. It does not substitute a different selection.
+5. `aas-stack.json` has no Core selection policy. User constraints can guide the agent's reasoning, but they are not an MCP eligibility filter or manifest gate.
+
+## Functional gate
+
+The packed-product smoke path must prove:
+
+1. **Catalog completeness** — packaged catalog count and IDs equal the canonical registry; exact-ID search, `get_skill`, and content reads work for every canonical skill.
+2. **MCP contract** — the five supported read-only tools and resource template work over real stdio framing without repository scanning or state writes.
+3. **Agent-owned composition** — `compose_stack` preserves the exact ordered ID selection supplied by the agent and returns a structurally valid manifest without a policy field.
+4. **No metadata gating** — skills with unknown, critical, manual, blocked, incomplete, or absent informational metadata remain searchable, selectable, composable, and plannable.
+5. **Stack lifecycle** — compose, inspect, validate, plan, and doctor succeed in isolated roots without materializing target skills or managed state.
+6. **Workbench** — bounded text-only import/review tests and production build pass without ambient filesystem access.
 
 ## Experimental writes
 
-`stack apply` and `stack recover` are present for controlled development but
-are not preview-supported safety claims. They are disabled by default:
-
-- apply requires the additional `--experimental-apply` flag and the existing
-  exact plan-digest approval;
-- recovery requires `--experimental-recovery` and retains its existing
-  recovery-plan approval;
-- successful experimental writes return `releaseProfile: "preview"` and
-  `certificationStatus: "experimental"`;
-- absence of the opt-in fails before runtime resolution or target writes with
-  a structured policy error.
-
-Internal transaction tests are development evidence only. Apply and recovery
-remain experimental and outside the supported preview claim.
-
-## Preview functional gate
-
-The preview job must install the exact candidate tarball with lifecycle scripts
-disabled and run without checkout-only runtime dependencies. It is an essential
-end-to-end smoke test, not an OS/runtime certification matrix.
-
-Required functional suites are:
-
-1. **Package and entrypoints** — allowlisted package contents; `aas`,
-   `aas-mcp`, and the legacy alias exist; legacy invocation creates no stack
-   state implicitly.
-2. **Stack lifecycle** — `init -> recommend -> validate -> plan -> doctor`
-   succeeds in isolated roots and does not materialize target skills or AAS
-   managed state.
-3. **Determinism and explanation** — repeated identical inputs produce the
-   same canonical recommendation payload and expose factor, coverage, evidence,
-   exclusion, and unknown fields.
-4. **Policy** — proved incompatibility or forbidden risk is excluded;
-   incomplete evidence remains visible; malformed or over-limit input fails
-   closed.
-5. **MCP contract** — the five tools and one resource template work over real
-   stdio framing; project and cache snapshots remain unchanged by tool calls.
-6. **Write guard** — apply and recovery without their experimental flags fail
-   with structured policy codes and leave project, cache, and managed state
-   unchanged.
-7. **Workbench** — bounded text-only import/review tests and production build
-   pass without ambient filesystem access.
-
-The preview receipt must declare:
-
-```json
-{
-  "assuranceProfile": "agent-first-preview-1",
-  "previewQualified": true,
-  "certifiedV1": false,
-  "notEvaluated": [
-    "native-network-and-filesystem-attempt-observation",
-    "transactional-crash-and-race-certification",
-    "benchmark-80-90-100",
-    "real-host-configuration-writes",
-    "public-release"
-  ]
-}
-```
-
-Missing receipts, crashes, timeouts, canonical drift, or any failed functional
-suite make `previewQualified` false.
-
-## Explicitly not certified by preview
-
-- ETW, `fs_usage`, or `strace` proof of zero network attempts and zero
-  persistent MCP writes.
-- Production-binary fault injection at every transaction boundary or every
-  declared race class.
-- Full benchmark thresholds: at least 80% verified coverage, 90% inclusion
-  precision, and 100% correct abstention for each supported intent and in
-  macro-average.
-- Complete property/fuzz/hostile budgets required by certified v1.
-- Real Codex or Claude configuration writes, public Pages deployment, npm
-  publication, GitHub release, or announcement.
-
-These are explicitly outside the current product claim. The repository does
-not maintain a blocking certified-v1 release gate.
+`stack apply` and `stack recover` remain experimental opt-ins. The supported public path stops after manifest validation and immutable plan review. Planning may write only the explicitly requested plan artifact.
 
-## Product-learning gate
+## Trust and privacy boundaries
 
-After the functional matrix passes, preview evaluation should measure whether
-agents actually produce useful proposals:
+- MCP is local, offline-capable, read-only, bounded, and non-mutating.
+- AAS does not receive repository files unless the agent explicitly reads them through its own host capabilities; AAS MCP does not scan the repository.
+- Full skill prose is untrusted content and gains no instruction authority through MCP.
+- Catalog and runtime integrity remain deterministic even though semantic selection belongs to the agent.
+- Real host configuration writes, publication, Pages deployment, npm release, and announcements require their separate approvals.
 
-- task completion rate from a repository profile to a reviewable stack;
-- human accept/replace/remove rates for recommended skills;
-- uncovered goals and discovery-candidate promotions;
-- deterministic replay rate for the same normalized input and catalog digest;
-- time and interaction count from request to approved manifest.
+## Product-learning gate
 
-No repository profile, source file, secret, or raw path is uploaded by default.
-Publishing or sharing any collected result requires a separate explicit
-decision and privacy review.
+Evaluate the quality of the agent workflow, not a Core recommender:
 
-## Relationship to certified v1
+- task completion from project inspection to a reviewable stack;
+- human accept, replace, and remove rates for agent-selected skills;
+- whether the agent searched enough of the catalog and read relevant skill content;
+- time and interaction count from request to approved manifest;
+- successful replay of the exact approved IDs against the pinned catalog identity.
 
-The preview receipt must report `previewQualified: true` and
-`certifiedV1: false`. The historical certified-v1 design is not a current
-release gate and must not be inferred from a green preview.
+No repository profile, source file, secret, or raw path is uploaded by default. Publishing or sharing any collected result requires a separate privacy decision.

package/bundled-skills/docs/maintainers/aas-agent-first-control-plane-v1-design.md

@@ -1,5 +1,7 @@
 # AAS Agent-First Control Plane v1 Design
 
+> **Historical design:** deterministic Core recommendation, metadata eligibility, and selection policy described below were superseded on 2026-07-19 by the active [Agent-Owned Selection Profile](aas-agent-first-control-plane-preview-profile.md). Retained for architecture history; not current product policy.
+
 Status: frozen and approved for implementation
 Date: 2026-07-17
 

package/bundled-skills/docs/maintainers/aas-agent-first-control-plane-v1-goal.md

@@ -1,5 +1,7 @@
 # AAS Agent-First Control Plane v1 Goal
 
+> **Historical goal:** recommendation-quality, metadata, and policy gates described below were superseded on 2026-07-19 by the active [Agent-Owned Selection Profile](aas-agent-first-control-plane-preview-profile.md). Retained for decision history; not a current release gate.
+
 Status: approved source packet for the active Codex goal
 Design source: `docs/maintainers/aas-agent-first-control-plane-v1-design.md`
 

package/bundled-skills/docs/maintainers/aas-agent-first-control-plane-v1-worklog.md

@@ -1,5 +1,7 @@
 # AAS Agent-First Control Plane v1 Worklog
 
+- 2026-07-19: Semantic skill selection moved to Codex and Claude. Core now exposes the complete catalog and validates/pins exact agent-selected IDs through `compose_stack`; selection policy and metadata eligibility gates were retired. Every canonical skill must remain searchable, readable, selectable, and usable. Earlier recommendation entries below are historical.
+
 ## 2026-07-18 — Baseline workflow retired
 
 - The standalone `aas-v1-baseline` pull-request workflow and required status check were retired by maintainer decision. The obsolete verifier corpus, harness, tuning runner, and paused apply/optimize workflows were subsequently removed. The protected `pr-policy`, `pr-evidence`, `source-validation`, and `artifact-preview` gates remain required.

package/bundled-skills/docs/maintainers/repo-growth-seo.md

@@ -6,7 +6,7 @@ This document keeps the repository's GitHub-facing discovery copy aligned with t
 
 Preferred positioning:
 
-> AAS Core is the local, deterministic engine that turns an explicit project profile into an explainable skill-stack recommendation and immutable preview plan, backed by 1,967+ cataloged skills.
+> AAS Core is the local, deterministic boundary that exposes the complete catalog, validates exact skill IDs selected by the coding agent from an explicit project profile, and produces an immutable preview plan, backed by 1,968+ cataloged skills.
 
 Key framing:
 
@@ -29,7 +29,7 @@ Preferred homepage:
 Preferred social preview:
 
 - lead with `AAS Core` and the profile → stack → plan flow;
-- present `1,968+ Agentic Skills` as supporting catalog evidence, not a second product;
+- present `1,969+ Agentic Skills` as supporting catalog evidence, not a second product;
 - mention Codex and Claude as the current Core agent path, with broader host compatibility as distribution support;
 - avoid dense text and tiny logos that disappear in social cards.
 
@@ -116,7 +116,7 @@ Start here:
 Suggested pinned discussion topics:
 
 - `Start here: compose a project stack with AAS Core`
-- `Choose between Core recommendation and direct distribution`
+- `Choose between an agent-selected Core stack and direct distribution`
 - `How the catalog, plugins, bundles, and workflows support Core`
 
 Discussion posts should:

package/bundled-skills/docs/maintainers/skills-update-guide.md

@@ -72,7 +72,7 @@ The update process refreshes:
 - Canonical skills index (`skills_index.json`)
 - Compatibility mirror (`data/skills_index.json`)
 - Web app skills data (`apps\web-app\public\skills.json`)
-- All 1,968+ skills from the skills directory
+- All 1,969+ skills from the skills directory
 
 ## When to Update
 

package/bundled-skills/docs/users/aas-core.md

@@ -1,33 +1,30 @@
-# AAS Core: Agent-First Skill Stacks
+# AAS Core: Agent-Owned Skill Stacks
 
-> **Preview status:** AAS Agent-First Preview helps Codex and Claude compose a local, explainable, reproducible skill stack. Full-catalog recommendation quality and transactional apply/recovery safety are not yet certified.
+AAS Core lets Codex and Claude search and read the complete local AAS catalog, preserve their exact skill selection as reproducible desired state, and preview a validated plan before any target change.
 
-AAS Core is the primary way to turn the repository's skill catalog into a controlled project stack:
+> **The agent inspects and chooses. AAS records and validates. You control.**
 
-> **The agent composes. You control. AAS keeps the stack reproducible.**
-
-The durable artifact is [`aas-stack.json`](#the-stack-manifest), not a prompt, an opaque model decision, or a copy of the entire catalog. The same deterministic, versioned core powers the local MCP server and the `aas` CLI. The hosted Workbench is a review surface; it is not a browser-side installer or hosted control plane.
+The primary durable artifact is [`aas-stack.json`](#the-stack-manifest). It records the exact skill IDs chosen by the coding agent; it is not the output of a Core ranking system. An audit-enabled flow can also persist a separate canonical `aas-selection-evidence.json` sidecar. The local MCP is a read-only catalog, composition, and evidence boundary; a client or the `aas` CLI performs persistence, the CLI validates and plans, and Workbench is a browser-local review surface.
 
 ## How it works
 
 ```text
 your project
   -> Codex or Claude inspects the repository
-  -> local AAS MCP (stdio, read-only)
-  -> deterministic AAS Core + bundled or verified local catalog
-  -> agent explains a recommendation and proposes aas-stack.json
-  -> you review the exact skills, target, policy, and catalog identity
+  -> agent searches and reads the complete local AAS catalog
+  -> agent chooses the exact skill IDs
+  -> compose_stack validates and returns the manifest in memory
+  -> client or CLI persists aas-stack.json and optional evidence sidecar
+  -> you review the artifacts
   -> aas stack validate
   -> aas stack plan (preview; no skill changes)
 ```
 
-The agent may inspect your project using its normal local capabilities, but AAS MCP does not scan the repository. It receives an explicit, allowlisted profile from the agent and returns structured catalog evidence.
+AAS MCP does not scan the repository and does not decide which skills are best. Codex or Claude uses its own project understanding and judgment. All 1,968 skills in the current catalog remain individually searchable, readable, selectable, and usable; missing or incomplete metadata never makes a skill ineligible. Core has no semantic policy that favors a small stack, while every stack manifest has an explicit technical maximum of 128 skills.
 
 ## Configure the local MCP
 
-> **Release boundary:** AAS Core landed after release 14.6.0, which is not a valid Core bootstrap. Core-capable packages begin with the 15.x line. In the command template below, replace `X.Y.Z` only with an exact release whose notes explicitly state that it includes AAS Core; do not resolve an unreviewed moving tag.
-
-The package publishes separate `aas` and `aas-mcp` binaries. For a pinned Core release without relying on npm's default-bin selection, invoke `aas` explicitly:
+> **Release boundary:** AAS Core landed after release 14.6.0. Use an exact Core-capable release rather than an unreviewed moving tag.
 
 ```bash
 npm exec --yes --ignore-scripts --package=agentic-awesome-skills@X.Y.Z -- aas mcp configure \
@@ -45,34 +42,56 @@ Use `--host claude` with the appropriate absolute Claude MCP configuration path
 
 Configuration is explicit and integrity-bound. AAS installs or reuses an exact content-addressed runtime, verifies it, and changes only its managed MCP configuration section. Restart the host if it does not reload MCP configuration automatically.
 
-## Ask the agent to compose the stack
+## Ask the agent to choose the stack
 
-Once the host discovers the AAS MCP tools, give it the outcome and constraints rather than manually choosing from almost 2,000 skills:
+Give the agent the desired outcome and constraints, and leave selection judgment with the agent:
 
 ```text
-Inspect this repository and use the AAS MCP tools to recommend a small skill stack
-for implementing and testing this project. Explain exclusions and unknowns, then
-propose an aas-stack.json and validate it with inspect_stack before presenting it.
-Do not install or apply anything.
+Inspect this repository. Search and read the complete local AAS catalog, then
+enumerate the project's primary capability areas. For each capability, run a
+focused search, paginate or refine until you find plausible candidates, and use
+get_skill to compare multiple candidates when available. Select at least one
+non-redundant valid skill for every covered capability. Explicitly report as a
+catalog gap any capability for which the catalog has no valid match. At minimum,
+evaluate architecture/runtime, languages/frameworks, domain behavior,
+data/storage, external integrations, testing/quality, security/privacy,
+user experience/accessibility when user-facing, deployment/operations, and
+maintenance workflow; mark dimensions not applicable instead of silently
+omitting them. Do not stop at the first few matches or optimize for the smallest
+stack. Core imposes no semantic small-stack policy; the manifest format has a
+technical maximum of 128 selected skills.
+Only then use compose_stack with a project profile to validate the exact IDs and
+return a schema 2 manifest in memory, and use inspect_stack before presenting
+it. Do not install or apply anything.
 ```
 
-The local MCP exposes exactly these read-only tools:
+This capability-coverage contract is delivered to supported clients in the MCP
+`initialize` instructions and reinforced by the tool descriptions. It is an
+agent obligation, not a Core ranking or eligibility policy: Core still accepts
+and preserves any structurally valid set of catalog IDs and never chooses for the
+agent.
+
+The local MCP exposes these read-only tools:
 
-- `search_skills` — search the verified local catalog;
-- `get_skill` — inspect one skill and its recorded evidence;
-- `recommend_stack` — produce a deterministic recommendation from an explicit profile and policy;
+- `search_skills` — retrieve deterministic, paginated matches from every skill in the verified local catalog without scores or ranking;
+- `get_skill` — inspect one skill and optionally read its full content;
+- `compose_stack` — validate the agent-selected IDs and return the stack manifest in memory without writing it;
 - `inspect_stack` — validate and explain a proposed manifest;
 - `diff_stack` — compare manifests using verified local catalogs.
+- `export_selection_evidence` — combine the server-recorded session trace with an agent-declared capability ledger and an already composed and inspected manifest;
+- `inspect_selection_evidence` — validate the sidecar's structure, digests, catalog identity, manifest binding, and factual cross-references without judging skill suitability.
 
-It also exposes the `aas://skills/{id}` resource template. MCP calls do not install or remove skills, update catalogs, edit host configuration, or apply a stack. Full skill text is returned only when requested and remains marked as untrusted content.
+Search results use a stable catalog order and contain no relevance score, recommendation, or preferred ordering. Codex or Claude evaluates the returned candidates semantically and chooses exact IDs. Metadata returned by search or inspection is informational context; Core does not use risk, source, setup, compatibility, review, or evidence metadata to rank, exclude, or disable a skill.
+
+MCP calls do not install or remove skills, update catalogs, edit host configuration, persist a stack, or apply it. Full skill text is returned only when requested and remains marked as untrusted content.
 
 ## The stack manifest
 
-`aas-stack.json` records approved desired state:
+`aas-stack.json` records agent-chosen desired state:
 
 ```json
 {
-  "schemaVersion": 1,
+  "schemaVersion": 2,
   "name": "project-stack",
   "catalog": {
     "package": "agentic-awesome-skills",
@@ -80,11 +99,12 @@ It also exposes the `aas://skills/{id}` resource template. MCP calls do not inst
     "integrity": "sha256-..."
   },
   "targets": [{ "host": "codex", "scope": "project" }],
-  "intent": { "goals": ["build", "test"] },
-  "policy": {
-    "allowedRisk": ["none", "safe"],
-    "requireKnownSource": true,
-    "allowManualSetup": false
+  "profile": {
+    "goals": ["build", "test"],
+    "projectType": "web application",
+    "languages": ["typescript"],
+    "frameworks": ["react"],
+    "constraints": ["preview only"]
   },
   "skills": [
     { "id": "example-skill" }
@@ -92,7 +112,31 @@ It also exposes the `aas://skills/{id}` resource template. MCP calls do not inst
 }
 ```
 
-The manifest pins the catalog identity, target, intent, policy, and exact skill IDs. Repository observations, ranking factors, exclusions, unknowns, and natural-language explanations stay in recommendation or plan output instead of becoming hidden state.
+The manifest pins catalog identity, targets, the project profile, and exact agent-selected skill IDs. It intentionally has no selection policy: Core validates identity and structure but does not overrule the agent's choice because metadata is missing, incomplete, or cautionary.
+
+`compose_stack` produces this manifest only in MCP process memory. Persist it through the client or the CLI. Audit-enabled CLI flows publish `aas-stack.json` together with `aas-selection-evidence.json` in the requested `artifact-dir`, keeping the sidecar separate from the desired-state manifest.
+
+## Selection evidence sidecar
+
+`aas-selection-evidence.json` makes the selection process auditable without moving semantic judgment into Core. It binds a path-safe project fingerprint, catalog identity, manifest digest, the agent-declared ten-dimension capability ledger, capability-to-skill mappings, and the actual `search_skills`, `get_skill`, `compose_stack`, and `inspect_stack` facts recorded by that MCP server session. `export_selection_evidence` takes the ledger but obtains the trace from server-owned session state; the caller cannot supply a replacement historical trace. `inspect_selection_evidence` performs structural and factual validation only.
+
+The trace records effective search query/cursor/limit values and returned IDs, opened skill IDs, exact compose IDs, inspect outcomes, safe error codes, deterministic retry attempts, and canonical input/output byte counts. Monotonic call durations are recorded separately outside the evidence digest. Client name and version come from MCP initialization when valid and available; model identity is omitted unless a trusted protocol surface supplies it.
+
+The sidecar does not prove that a capability is correctly interpreted, that a selected skill is best, or that semantic coverage is sufficient. Repository evidence references are relative and contain no file contents or absolute paths. Search queries are recorded verbatim as factual trace data, so do not put secrets, credentials, private source text, or personal data in `search_skills` queries. Runtime observations that are not deterministic are not part of the canonical evidence digest.
+
+The digest makes later edits detectable but is not a signature or cross-session identity attestation. The non-falsification guarantee is narrower: callers cannot inject or replace historical tool calls through `export_selection_evidence`; a standalone inspector can verify structure and digests, not who produced the file.
+
+To publish the manifest and exported sidecar without exposing a one-file intermediate state, use a new artifact directory:
+
+```bash
+aas stack create \
+  --selection /absolute/path/to/agent-selection.json \
+  --evidence /absolute/path/to/exported-evidence.json \
+  --artifact-dir /absolute/path/to/new-audit-artifact \
+  --require-evidence
+```
+
+The destination must not already exist. The CLI validates both artifacts, writes private staged files named `aas-stack.json` and `aas-selection-evidence.json`, synchronizes them, and publishes the complete directory with one rename. The original `stack create --selection ... --out ...` manifest-only path remains supported.
 
 ## Validate and preview the plan
 
@@ -110,32 +154,23 @@ aas stack plan \
   --out /absolute/path/to/plan.json
 ```
 
-`stack plan` derives the exact runtime version from the catalog identity in `aas-stack.json`; the verified runtime integrity remains explicit. The CLI rejects a legacy `--runtime-version` override when it disagrees with the manifest, so the documented command does not need a version edit for each release.
-
 `stack validate` is read-only. `stack plan` writes only the requested plan artifact and does not materialize skills or AAS managed state in the target. The immutable plan binds the manifest, runtime, catalog, target identity, current managed state, and exact logical operations.
 
-Stop after reviewing the plan unless you are deliberately participating in controlled preview development. `stack apply` and `stack recover` are disabled by default, require additional experimental flags and exact digest approval, and are **not supported or certified preview safety claims**.
+Stop after reviewing the plan unless you are deliberately participating in controlled preview development. `stack apply` and `stack recover` remain experimental and require explicit opt-in.
 
 ## Privacy, trust, and limits
 
 - MCP is local stdio, process-per-session, read-only, offline-capable, and contains no model credentials or telemetry.
-- Recommendation is deterministic and evidence-based; AAS does not call another model, use embeddings, or perform remote ranking.
-- Missing evidence is reported as `unknown`. AAS may leave goals uncovered instead of presenting a weak match as certainty.
+- Codex or Claude owns semantic selection. Different agents or project observations may reasonably produce different stacks.
+- Catalog integrity and manifest validation are deterministic; skill suitability is an agent judgment, not a Core score.
+- Core does not impose a semantic skill-count target. The technical manifest maximum is 128 skills, and every one of the current catalog's 1,968 skills remains individually searchable, readable, selectable, and usable. Metadata remains visible but informational.
+- Evidence exports include raw `search_skills` queries; keep secrets and sensitive project content out of those queries.
 - Catalog updates and runtime changes are explicit. There is no resident daemon or implicit auto-update.
-- The MCP boundary does not grant skill prose instruction authority and cannot guarantee how an external model interprets untrusted content.
-- Preview qualification does not certify full-catalog recommendation quality, transactional crash/race safety, apply, or recovery.
+- Skill prose is untrusted content and does not gain instruction authority by being returned through MCP.
 
 ## Other ways to use the catalog
 
-AAS Core is the recommended path when Codex or Claude can use the local MCP. Existing distribution paths remain available:
-
-- direct skill installs for hosts that load `SKILL.md` files;
-- specialized plugins for a fixed, domain-focused distribution;
-- bundles as human-curated presets;
-- workflows as ordered execution playbooks;
-- the legacy `agentic-awesome-skills` installer for compatible direct installs.
-
-These surfaces provide catalog content and packaging. AAS Core adds project-aware composition, explicit policy, a durable stack manifest, and a reviewable plan.
+Direct installs, specialized plugins, bundles, workflows, and the legacy installer remain available. These surfaces distribute or curate catalog content; AAS Core adds complete local access, durable agent-owned selection, manifest validation, and a reviewable plan.
 
 ## Next reads
 

package/bundled-skills/docs/users/agentic-awesome-skills-vs-awesome-claude-skills.md

@@ -1,6 +1,6 @@
 # Agentic Awesome Skills vs Awesome Claude Skills
 
-If you are comparing **Agentic Awesome Skills** with **Awesome Claude Skills**, first decide whether you need deterministic project-level composition or an editorial discovery list. Catalog breadth and curation are secondary dimensions.
+If you are comparing **Agentic Awesome Skills** with **Awesome Claude Skills**, first decide whether you need complete catalog access with agent-owned reproducible selection or an editorial discovery list.
 
 For clarity: the repository many people still refer to as `awesome-claude-skills` now lives at [VoltAgent/awesome-agent-skills](https://github.com/VoltAgent/awesome-agent-skills).
 
@@ -13,15 +13,15 @@ For clarity: the repository many people still refer to as `awesome-claude-skills
 
 | Criteria | Agentic Awesome Skills | VoltAgent Awesome Agent Skills |
 | --- | --- | --- |
-| Best for | Local deterministic composition, durable desired state, and plan preview | Curated discovery and official/community highlights |
+| Best for | Complete local catalog access, agent-owned selection, durable desired state, and plan preview | Curated discovery and official/community highlights |
 | Product shape | AAS Core with local MCP, CLI, stack/plan artifacts, Workbench review, and supporting catalog/distribution | Curated awesome-list style collection |
 | Supported tools | Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, Kiro, OpenCode, Copilot, more | Claude Code, Codex, Antigravity, Gemini CLI, Cursor, Copilot, OpenCode, Windsurf, more |
 | Onboarding | Installation docs, bundles, workflows, getting-started guides | Curated README and categorized references |
-| Good fit when | You want an agent to recommend a project stack under explicit policy | You want a smaller list to browse and evaluate manually |
+| Good fit when | You want an agent to inspect a project and choose exact IDs from the full catalog | You want a smaller list to browse and evaluate manually |
 
 ## Why choose Agentic Awesome Skills
 
-- You want Codex or Claude to send an explicit profile to a local, read-only MCP and receive a deterministic recommendation.
+- You want Codex or Claude to search and read a complete catalog through a local, read-only MCP and own the selection.
 - You want the approved selection recorded as `aas-stack.json` and validated before an immutable plan is produced.
 - You care about onboarding assets like [`bundles.md`](bundles.md), [`workflows.md`](workflows.md), and tool-specific guides.
 - You need coverage across many domains, not just a curated shortlist.
@@ -36,7 +36,7 @@ For clarity: the repository many people still refer to as `awesome-claude-skills
 
 - The AAS catalog is larger and its evidence remains uneven; Core reports unknowns rather than treating breadth as certified quality.
 - VoltAgent can be easier to skim quickly because it optimizes for curation.
-- If you want both, use curated lists for editorial discovery and AAS Core when you need a reproducible, policy-controlled project stack.
+- If you want both, use curated lists for editorial discovery and AAS Core when you need a reproducible agent-selected project stack.
 
 ## Suggested next step