opencode-skills-collection 4.0.7 → 4.0.9

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

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "updatedAt": "2026-07-21T01:23:41.144Z",
+  "updatedAt": "2026-07-23T01:29:44.093Z",
   "entries": [
     "00-andruia-consultant",
     "007",
@@ -931,6 +931,7 @@
     "helium-mcp",
     "helm-chart-scaffolding",
     "helpdesk-automation",
+    "hf-cloud-aws-context-discovery",
     "hf-mcp",
     "hf-mem",
     "hierarchical-agent-memory",
@@ -1162,7 +1163,17 @@
     "marketing-ideas",
     "marketing-plan",
     "marketing-psychology",
+    "markstream-angular",
+    "markstream-custom-components",
     "markstream-install",
+    "markstream-migration",
+    "markstream-nuxt",
+    "markstream-react",
+    "markstream-svelte",
+    "markstream-vue",
+    "markstream-vue2",
+    "markstream-vue2-cli",
+    "markstream-vue2-vite",
     "matematico-tao",
     "mathguard",
     "matplotlib",
@@ -1229,11 +1240,17 @@
     "multi-agent-task-orchestrator",
     "multi-cloud-architecture",
     "multi-platform-apps-multi-platform",
+    "n8n-agents",
+    "n8n-binary-and-data",
     "n8n-code-javascript",
     "n8n-code-python",
+    "n8n-code-tool",
+    "n8n-error-handling",
     "n8n-expression-syntax",
     "n8n-mcp-tools-expert",
+    "n8n-multi-instance",
     "n8n-node-configuration",
+    "n8n-subworkflows",
     "n8n-validation-expert",
     "n8n-workflow-patterns",
     "nanobanana-ppt-skills",
@@ -1851,6 +1868,7 @@
     "use-dom",
     "user-thoughts",
     "using-git-worktrees",
+    "using-n8n-mcp-skills",
     "using-neon",
     "using-superpowers",
     "uv-package-manager",

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

@@ -41,8 +41,8 @@ Before changing anything:
 
 2. Validate changed skills truthfully.
    - Run `npm run validate`, `npm run validate:references`, `npm run security:docs`, changed-skill evidence, and the relevant tests.
-   - Inspect semantics, safety, provenance, declared risk, limitations, and all tracked bundle files directly. Treat inferred risk labels and heuristic quality scores as non-authoritative; do not change a skill merely to satisfy a lexical signal.
-   - Inspect the `skill-review` workflow on the exact current head SHA.
+   - Treat the entire tracked `skills/<skill-id>/**` subtree as skill content. Inspect semantics, safety, provenance, declared risk, limitations, and every bundled file directly, including nested examples, scripts, lockfiles, references, and assets. Never reduce evidence or review to `SKILL.md` or a fixed support-directory allowlist.
+   - Require changed-skill evidence to cover every Git record in each changed canonical skill subtree. Require the `skill-review` workflow for changes under `skills/**` or `plugins/**/skills/**`; its reusable result must be keyed by the complete nearest skill-directory fingerprint on the exact current head SHA.
    - `review` means Tessl semantic review actually ran or a valid identical-content result was reused.
    - `manual-review-required` means Tessl credentials or credits were unavailable, or Tessl did not produce a passing result. Perform the maintainer semantic review and attest with `--reviewed-head <full-40-character-sha>`.
    - Any non-passing Tessl outcome produces `manual-review-required`; complete the semantic review and bind the judgment to the exact head instead of treating a heuristic score as merge authority.
@@ -61,6 +61,7 @@ Before changing anything:
      ```
 
    - `merge:batch` may normalize the PR body and close/reopen the PR. GitHub creates the replacement workflow runs asynchronously; the command must wait for and approve only post-reopen workflow/check-suite IDs. Older runs on the same SHA cannot satisfy or fail the fresh gate.
+   - Same-repository location is not sufficient authority for sensitive changes. The guarded same-repository exception is limited to a PR authored by the repository owner and requires an exact full-head attestation; collaborator-authored sensitive PRs fail closed under the external safety policy.
    - The routine protected checks are `pr-policy`, `pr-evidence`, `source-validation`, and `artifact-preview`. The retired `aas-v1-baseline` workflow is not a merge prerequisite and must not be awaited or approved during source or canonical-sync batches.
    - If the PR head or base changes, discard stale evidence and rerun from a fresh `origin/main`.
 
@@ -69,6 +70,10 @@ Before changing anything:
    - Verify its managed-only diff, required checks, merge result, and the resulting `origin/main`.
    - If an unmanaged repair remains, use a topic PR; never patch `main` directly.
 
+## Workflow Contract Change Gate
+
+When changing maintainer scripts, workflows, or policy, update the canonical skill, maintainer documentation, and regression tests in the same source PR. Add a negative test for every failure mode being fixed, run the relevant dry-run path, and reject any implementation/documentation mismatch. Source PRs must exclude generated registries and plugin mirrors; the protected canonical-sync PR owns that derived state, except for files intentionally staged by the scripted protected-release flow.
+
 ## Hosted Catalog and Legacy Redirect Bridge
 
 Treat the current catalog and the legacy user-site bridge as one public system:
@@ -106,12 +111,21 @@ For AAS CLI, MCP, stack, catalog-cache, or Workbench changes:
 
 Release only when requested.
 
+Every stable or prerelease version requires full release alignment. Creating the tag, GitHub Release, or npm package is an intermediate milestone, never the completion condition.
+
 1. Include the target changelog entry in the maintainer batch PR so it is already on protected `main`; avoid a separate release-notes-only PR.
 2. From clean, current `main`, run `npm run release:preflight` and required security checks.
-3. Run `npm run release:prepare -- X.Y.Z`. This creates and pushes `release/vX.Y.Z` and opens the protected release PR.
-4. Merge that release PR through its required checks, update local `main` to equal `origin/main`, and wait for any canonical-sync PR to close.
-5. Run `npm run release:publish -- X.Y.Z`. It verifies the exact protected merge before creating or reusing the tag and GitHub Release.
-6. Wait for publishing workflows, then verify the tag/ref, GitHub Release, npm version and dist-tag, CI, Pages, CodeQL, live `llms.txt`, `skills.json`, and changed catalog routes.
+3. Run the release-state generator and its explicit plugin gates. Require a second no-drift pass before publication: `npm run sync:release-state`, `npm run plugin-compat:check`, and `npm run bundles:check` must leave a clean tree. Inspect `package.json`, `package-lock.json`, generated registries and the offline catalog, tracked web assets, `.agents/plugins/marketplace.json`, `.claude-plugin/plugin.json`, `.claude-plugin/marketplace.json`, and every published Codex/Claude plugin mirror and editorial-bundle manifest. Every release-owned manifest version must equal `X.Y.Z`.
+4. Run `npm run release:prepare -- X.Y.Z`. This creates and pushes `release/vX.Y.Z` and opens the protected release PR.
+5. Merge that release PR through its required checks, update local `main` to equal `origin/main`, and wait for every source, release, or canonical-sync PR in the release path to close. Re-run the release-state and plugin gates if protected `main` moved.
+6. Run `npm run release:publish -- X.Y.Z`. It must resolve exactly one merged release PR from the same repository, authored by the repository owner, with base `main`, exact title `chore: release vX.Y.Z`, and head branch `release/vX.Y.Z`. Zero or multiple candidates fail closed; never select the newest approximate match. The command then verifies that exact protected merge before creating or reusing the tag and GitHub Release.
+7. Wait for publishing workflows, then bind every proof to the exact released commit: verify the tag/ref, GitHub Release, npm version and intended dist-tag, required CI, CodeQL, and the explicitly dispatched release-only Pages build. Verify live `llms.txt`, `skills.json`, catalog and plugin routes, and the legacy redirect bridge; do not accept a successful run for a different SHA.
+8. After npm confirms `X.Y.Z` as the published dist-tag, discover every already-configured local AAS MCP host from its real configuration and update each one to the exact same package version before declaring the release complete. Updating existing AAS host entries is part of the release; creating a previously absent host configuration still requires explicit authorization.
+   - Use the published package's `aas mcp configure` two-pass flow: first preview the change, then repeat the identical command with its approval digest. Supply absolute host-config, cache, and backup paths; require a backup when replacing an existing configuration.
+   - Pin `agentic-awesome-skills@X.Y.Z` and `--version X.Y.Z`; never use `latest`, reuse an older cached runtime, or create a previously absent host configuration without explicit authorization.
+   - Verify that the managed host configuration points to a content-addressed `X.Y.Z` runtime, that the runtime package metadata reports `X.Y.Z`, and that a real MCP `initialize` plus `tools/list` handshake reports catalog package version `X.Y.Z`.
+   - Restart the host or open a fresh client session when required so the new MCP process is actually loaded. If configuration access, approval, or runtime verification is blocked, report the exact blocker and keep the maintainer task incomplete even though the package itself is already public.
+9. Fetch `origin/main` again after automation settles, fast-forward the maintainer checkout, and repeat the release-state, plugin, version, public-surface, and MCP parity checks. The final generator pass must be idempotent, the tree must stay clean, and `git rev-list --left-right --count main...origin/main` must end at `0 0`.
 
 Never rebase a published release tag, force stale release state, reuse a failed published version, or claim npm publication from the GitHub Release alone.
 
@@ -121,10 +135,10 @@ Finish only when:
 
 - every in-scope PR, issue, and alert is resolved or has one exact blocker;
 - no open source or canonical-sync PR remains unintentionally;
-- `main`, `origin/main`, required workflows, generated state, and public surfaces agree;
+- for every stable or prerelease version, clean local `main`, `origin/main`, the released commit, canonical generated state, every Codex/Claude plugin mirror, bundle, manifest, marketplace, compatibility report, tag, GitHub Release, npm dist-tag, required workflow, and live public surface agree exactly;
 - the source and legacy repositories have no unintended infrastructure PR, their protected branches and Actions settings remain enforced, and the live manifest identifies the source repository;
 - the user worktree is unchanged except for files the user explicitly placed in scope;
-- release proof is complete when a release was requested.
+- release proof is complete when a release was requested, including an idempotent no-drift regeneration and exact runtime parity between the published npm package and every already-configured local AAS MCP host. Any mismatch keeps the release incomplete.
 
 ## Failure Rules
 

package/bundled-skills/antigravity-maintainer-batch-release/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Antigravity Maintainer Batch Release"
+  short_description: "Run protected AAS maintenance and releases"
+  default_prompt: "Use $antigravity-maintainer-batch-release to run a protected AAS maintenance sweep with exact-head review, source-only merges, canonical sync, and fail-closed release verification."

package/bundled-skills/anywrite/SKILL.md

@@ -12,6 +12,14 @@ tags: [anytype, cli, pkm, notes, api-integration, productivity, knowledge-manage
 tools: [claude, cursor, gemini, codex]
 license: "MIT"
 license_source: "https://github.com/Antheurus/anywrite/blob/main/LICENSE"
+plugin:
+  targets:
+    codex: blocked
+    claude: blocked
+  setup:
+    type: manual
+    summary: "Requires a separately installed, user-approved anywrite executable at an explicit absolute path."
+    docs: SKILL.md
 ---
 
 # anywrite
@@ -30,12 +38,14 @@ license_source: "https://github.com/Antheurus/anywrite/blob/main/LICENSE"
 
 ### Step 1: Ensure Anytype desktop is running and authenticated
 
+This repository does not ship the `anywrite` executable. The user must install or build a reviewed upstream release outside the current workspace and provide its explicit absolute path. Before use, verify that path is an executable regular file, is not a symlink, and is not a workspace-relative `dist/` artifact. Never auto-discover or execute `./dist/anywrite` from the repository being worked on.
+
 The Anytype desktop app must be running locally (default `http://localhost:31009`). Authenticate once:
 
 ```bash
-./dist/anywrite auth --status        # shows configured yes/no and where the key came from
-./dist/anywrite auth                 # challenge flow — a 4-digit code appears in the app
-./dist/anywrite auth --code 1234     # non-interactive form of the same exchange
+"/absolute/path/to/anywrite" auth --status        # shows configured yes/no and where the key came from
+"/absolute/path/to/anywrite" auth                 # challenge flow — a 4-digit code appears in the app
+"/absolute/path/to/anywrite" auth --code 1234     # non-interactive form of the same exchange
 ```
 
 The key is written to `~/.anywrite/config.json` and is never printed by any command.
@@ -53,21 +63,21 @@ Resources: `spaces`, `objects`, `properties`, `tags`, `types`, `templates`, `lis
 ### Example 1: Create and update an object
 
 ```bash
-./dist/anywrite objects create <space> --type task --name "Buy milk"
-./dist/anywrite objects update <space> <object_id> --status "Done"
+"/absolute/path/to/anywrite" objects create <space> --type task --name "Buy milk"
+"/absolute/path/to/anywrite" objects update <space> <object_id> --status "Done"
 ```
 
 ### Example 2: Search and upload a file
 
 ```bash
-./dist/anywrite search global --query "task" --types task
-./dist/anywrite files upload <space> --file ./image.png
+"/absolute/path/to/anywrite" search global --query "task" --types task
+"/absolute/path/to/anywrite" files upload <space> --file ./image.png
 ```
 
 ### Example 3: Read chat messages
 
 ```bash
-./dist/anywrite chat messages <space> <chat_id> --all
+"/absolute/path/to/anywrite" chat messages <space> <chat_id> --all
 ```
 
 ## Best Practices

package/bundled-skills/cloudflare-security-audit/SKILL.md

@@ -43,15 +43,17 @@ Use the platform's equivalent capabilities while preserving the specified roles,
 
 ## Setup
 
-Before starting, establish two paths:
+Before starting, establish two paths and one target identity:
 - **Target**: the codebase to audit (from the user's request or the current working directory)
-- **Output directory**: where all audit artifacts go. Ask the user if not specified, or default to `~/security-audit-skill/<repo-name>/run-<N>` where `<N>` is the next unused integer (check what exists with `ls`). Create it if it doesn't exist. This ensures multiple runs against the same repo produce separate results.
+- **Target identity**: the canonical physical repository path plus its normalized `origin` owner/repository URL. Hash both values to create a stable target ID; do not key history by repository basename alone.
+- **Output directory**: where all audit artifacts go. Ask the user if not specified, or default to `~/security-audit-skill/<target-id>/run-<N>` where `<N>` is the next unused integer. Create it if it doesn't exist. This ensures same-named repositories cannot share audit history.
 
 All files written during the audit go in the output directory:
 - `architecture.md` — Phase 1 output, fed into Phase 2 agent prompts
 - `REPORT.md` — human-readable report (Phase 4)
 - `FINDINGS-DETAIL.md` — detailed data flows for MEDIUM+ findings (Phase 4)
 - `findings.json` — machine-readable structured output (Phase 5)
+- `target.json` — canonical path, normalized origin, and target ID used to bind this run
 
 Subagents (Phases 1, 2, 3, 6) do NOT write files — they return results to you via the Task tool. You are responsible for writing all files to the output directory.
 
@@ -59,7 +61,7 @@ Subagents (Phases 1, 2, 3, 6) do NOT write files — they return results to you
 
 Each audit run explores different code paths depending on which agents find what and where they dig. No single run finds everything. Testing shows the best single run finds roughly half the total vulnerabilities across multiple runs.
 
-**If prior runs exist** for the same repo (check `~/security-audit-skill/<repo-name>/`), read their `findings.json` files before starting Phase 2. Use them to:
+**If prior runs exist** for the exact target ID, first require their `target.json` canonical path and normalized origin to match the current target byte-for-byte. Treat missing or mismatched manifests as unrelated and never read or summarize their findings. Do not search or reuse prior runs from a basename-only directory. After that identity check, read matching `findings.json` files before starting Phase 2. Use them to:
 1. **Skip known findings** — don't waste agents re-discovering the same status bypass. Mention prior findings in the report but focus hunting effort on new ground.
 2. **Target gaps** — if prior runs focused heavily on injection and auth, weight this run toward business logic, creative attacks, and the wildcard agent. If prior runs missed public endpoints, focus there.
 3. **Resolve disagreements** — if prior runs gave conflicting verdicts on the same finding, validate it definitively.

package/bundled-skills/cloudflare-security-audit/references/RECONNAISSANCE.md

@@ -2,6 +2,8 @@
 
 ### Phase 1: Understand the application
 
+Before using prior-run context, verify the current run's `target.json` against the candidate run: canonical physical path, normalized origin owner/repository URL, and derived target ID must all match exactly. A repository basename is never a target identity. Ignore mismatched or missing manifests rather than importing their findings.
+
 Before looking for bugs, understand what you're auditing. This requires depth, not just a directory listing. Launch **multiple `research` agents in parallel** to map different aspects of the codebase:
 
 **Agent 1a: Overview, tech stack, and comparable baseline**

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

@@ -1,9 +1,9 @@
 ---
 title: Jetski/Cortex + Gemini Integration Guide
-description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,969+ skills."
+description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,987+ skills."
 ---
 
-# Jetski/Cortex + Gemini: safe integration with 1,969+ skills
+# Jetski/Cortex + Gemini: safe integration with 1,987+ 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 neutral, deterministic catalog retrieval and validates exact agent-selected IDs through a bounded, read-only MCP server.
 
@@ -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,969+ skills, this approach fills the context window before user messages are even added, causing truncation.
+With 1,987+ 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

@@ -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,969+ skills installed.
+This pattern avoids context overflow when you have 1,987+ skills installed.
 
 Manifest contract references:
 

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

@@ -13,7 +13,7 @@ The earlier deterministic recommendation design and goal documents are retained
 
 ## Supported surfaces
 
-- A complete, integrity-verified local catalog in which every canonical skill is searchable, readable, selectable, and usable.
+- A complete, integrity-verified local catalog in which every canonical skill is searchable, readable, and available for agent selection.
 - 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.
@@ -23,7 +23,7 @@ The earlier deterministic recommendation design and goal documents are retained
 
 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.
+3. Catalog metadata is informational only. Missing, incomplete, cautionary, or manually reviewed metadata must never make a canonical skill unsearchable or unavailable for agent selection.
 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.
 

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

@@ -1,6 +1,6 @@
 # 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-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, and available for agent selection. Earlier recommendation entries below are historical.
 
 ## 2026-07-18 — Baseline workflow retired
 

package/bundled-skills/docs/maintainers/merge-batch.md

@@ -18,7 +18,7 @@ npm run merge:batch -- --prs 450,449,446,451
 
 Add `--poll-seconds <n>` if you want a slower or faster status loop while checks settle.
 
-If a PR changes canonical `SKILL.md` content or its allowlisted supporting assets/references/resources, first review the exact current head commit, then attest to that immutable revision:
+If a PR changes any tracked file under a canonical `skills/<skill-id>/**` subtree, review the entire affected subtree at the exact current head commit, then attest to that immutable revision:
 
 ```bash
 npm run merge:batch -- --prs 450 --reviewed-head <40-character-head-sha>
@@ -34,7 +34,7 @@ Use `--dry-run` to exercise local classification without approving a run or merg
 - recompute changed-skill evidence with evaluator code materialized from the trusted `main` commit
 - reject incomplete evidence coverage, deterministic quality/security/provenance regressions, and base/head drift
 - for external PRs, poll for asynchronously-created fork runs and approve only runs waiting on `action_required` when every path, mode, object, size, and workflow identity is allowlisted
-- for same-repository maintainer PRs, allow repository-wide source changes while still enforcing trusted changed-skill evidence, exact-head review, required checks, branch protection, and immutable PR identity
+- for sensitive same-repository source changes, allow the guarded exception only when the PR author is the repository owner and the exact full head SHA is attested; collaborator-authored sensitive changes fail closed under the external safety policy
 - wait for the latest required checks bound to the exact head SHA
 - call GitHub's immediate squash-merge endpoint and continue only when it reports `merged: true`
 - pull the protected `main`; its trusted workflow opens a canonical-sync bot PR for generated artifacts and contributor credits when needed
@@ -48,7 +48,7 @@ Use `--dry-run` to exercise local classification without approving a run or merg
 
 - conflict resolution on the PR branch
 - manual judgment for risky skill changes
-- semantic review when the distinct `manual-review-required` check is present
+- semantic review when the distinct `manual-review-required` check is present; the review fingerprint covers the complete nearest skill directory, including nested examples, scripts, lockfiles, references, and assets
 - README community-source audits when the source metadata is ambiguous
 - fork-only edge cases that require contributor coordination outside GitHub permissions
 - base-branch drift: stale evidence is discarded and the batch must be rerun

package/bundled-skills/docs/maintainers/merging-prs.md

@@ -1,19 +1,19 @@
 # Merging Pull Requests
 
-**Policy: we always Merge PRs on GitHub so contributors get credit. We never Close a PR after integrating their work locally.**
+**Policy: every accepted PR is merged through `npm run merge:batch`, which uses GitHub's protected squash-merge endpoint so contributors get credit. We never push an integration directly to `main` or close a PR after copying its work.**
 
 ## Always merge via GitHub
 
-- Use the GitHub UI **"Squash and merge"** for every accepted PR.
+- Use `npm run merge:batch -- --prs <PR_NUMBER>` for every accepted PR; do not substitute the GitHub UI or a raw `gh pr merge` command.
 - The PR must show as **Merged**, not Closed. That way the contributor appears in the repo’s contribution graph and the PR is clearly linked to the merge commit.
 - Do **not** integrate a PR by squashing locally, pushing to `main`, and then closing the PR. That would show "Closed" and the contributor would not get proper credit.
-- Before merging, require the normal PR checks from [`.github/workflows/ci.yml`](../../.github/workflows/ci.yml) to be green. If the PR touches `SKILL.md`, also require the separate [`skill-review` workflow](../../.github/workflows/skill-review.yml) to pass.
-- For PRs that touch `SKILL.md` or risky guidance, require a real manual logic review in addition to the automated checks. Confirm the instructions, failure modes, and `risk:` label make sense before merging.
+- Before merging, require the normal PR checks from [`.github/workflows/ci.yml`](../../.github/workflows/ci.yml) to be green. If the PR changes anything under `skills/**` or `plugins/**/skills/**`, also require a truthful outcome from the separate [`skill-review` workflow](../../.github/workflows/skill-review.yml).
+- For any tracked change under a canonical `skills/<skill-id>/**` subtree, inspect the complete skill directory and require a real manual logic review in addition to the automated checks. Confirm instructions, bundled files, failure modes, provenance, and `risk:` label before attesting the exact full head SHA.
 - For ordered multi-PR maintainer batches, use [Merge Batch](merge-batch.md) as the operational shortcut and keep this document as the policy reference.
 
 ## If the PR has merge conflicts
 
-Resolve conflicts **on the PR branch** so the PR becomes mergeable, then use "Squash and merge" on GitHub.
+Resolve conflicts **on the PR branch** so the PR becomes mergeable, then use `merge:batch`.
 
 ### Generated files policy
 
@@ -38,10 +38,10 @@ Resolve conflicts **on the PR branch** so the PR becomes mergeable, then use "Sq
    `git add .` then `git commit -m "chore: merge main to resolve conflicts"` (or leave the default merge message).
 5. **Push to the same branch the PR is from**  
    If the PR is from the contributor’s fork branch (e.g. `sraphaz:feat/uncle-bob-craft`), you need push access to that branch. Options:
-   - **Preferred:** Ask the contributor to merge `main` into their branch, fix conflicts, and push; then you use "Squash and merge" on GitHub.
+   - **Preferred:** Ask the contributor to merge `main` into their branch, fix conflicts, and push; then use `merge:batch`.
    - If you have a way to push to their branch (e.g. they gave you permission, or the branch is in this repo), push:  
      `git push origin pr-<PR_NUMBER>:feat/uncle-bob-craft` (replace with the actual branch name from the PR).
-6. **On GitHub:** The PR should now be mergeable. Click **"Squash and merge"**. The PR will show as **Merged**.
+6. **Run the guarded merge:** Once the PR is mergeable, use `npm run merge:batch -- --prs <PR_NUMBER> [--reviewed-head <40-character-head-sha>]`. The PR will show as **Merged**.
 
 ### If the contributor resolves conflicts
 
@@ -58,23 +58,19 @@ git commit -m "chore: merge main to resolve conflicts"
 git push origin <their-branch>
 ```
 
-Then you use **"Squash and merge"** on GitHub. The PR will be **Merged**, not Closed.
+Then use the guarded `merge:batch` command. The PR will be **Merged**, not Closed.
 
-## Rare exception: local squash (avoid if possible)
+## No local-integration exception
 
-Only if merging via GitHub is not possible (e.g. contributor unreachable and you must integrate their work, or a one-off batch), you may squash locally and push to `main`. In that case:
-
-1. Add a **Co-authored-by** line to the squash commit so the contributor is still credited (see [GitHub: Creating a commit with multiple authors](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors)).
-2. Close the PR with a comment explaining why it was integrated locally and that attribution is in the commit.
-3. Prefer to avoid this pattern in the future so PRs can be **Merged** normally.
+If `merge:batch` cannot prove the immutable PR tuple, required checks, branch protection, or exact review evidence, stop and repair the PR or workflow. Never integrate locally, push directly to `main`, or replace the guarded command with a raw merge.
 
 ## Summary
 
 | Goal                         | Action                                                                 |
 |-----------------------------|------------------------------------------------------------------------|
-| Give contributors credit   | Always use **Squash and merge** on GitHub so the PR shows **Merged**.  |
-| PR has conflicts           | Resolve on the PR branch (you or the contributor), then **Squash and merge**. |
-| Never                      | Integrate locally and then **Close** the PR without merging.          |
+| Give contributors credit   | Use `merge:batch` so GitHub records the protected squash merge.       |
+| PR has conflicts           | Resolve on the PR branch, then run `merge:batch`.                     |
+| Never                      | Push an integration directly to `main`, use a raw merge, or close the PR after copying its work. |
 
 ## References
 

package/bundled-skills/docs/maintainers/pr-autonomy.md

@@ -63,9 +63,9 @@ A successful `manual-review-required` check means only that the requirement was
 
 A real merge also requires effective server-side protection for `main`: the four exact GitHub-Actions-owned checks (`pr-policy`, `pr-evidence`, `source-validation`, and `artifact-preview`), strict up-to-date enforcement, pull-request-only changes, administrator enforcement, no applicable ruleset bypass actors, and no merge queue. If that enforcement cannot be proven, `merge:batch` refuses non-dry-run operation. Base drift is never retried with stale evidence; the batch must be rerun from the new tuple. Pre-existing auto-merge state is rejected, and the immediate GitHub merge endpoint must return `merged: true` before post-merge work begins.
 
-Same-repository maintainer PRs may legitimately change repository-wide policy, tooling, workflows, or documentation, so the fork content allowlist does not apply to them. They remain bound to the protected branch, trusted-base evidence evaluator, exact PR/base/head tuple, semantic-review requirements, and required checks. Missing or mismatched head-repository identity is treated as external and therefore fails closed under the fork allowlist.
+Sensitive same-repository PRs may use the repository-wide source exception only when the PR author is the repository owner and the maintainer attests the exact full head SHA. Collaborator-authored sensitive PRs do not inherit trust from branch location and fail closed under the external safety policy. Every accepted PR remains bound to the protected branch, trusted-base evidence evaluator, exact PR/base/head tuple, semantic-review requirements, and required checks. Missing or mismatched head-repository identity is treated as external.
 
-For canonical `SKILL.md` or allowlisted supporting skill-content changes, the maintainer supplies `--reviewed-head <full-sha>`. A stale, abbreviated, or mismatched SHA fails closed. The Skill Review check itself is required only for `SKILL.md` changes because that workflow is path-filtered; support-only changes still require the exact-SHA human attestation.
+For any tracked change under a canonical `skills/<skill-id>/**` subtree, the maintainer supplies `--reviewed-head <full-sha>`. A stale, abbreviated, or mismatched SHA fails closed. Skill Review triggers for `skills/**` and `plugins/**/skills/**`, and its reusable result is keyed by the complete nearest skill-directory fingerprint, so nested examples, scripts, lockfiles, references, assets, and other bundled files cannot bypass semantic review.
 
 Deletions, copies, ambiguous moves, and all canonical skill-content changes remain manual-only in this stage even when deterministic evidence contains no regression. A passing ratchet is not semantic approval and never makes a skill eligible for automatic merge.
 

package/bundled-skills/docs/maintainers/release-process.md

@@ -46,7 +46,7 @@ Use this as a diagnostic signal. It is useful for spotting legacy quality debt,
 - Add the release entry to [`CHANGELOG.md`](../../CHANGELOG.md).
 - Confirm `README.md` reflects the current version and generated counts.
 - Confirm Credits & Sources, contributors, and support links are still correct.
-- If PR or CI workflow behavior changed during the cycle, confirm maintainer and contributor docs mention the active checks (for example the `skill-review` workflow for `SKILL.md` pull requests).
+- If PR or CI workflow behavior changed during the cycle, confirm maintainer and contributor docs mention the active checks (for example the `skill-review` workflow for any change under `skills/**` or `plugins/**/skills/**`).
 - If maintainers changed declared risk labels during the cycle, confirm that each change has semantic review evidence rather than lexical inference.
 
 5. Prepare the protected release PR:
@@ -60,7 +60,9 @@ This command:
 - checks `CHANGELOG.md` for `X.Y.Z`
 - aligns `package.json` / `package-lock.json`
 - runs the full release suite
+- explicitly proves `plugin-compat:check` and `bundles:check` after regeneration
 - refreshes release metadata in `README.md`
+- regenerates canonical registries, tracked web assets, both plugin marketplaces, every Codex/Claude mirror and editorial bundle, and every release-owned plugin manifest
 - stages canonical release files
 - creates and pushes `release/vX.Y.Z`
 - opens a release PR containing the scripted canonical release state
@@ -73,7 +75,7 @@ Prerelease versions use the same protected flow, for example `15.0.0-rc.1`. They
 npm run release:publish -- X.Y.Z
 ```
 
-This command proves local `main` equals protected `origin/main` and the exact squash commit of the merged `release/vX.Y.Z` PR, checks that no canonical-sync PR or release-state drift remains, creates or reuses the matching local/remote tag safely, and creates the GitHub release object from the matching `CHANGELOG.md` section. SemVer prereleases are marked as GitHub prereleases. It never pushes `main` directly and can be retried after a partial tag/release failure.
+This command requires exactly one merged release PR from the same repository, authored by the repository owner, with base `main`, exact title `chore: release vX.Y.Z`, and head branch `release/vX.Y.Z`. Zero or multiple candidates fail closed; the command never chooses the newest approximate match. It then proves local `main` equals protected `origin/main` and that PR's exact squash commit, checks that no canonical-sync PR or release-state drift remains, creates or reuses the matching local/remote tag safely, and creates the GitHub release object from the matching `CHANGELOG.md` section. SemVer prereleases are marked as GitHub prereleases. It never pushes `main` directly and can be retried after a partial tag/release failure.
 
 7. Publish to npm if needed:
 
@@ -89,6 +91,19 @@ npm view agentic-awesome-skills dist-tags --json
 
 The workflow reruns `sync:release-state`, installs Python dependencies from `tools/requirements.txt`, refreshes tracked web assets, fails on canonical drift via `git diff --exit-code`, executes tests and docs security checks, runs the web-app coverage gate, enforces `npm audit --audit-level=high`, builds the web app, and dry-runs the npm package before publishing.
 
+8. Complete the mandatory full-release-alignment gate.
+
+A stable or prerelease version is not complete when only its tag, GitHub Release, or npm package exists. After publication:
+
+- rerun `npm run sync:release-state`, `npm run plugin-compat:check`, and `npm run bundles:check`, then require an idempotent second pass and a clean tree;
+- verify every release-owned Codex/Claude plugin manifest and Claude marketplace entry equals `X.Y.Z`, without treating nested third-party skill manifests as AAS release manifests;
+- bind local and remote `main`, the tag, GitHub Release, npm version and intended dist-tag, required CI, CodeQL, and the explicitly dispatched release-only Pages deployment to the exact released commit;
+- read back live `llms.txt`, `skills.json`, catalog/plugin routes, and the legacy redirect bridge;
+- discover every already-configured local AAS MCP host from real configuration, update each existing entry with the digest-bound two-pass `aas mcp configure` flow, pin `agentic-awesome-skills@X.Y.Z` and `--version X.Y.Z`, preserve a backup, restart or reconnect the host, and prove a real `initialize` plus `tools/list` handshake reports `X.Y.Z`;
+- fetch and fast-forward `main` again after automation settles, require `git rev-list --left-right --count main...origin/main` to return `0 0`, and repeat the no-drift, public-surface, and MCP parity checks.
+
+A release request covers updates to existing AAS MCP host entries only. Creating a previously absent host configuration still needs separate authorization. Any mismatch, inaccessible configured host, or stale public surface keeps the release incomplete.
+
 ## Canonical Sync Bot
 
 `main` still uses the repository's auto-sync model for canonical generated artifacts, but through a protected pull-request contract:

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 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.
+> 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 the current catalog.
 
 Key framing:
 
@@ -20,7 +20,7 @@ Key framing:
 
 Preferred description:
 
-> Local, deterministic AAS Core for explainable coding-agent skill stacks, backed by 1,967+ cataloged skills. Includes a read-only MCP, stack CLI, Workbench review, plugins, bundles, workflows, and direct distribution.
+> Local, deterministic AAS Core for explainable coding-agent skill stacks, backed by the current catalog. Includes a read-only MCP, stack CLI, Workbench review, plugins, bundles, workflows, and direct distribution.
 
 Preferred homepage:
 
@@ -29,7 +29,7 @@ Preferred homepage:
 Preferred social preview:
 
 - lead with `AAS Core` and the profile → stack → plan flow;
-- present `1,969+ Agentic Skills` as supporting catalog evidence, not a second product;
+- present `1,987+ 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.
 

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,969+ skills from the skills directory
+- All 1,987+ skills from the skills directory
 
 ## When to Update
 

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

@@ -20,14 +20,17 @@ your project
   -> aas stack plan (preview; no skill changes)
 ```
 
-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.
+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. Every current catalog skill remains individually searchable, readable, and available for agent selection; 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.
+
+> [!IMPORTANT]
+> Structural and identity validity does not certify semantic fit, compatibility, setup correctness, operational safety, or safety to apply.
 
 ## Configure the local MCP
 
 > **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 \
+npm exec --yes --ignore-scripts --package=agentic-awesome-skills@15.3.0 -- aas mcp configure \
   --host codex \
   --scope user \
   --config /absolute/path/to/codex/config.toml \
@@ -42,6 +45,21 @@ 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.
 
+### Native Windows and Codex
+
+Native Windows 10 and 11 with Node.js 22 are supported preview targets for the Codex user-scoped adapter, including the Codex CLI `0.144.x` configuration shape. Use absolute Windows paths for `--config`, `--cache-root`, and, when replacing an existing configuration, `--backup-dir`.
+
+During preview, AAS checks the ownership of the configuration parent directory (normally `%USERPROFILE%\.codex`) and the existing `config.toml` with PowerShell `Get-Acl`; it does not inspect the cache DACL at that stage and does not invoke `icacls`. `AAS_ADAPTER_WINDOWS_ACL_FAILED` now reports the inspected `path`, ACL `phase`, exit `status`, and a bounded diagnostic. An unresolved inherited ACE name is treated as untrusted ACL data rather than crashing identity translation. If preview still fails, use those fields to inspect the named configuration path, not the cache, and do not add `--approve` until preview returns `approvalRequired` with an `approvalDigest`.
+
+## Quick path
+
+1. Run the exact-version MCP configuration command above, review its approval digest, and repeat it with `--approve <approval-digest>`.
+2. Give Codex or Claude the project outcome, target, constraints, and the selection prompt below.
+3. Let the agent search and inspect candidates, choose exact IDs, and call `compose_stack`; review the returned manifest before persisting it.
+4. Persist the selection as `aas-stack.json`, optionally with the separate evidence sidecar for an audit-enabled flow.
+5. Run `aas stack validate`, then `aas stack plan` with explicit absolute paths and integrity inputs.
+6. Review the immutable plan and stop. Apply and recovery remain experimental opt-in paths.
+
 ## Ask the agent to choose the stack
 
 Give the agent the desired outcome and constraints, and leave selection judgment with the agent:
@@ -163,7 +181,7 @@ Stop after reviewing the plan unless you are deliberately participating in contr
 - MCP is local stdio, process-per-session, read-only, offline-capable, and contains no model credentials or telemetry.
 - 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.
+- Core does not impose a semantic skill-count target. The technical manifest maximum is 128 skills, and every current catalog skill remains individually searchable, readable, and available for agent selection. 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.
 - Skill prose is untrusted content and does not gain instruction authority by being returned through MCP.
@@ -172,6 +190,23 @@ Stop after reviewing the plan unless you are deliberately participating in contr
 
 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.
 
+## Current preview status
+
+| Surface | Current status |
+| --- | --- |
+| Published package | Current npm release; AAS Core status is `agent-first-preview` |
+| Catalog search and inspection | Supported preview; local and read-only |
+| Agent-owned composition | Supported preview; Core validates IDs and structure, not semantic suitability |
+| Stack validation and plan preview | Supported preview; no target skill changes |
+| Workbench | Browser-local review of stack and plan artifacts |
+| Selection evidence | Exported and inspected through MCP/CLI contracts; not yet reviewed in Workbench |
+| Apply and recovery | Experimental, explicit opt-in, outside the supported safety claim |
+| Semantic suitability certification | Not provided |
+
+## Why not just search the skills directory?
+
+Direct file search can find candidate prose, but it leaves the result in the conversation. AAS Core adds verified catalog identity, explicit target binding, durable desired state, optional selection evidence, deterministic validation, immutable planning, and dedicated review surfaces. Its value is not choosing better than the coding agent; it is turning the agent's choice into reproducible, inspectable state.
+
 ## Next reads
 
 - [Getting Started](getting-started.md)

package/bundled-skills/docs/users/bundles.md

@@ -1062,4 +1062,4 @@ Found a skill that should be in a bundle? Or want to create a new bundle? [Open
 
 ---
 
-_Last updated: June 2026 | Total Skills: 1,969+ | Total Bundles: 58_
+_Last updated: June 2026 | Total Skills: 1,987+ | Total Bundles: 58_