opencode-skills-collection 4.0.52 → 4.0.54

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

@@ -1,81 +0,0 @@
-# Merge Batch
-
-`merge:batch` is the maintainer shortcut for merging multiple PRs in order while keeping the GitHub-only squash rule and delegating generated follow-up work to the protected canonical-sync PR lane.
-
-## Prerequisites
-
-- Start from a clean `main` that exactly matches `origin/main`.
-- For a real merge, require pull-request-only strict branch protection with the four exact GitHub-Actions-owned checks, administrator enforcement, no applicable ruleset bypass actors, and no merge queue. Dry runs remain available without this server-side prerequisite.
-- Make sure [`.github/MAINTENANCE.md`](../../.github/MAINTENANCE.md) is the governing policy.
-- Have `gh` authenticated with maintainer permissions.
-- Use this only for PRs that are already expected to merge; conflicting PRs still need the manual conflict playbook.
-
-## Basic Usage
-
-```bash
-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 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>
-```
-
-Use `--dry-run` to exercise local classification without approving a run or merging. An abbreviated or stale attestation is rejected.
-
-## CI Intake Contract
-
-- Before dependent required jobs do expensive setup or wait work, `pr-policy` runs the fork-safety classifier from the exact protected-base implementation and fails an unsafe fork diff early.
-- That CI result is fail-fast evidence, not merge authority. `merge:batch` independently recomputes the complete decision from trusted `main` and remains the only command allowed to approve fork runs or merge the PR.
-- `impact_profile` is shadow-only telemetry. It never skips a required job, test, review, or merge gate.
-- Normal source PRs generate derived preview state once in `source-validation`; `artifact-preview` verifies the exact-head manifest and digest instead of generating the tree again.
-- Canonical-sync PRs use the complementary path: `pr-policy` proves the exact reproduced tree, lightweight `source-validation` records that boundary, and `artifact-preview` confirms no generated drift. Final CI and CodeQL still run on the resulting `main` commit.
-- Test timing is observational. Local deterministic sharding requires the explicit `npm run test:local -- --shard-index N --shard-count M` opt-in; required CI remains complete and unsharded.
-
-## Happy Path
-
-`merge:batch` will:
-
-- fetch the exact base/head objects and classify the complete raw Git diff
-- 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
-- allow only exact `source_repo` transitions recorded in the trusted protected-base provenance exception ledger; unrecorded or malformed transitions still fail closed
-- 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 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
-
-## What It Automates
-
-- exact-head required-check polling
-- handoff of post-merge contributor and artifact drift to the canonical-sync PR lane
-
-## What It Does Not Automate
-
-- PR-body rewriting or normalization
-- closing or reopening PRs to refresh metadata or workflow runs
-- conflict resolution on the PR branch
-- manual judgment for risky skill changes
-- 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 or head drift: stale evidence is discarded, the checkout must be refreshed to the current `origin/main`, and the batch must be rerun; there is no automatic retry
-- auto-merge and merge-queue enrollment; deferred merge state is rejected
-
-## When To Stop
-
-Stop and switch to the manual playbook when:
-
-- the PR is `CONFLICTING`
-- `merge:batch` reports a check failure that needs source changes, not maintainer automation
-- the PR needs a manual README credits decision
-- an external PR's local diff contains a symlink, gitlink, executable mode, unknown path/type, oversized blob, or other non-allowlisted change
-- the workflow run cannot be bound to the intended PR number, current head SHA, `pull_request` event, and trusted workflow definition
-- fork approval or branch permissions are missing
-- effective strict protection for `main` cannot be proven
-
-In those cases, follow [Merging Pull Requests](merging-prs.md) and the relevant sections in [MAINTENANCE.md](../../.github/MAINTENANCE.md).

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

@@ -1,79 +0,0 @@
-# Merging Pull Requests
-
-**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 `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 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 `merge:batch`.
-
-### Generated files policy
-
-- Treat `CATALOG.md`, `skills_index.json`, and `data/*.json` as **derived artifacts**, not contributor-owned source files.
-- `README.md` is mixed ownership: contributor prose edits are allowed, but workflow-managed metadata is canonicalized on `main`.
-- If derived files appear in a PR refresh or merge conflict, prefer **`main`'s side** and remove them from the PR branch instead of hand-maintaining them there.
-- Do not block a PR only because shared generated files would be regenerated differently after other merges. `main` auto-syncs the final state after merge.
-- If a skill PR leaves `risk: unknown`, that is not automatically a blocker. Review the actual behavior semantically; do not infer risk from isolated words or rewrite it automatically.
-
-### Steps (maintainer resolves conflicts on the contributor’s branch)
-
-1. **Fetch the PR branch**  
-   `git fetch origin pull/<PR_NUMBER>/head:pr-<PR_NUMBER>`
-2. **Checkout that branch**  
-   `git checkout pr-<PR_NUMBER>`
-3. **Merge `main` into it**  
-   `git merge origin/main`  
-   Resolve any conflicts in the working tree. For generated registry files (`CATALOG.md`, `data/*.json`, `skills_index.json`), prefer `main`'s version and remove them from the contributor branch:
-   `git checkout --theirs CATALOG.md data/catalog.json skills_index.json`
-   If `README.md` conflicts only because of workflow-managed metadata, prefer `main`'s side there too. Keep contributor prose edits when they are real source changes.
-4. **Commit the merge**  
-   `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 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. **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
-
-Ask them to:
-
-```bash
-git checkout <their-branch>
-git fetch origin main
-git merge origin/main
-# resolve conflicts, then drop derived files from the PR if they appear:
-# CATALOG.md, skills_index.json, data/*.json
-git add .
-git commit -m "chore: merge main to resolve conflicts"
-git push origin <their-branch>
-```
-
-Then use the guarded `merge:batch` command. The PR will be **Merged**, not Closed.
-
-## No local-integration exception
-
-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   | 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
-
-- [Merge Batch](merge-batch.md)
-- [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)
-- [GitHub: Merging a PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request)

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

@@ -1,102 +0,0 @@
-# Pull Request Autonomy
-
-This document describes the repository's staged path toward lower-maintenance pull-request handling. The first stage is evidence and routing, not automatic merge.
-
-## Trust Model
-
-Pull-request CI is unprivileged: it has read-only repository permissions and receives no repository secrets. Reports produced there are useful to contributors and maintainers, but they are explicitly advisory because the pull-request checkout can modify the reporting code itself.
-
-Any privileged or local maintainer action must recompute its decision from trusted `main` code against immutable base and head object IDs. It must not consume the pull-request-generated decision artifact as authorization.
-
-`merge:batch` therefore materializes the evaluator from the exact local `main` commit after proving that local `HEAD` equals `origin/main`. It runs that tracked-only evaluator in an isolated Python process; untracked workspace files, pull-request scripts, Python environment overrides, and uploaded artifacts are not part of the authorization path.
-
-## Evidence Artifacts
-
-The `pr-evidence` CI job produces:
-
-- `preflight.json`: changed files, broad change categories, source-only policy state, and pull-request template state;
-- `changed-skills.json`: before/after evidence for changed canonical skills, including audit findings, score, security flags, risk, provenance, and deterministic regression reasons;
-- `decision-manifest.json`: a schema-versioned shadow routing recommendation.
-
-The manifest always contains:
-
-```json
-{
-  "schema_version": 1,
-  "mode": "shadow",
-  "untrusted_advisory": true,
-  "route": "human_review"
-}
-```
-
-The `untrusted_advisory` marker is intentional. No workflow, merge command, or future bot may treat the artifact as privileged authorization.
-
-The `pr-policy` job also reports an `impact_profile` and its reasons. That profile is observational shadow telemetry only: it does not skip, downgrade, or satisfy any required job, test, review, or merge gate.
-
-## Shadow Routes
-
-- `block`: deterministic repository policy failed, such as a newly introduced changed-skill regression or a direct edit to generated artifacts.
-- `human_review`: the change is valid enough to inspect, but it touches canonical skill content, sensitive paths, uncertain provenance/risk, or lacks semantic review.
-- `eligible_for_later_automation`: deterministic evidence found no blocker and the change belongs to a low-risk class. In the current stage this remains advisory and does not enable auto-merge.
-
-Every new or relocated skill and every canonical skill-content change requires maintainer review in v1. A `safe` risk label is not sufficient evidence for automatic merge.
-
-## Fork Review States
-
-For an ordinary fork PR, `pr-policy` materializes the intake implementation from the exact protected base and evaluates fork safety before its dependent required jobs begin expensive setup or waiting. This makes unsafe paths, modes, objects, sizes, and repository identity fail fast in unprivileged CI. It is not authorization: `merge:batch` independently recomputes the full decision from trusted `main` and remains the sole authority for fork-run approval and merge.
-
-The Skill Review workflow separates two outcomes:
-
-- `review`: a semantic review actually ran using trusted base scripts;
-- `manual-review-required`: Tessl credentials or quota were unavailable, or Tessl did not produce a passing semantic result, so a maintainer must review and attest to the exact head SHA.
-
-A successful `manual-review-required` check means only that the requirement was recorded. It is not a successful semantic review.
-
-## Maintainer Recalculation
-
-`merge:batch` must bind workflow approval and human attestation to one full head SHA. It does not rewrite the PR body or close and reopen the PR to manufacture replacement runs. Before approving a waiting fork run, it independently:
-
-1. captures base and head object IDs;
-2. fetches those objects without checking out pull-request code;
-3. computes a complete NUL-delimited raw Git diff with full object IDs and modes;
-4. for external PRs, rejects unsafe paths, modes, symlinks, gitlinks, executable files, unknown types, oversized blobs, incomplete metadata, or non-allowlisted workflows;
-5. verifies workflow event, workflow identity, pull-request number, and head SHA;
-6. recomputes changed-skill evidence over the exact merge-base-to-head record set and requires one-to-one coverage of every skill-content Git record;
-7. rejects operational errors, malformed evidence, incomplete snapshots, score-component regressions, provenance identity regressions, or any other deterministic blocker; an exact `source_repo` rename may pass only when the trusted protected-base ledger records the skill, old slug, new slug, upstream repository ID, verification date, and canonical GitHub URL;
-8. re-reads both pull-request base and head before and after approval and immediately before merge.
-
-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. `merge:batch` does not retry base drift automatically or reuse 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.
-
-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 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.
-
-## Required CI Work Split
-
-For an ordinary source PR, `source-validation` runs validation, tests, security checks, and generated-state refresh once, then uploads a byte-canonical JSON preview manifest listing drift paths and bound to repository, workflow SHA, run ID and attempt, and exact PR head SHA. `artifact-preview` verifies the downloaded manifest, digest, and identity before reporting drift; it does not repeat source generation.
-
-For the protected canonical-sync PR, `pr-policy` already reproduces the exact expected tree from trusted `main`. `source-validation` is therefore a lightweight boundary record, while `artifact-preview` regenerates and confirms that the canonical head has no drift. After protected merge, explicitly dispatched final CI and CodeQL validate the resulting `main` commit.
-
-The test runner emits per-test and summary timing telemetry so maintainers can measure before changing the DAG. Deterministic sharding is available only through an explicit `npm run test:local -- --shard-index N --shard-count M` invocation. Required CI uses the complete unsharded `npm run test` path; neither timing, sharding, nor `impact_profile` removes assurance.
-
-## Protected Canonical Sync
-
-Generated artifacts and contributor credits no longer write directly to `main`. Push and scheduled maintenance workflows regenerate the repository state without persisted checkout credentials, reject any unmanaged drift, and maintain one bot PR from `automation/canonical-repo-state`.
-
-Because GitHub suppresses ordinary workflow recursion for PRs created with `GITHUB_TOKEN`, the trusted writer explicitly dispatches the four required checks on the bot branch. That dispatch is accepted only on the exact branch, only for files declared by the generated-files contract, and only when rerunning `sync:repo-state` produces the exact full Git tree. A trusted waiter binds the open PR to its immutable head, verifies all four exact GitHub Actions checks, confirms that `main` remains protected and unchanged, performs an immediate exact-head squash merge, and explicitly dispatches main CI and CodeQL. Pages remains release-only and must never be dispatched by canonical synchronization. The detailed protection policy is configured and audited with maintainer credentials; the workflow token has no bypass around it.
-
-## Later Phases
-
-Each phase requires evidence from the previous phase before activation:
-
-1. Observe shadow route accuracy and false-positive rates on real pull requests.
-2. Move remaining release writers to protected release pull requests; canonical CI, hygiene, and contributor-sync writers already use the bot pull-request lane.
-3. Keep `main` protected by stable app-bound checks and remove any newly introduced direct writer.
-4. Add schema-validated fork-safe semantic review whose privileged code always comes from the protected base.
-5. Build deterministic release-candidate pull requests with rendering separated from publication.
-6. Expand immutable upstream commit/path/hash provenance. The first narrow delta exception ledger now covers maintainer-verified `source_repo` renames only; broader provenance exceptions remain out of scope.
-7. Consider auto-merge only for empirically proven documentation or metadata classes. New skills, security-sensitive content, workflows, installers, releases, provenance exceptions, and policy changes remain human decisions.
-
-Merge queue is not part of the current plan. The repository is personally owned, and its workflows do not currently support a `merge_group` event.

package/bundled-skills/docs/maintainers/provenance-identity-exceptions.json

@@ -1,14 +0,0 @@
-{
-  "schema_version": 1,
-  "exceptions": [
-    {
-      "skill_id": "modellix",
-      "field": "source_repo",
-      "before": "Modellix/modellix-skill",
-      "after": "Modellix/modellix-plugin",
-      "upstream_repository_id": 1150322983,
-      "verified_at": "2026-07-28",
-      "evidence_url": "https://github.com/Modellix/modellix-plugin"
-    }
-  ]
-}

package/bundled-skills/docs/maintainers/release-notes-7.2.0.md

@@ -1,32 +0,0 @@
-## v7.2.0 - Community PR Harvest & Cleanup (2026-03-08)
-
-**Eight PRs merged: 44 broken skills removed, zebbern attribution restored, Chinese docs, new skills (audit-skills, senior-frontend, shadcn, frontend-slides update, pakistan-payments-stack), and explainable auto-categorization.**
-
-This release cleans up the registry (removal of 44 SKILL.md files that contained only "404: Not Found"), restores `author: zebbern` attribution to 29 security skills, and merges community contributions: Simplified Chinese documentation, audit-skills, senior-frontend and shadcn skills, frontend-slides dependencies and formatting, pakistan-payments-stack for Pakistani SaaS payments, and explainable auto-categorization in the index generator. Bundle references were updated to drop missing skills so reference validation passes.
-
-### New Skills
-
-- **audit-skills** — Audit-safe skills (PR #236)
-- **senior-frontend** — React, Next.js, TypeScript, Tailwind (PR #233)
-- **shadcn** — shadcn/ui ecosystem (PR #233)
-- **pakistan-payments-stack** — JazzCash, Easypaisa, PKR billing (PR #228)
-
-### Improvements
-
-- **Registry cleanup**: 44 broken "404: Not Found" skill files removed (PR #240).
-- **Attribution**: `author: zebbern` restored for 29 security skills (PR #238).
-- **Docs**: frontend-slides updated with missing deps and formatting (PR #234); Simplified Chinese docs added (PR #232).
-- **Index**: Explainable auto-categorization in `generate_index.py` (PR #230).
-- **Bundles**: `data/bundles.json` updated to remove references to removed or missing skills; `npm run validate:references` passes.
-- **Registry**: Now tracking **1,232** skills.
-
-### Credits
-
-- **@munir-abbasi** for Chinese docs (PR #232)
-- **@itsmeares** for senior-frontend, shadcn (PR #233), frontend-slides update (PR #234)
-- **@zebbern** for security skills attribution (PR #238)
-- Contributors behind PRs #228, #230, #236, #240
-
----
-
-_Upgrade: `git pull origin main` or `npx agentic-awesome-skills`._

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

@@ -1,124 +0,0 @@
-# Release Process
-
-This is the maintainer playbook for cutting a repository release. Historical release notes belong in [`CHANGELOG.md`](../../CHANGELOG.md); this file documents the repeatable process.
-
-## Preconditions
-
-- The tracked working tree is clean.
-- You are on `main`.
-- `CHANGELOG.md` already contains the release section you intend to publish.
-- README counts, badges, and acknowledgements are up to date.
-
-## Release Checklist
-
-1. Run the scripted preflight:
-
-```bash
-npm run release:preflight
-```
-
-This preflight now runs the deterministic `sync:release-state` flow, refreshes the tracked web assets in `apps/web-app/public`, executes the local test suite, installs the web-app dependencies, runs the web-app build, and performs `npm pack --dry-run --json` so release tags are validated against the same artifact path used later in CI.
-
-The active CI/release contract also expects:
-
-- Python dependencies to come from `tools/requirements.txt`,
-- the web app coverage job (`npm run app:test:coverage`) to stay green,
-- and `npm run security:docs` to pass without relying on non-blocking audit warnings.
-
-2. Mandatory documentation hardening (repo-wide SKILL.md security scan):
-
-```bash
-npm run security:docs
-```
-
-This is required so every release validates repo-wide risky command patterns and inline token-like examples before publishing.
-
-3. Optional hardening pass:
-
-```bash
-npm run validate:strict
-```
-
-Use this as a diagnostic signal. It is useful for spotting legacy quality debt, but it is not yet the release blocker for the whole repository.
-
-4. Update release-facing docs:
-
-- 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 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:
-
-```bash
-npm run release:prepare -- X.Y.Z
-```
-
-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, every eligible Agent Plugins bundle manifest, 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
-
-Prerelease versions use the same protected flow, for example `15.0.0-rc.1`. They must have their own exact changelog section.
-
-6. Merge the release PR through required checks, update local `main`, then publish the GitHub release:
-
-```bash
-npm run release:publish -- X.Y.Z
-```
-
-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:
-
-```bash
-npm publish --tag latest
-```
-
-Normally this still happens via the existing GitHub release workflow after the GitHub release is published. The workflow publishes stable versions explicitly to npm's `latest` dist-tag and prerelease versions explicitly to `next`; it fails closed on an invalid version. Verify both tags after a prerelease so `latest` remains on the last stable release.
-
-```bash
-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, eligible Agent Plugins bundle 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;
-- dispatch Pages only from the exact immutable `vX.Y.Z` release tag, never from `main` or another branch, and require the tag, package version, and published GitHub Release to identify the same commit before build work begins;
-- 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:
-
-- PRs stay source-only.
-- After merge, the `main` workflow may open or update `automation/canonical-repo-state`; it never pushes generated files directly to `main`.
-- The bot PR is only allowed to stage files resolved from `tools/scripts/generated_files.js --include-mixed`.
-- Its explicitly dispatched required checks require both managed-only paths and an exact converged Git tree before an immediate protected merge.
-- If repo-state sync leaves any unmanaged tracked or untracked drift, the workflow fails instead of pushing a partial fix.
-- The scheduled hygiene workflow follows the same contract and shares the same concurrency group so only one canonical sync writer runs at a time.
-- Between the protected release merge and its tag, the only canonical-sync successor subjects accepted by the release contract are exactly `chore: synchronize canonical repository state` and `[skip pages] chore: synchronize canonical repository state`. The latter is the durable audit marker that the successor must not trigger the release-only Pages lane; both remain subject to the managed-only range validation.
-
-## Rollback Notes
-
-- If the release tag is wrong, delete the tag locally and remotely before republishing.
-- If generated files drift after tagging, cut a follow-up patch release instead of mutating a published tag.
-- If npm publish fails after tagging, fix the issue, bump the version, and publish a new release instead of reusing the same version.

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

@@ -1,133 +0,0 @@
-# Repo Growth SEO Playbook
-
-This document keeps the repository's GitHub-facing discovery copy aligned with the SEO-focused user docs.
-
-## Current position
-
-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 the current catalog.
-
-Key framing:
-
-- AAS Core as the primary product;
-- local MCP and CLI as the agent-facing and operator-facing interfaces;
-- `aas-stack.json` and the immutable plan as durable artifacts;
-- GitHub as the canonical source, with the hosted catalog and Workbench as discovery and review surfaces;
-- catalog, plugins, bundles, workflows, and direct installers as supporting content and distribution.
-
-## GitHub About settings
-
-Preferred description:
-
-> 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:
-
-> `https://github.com/sickn33/agentic-awesome-skills`
-
-Preferred social preview:
-
-- lead with `AAS Core` and the profile → stack → plan flow;
-- present `2,108+ 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.
-
-Preferred topics:
-
-- `antigravity`
-- `antigravity-skills`
-- `claude-code`
-- `claude-code-skills`
-- `cursor`
-- `cursor-skills`
-- `codex-cli`
-- `codex-skills`
-- `gemini-cli`
-- `gemini-skills`
-- `kiro`
-- `ai-agents`
-- `ai-agent-skills`
-- `agent-skills`
-- `agentic-skills`
-- `developer-tools`
-- `skill-library`
-- `ai-workflows`
-- `ai-coding`
-- `mcp`
-
-## Release notes checklist
-
-When publishing a release:
-
-- include a title that names the main user-facing use case, not only the internal codename;
-- mention newly supported tools, new bundles, and onboarding improvements early;
-- link back to the most relevant docs in `docs/users/`;
-- keep the first paragraph useful to someone who found the release page from Google.
-
-Suggested opening structure:
-
-1. one-sentence release summary with tool/use-case language;
-2. top changes that matter to new and returning users;
-3. links to install, bundles, workflows, and relevant comparison pages if needed.
-
-Suggested release template:
-
-```md
-## [VERSION] - YYYY-MM-DD - "User-facing title"
-
-> AAS Core and supporting catalog update for local, explainable coding-agent skill stacks.
-
-Start here:
-
-- AAS Core guide: `docs/users/aas-core.md`
-- Direct skill distribution: `npx agentic-awesome-skills`
-- Choose your tool: `README.md#choose-your-tool`
-- Specialized plugins: `README.md#recommended-specialized-plugins`
-- Bundles: `docs/users/bundles.md`
-- Workflows: `docs/users/workflows.md`
-
-## What's new
-
-- New skills with clear use-case language
-- New bundles, workflows, or onboarding docs
-- New tool support or compatibility improvements
-
-## Improvements
-
-- Reliability and installer updates
-- Quality, validation, or metadata updates
-- Security or maintenance work that affects users
-
-## Who should care
-
-- Claude Code users
-- Cursor users
-- Codex CLI users
-- Gemini CLI users
-
-## Credits
-
-- Contributors and merged PRs
-```
-
-## Discussions checklist
-
-Suggested pinned discussion topics:
-
-- `Start here: compose a project stack with AAS Core`
-- `Choose between an agent-selected Core stack and direct distribution`
-- `How the catalog, plugins, bundles, and workflows support Core`
-
-Discussion posts should:
-
-- link to the tool-specific docs in `docs/users/`;
-- answer one search intent cleanly;
-- end with a single clear next step such as install, star, or compare.
-
-## Content maintenance rules
-
-- Keep README, GitHub About description, and tool-specific user docs semantically aligned.
-- Avoid cannibalization by giving each user doc a distinct primary intent.
-- Prefer honest comparisons over absolute claims.
-- Do not use SEM or paid language in discovery docs unless strategy changes later.

package/bundled-skills/docs/maintainers/rollback-procedure.md

@@ -1,43 +0,0 @@
-# Rollback Procedure
-
-Use this when a structural refactor, generated artifact refresh, or release prep needs to be backed out safely.
-
-## Before Rolling Back
-
-- Capture the current branch name with `git branch --show-current`.
-- Review changed files with `git status --short`.
-- Decide whether you need to keep any generated files before reverting.
-
-## Safe Rollback Flow
-
-1. Create a temporary safety branch:
-
-```bash
-git switch -c rollback-safety-check
-```
-
-2. Verify the repository still reports the expected changed files:
-
-```bash
-git status --short
-```
-
-3. Switch back to the original branch:
-
-```bash
-git switch -
-```
-
-4. If you need to discard only this refactor later, revert the relevant commit(s) or restore specific files explicitly:
-
-```bash
-git restore README.md CONTRIBUTING.md package.json package-lock.json
-git restore --staged README.md CONTRIBUTING.md package.json package-lock.json
-```
-
-5. If the refactor has already been committed, prefer `git revert <commit>` over history-rewriting commands.
-
-## Notes
-
-- Avoid `git reset --hard` unless you have explicit approval and understand the impact on unrelated work.
-- For generated artifacts, regenerate after rollback with the standard scripts instead of manually editing them.