opencode-skills-collection 4.0.10 → 4.0.11

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

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "updatedAt": "2026-07-24T01:26:11.385Z",
+  "updatedAt": "2026-07-25T01:26:09.879Z",
   "entries": [
     "00-andruia-consultant",
     "007",
@@ -1600,6 +1600,7 @@
     "seo-content-refresher",
     "seo-content-writer",
     "seo-dataforseo",
+    "seo-drift",
     "seo-forensic-incident-response",
     "seo-fundamentals",
     "seo-geo",

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

@@ -51,6 +51,10 @@ Before changing anything:
 3. Run checks in parallel where independent.
    - Use the repository validation, test, docs-security, source-credit, reference, warning-budget, and targeted app checks required by the changed files.
    - Fix deterministic policy failures in the source; do not wait for them as if they were flaky CI.
+   - Treat `pr-policy` fork classification from the exact protected-base implementation as an unprivileged fail-fast gate before dependent work, never as approval authority. `merge:batch` must still recompute the current trusted decision before approving any fork run or merging.
+   - Treat `impact_profile` as shadow-only telemetry. It must not skip, downgrade, or satisfy any required check.
+   - For ordinary source PRs, require `source-validation` to generate preview state once and `artifact-preview` to verify the manifest bound to the exact head and run identity. For canonical-sync PRs, rely on `pr-policy` exact-tree reproduction, keep `source-validation` lightweight, require `artifact-preview` to confirm no drift, and retain final CI and CodeQL on the merged `main` commit.
+   - Keep timing observational and test sharding opt-in. Required CI must continue to run the full unsharded `npm run test`; deterministic local shards may be used only through `npm run test:local -- --shard-index N --shard-count M`.
 
 4. Merge accepted source PRs in conflict-aware order.
    - Run a dry classification first when useful.
@@ -60,10 +64,10 @@ Before changing anything:
      npm run merge:batch -- --prs <PR_LIST> --reviewed-head <FULL_HEAD_SHA>
      ```
 
-   - `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.
+   - `merge:batch` does not rewrite the PR body and does not close or reopen the PR. It evaluates the current immutable PR tuple and may approve only workflow runs bound to that PR and exact head SHA.
    - 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`.
+   - If the PR head or base changes, discard stale evidence, refresh to the current `origin/main`, and rerun the batch. The command does not retry base drift automatically.
 
 5. Converge canonical state once after the source batch.
    - Wait for the protected `automation/canonical-repo-state` PR.
@@ -119,7 +123,7 @@ Every stable or prerelease version requires full release alignment. Creating the
 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.
+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 from the exact immutable `vX.Y.Z` tag. Never dispatch Pages from `main` or another branch. 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.

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,987+ skills."
+description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,988+ skills."
 ---
 
-# Jetski/Cortex + Gemini: safe integration with 1,987+ skills
+# Jetski/Cortex + Gemini: safe integration with 1,988+ 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,987+ skills, this approach fills the context window before user messages are even added, causing truncation.
+With 1,988+ 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,987+ skills installed.
+This pattern avoids context overflow when you have 1,988+ skills installed.
 
 Manifest contract references:
 

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

@@ -26,6 +26,15 @@ 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:
@@ -46,12 +55,14 @@ Use `--dry-run` to exercise local classification without approving a run or merg
 
 ## 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 drift: stale evidence is discarded and the batch must be rerun
+- 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

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

@@ -31,6 +31,8 @@ The manifest always contains:
 
 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.
@@ -41,6 +43,8 @@ Every new or relocated skill and every canonical skill-content change requires m
 
 ## 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;
@@ -50,7 +54,7 @@ A successful `manual-review-required` check means only that the requirement was
 
 ## Maintainer Recalculation
 
-`merge:batch` must bind workflow approval and human attestation to one full head SHA. When it refreshes a PR body by closing and reopening the PR, it also records the pre-refresh workflow-run IDs and accepts checks only from post-refresh check suites. A shared head SHA is not sufficient evidence of freshness because multiple `pull_request` events can exist for the same commit. Before approving a waiting fork run, it independently:
+`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;
@@ -61,7 +65,7 @@ A successful `manual-review-required` check means only that the requirement was
 7. rejects operational errors, malformed evidence, incomplete snapshots, score-component regressions, provenance identity regressions, or any other deterministic blocker;
 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. 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.
+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.
 
@@ -69,11 +73,19 @@ For any tracked change under a canonical `skills/<skill-id>/**` subtree, the mai
 
 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, Pages, and CodeQL. The detailed protection policy is configured and audited with maintainer credentials; the workflow token has no bypass around it.
+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
 

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

@@ -98,6 +98,7 @@ A stable or prerelease version is not complete when only its tag, GitHub Release
 - 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;
+- 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.
@@ -114,6 +115,7 @@ A release request covers updates to existing AAS MCP host entries only. Creating
 - 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
 

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

@@ -29,7 +29,7 @@ Preferred homepage:
 Preferred social preview:
 
 - lead with `AAS Core` and the profile → stack → plan flow;
-- present `1,987+ Agentic Skills` as supporting catalog evidence, not a second product;
+- present `1,988+ 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,987+ skills from the skills directory
+- All 1,988+ skills from the skills directory
 
 ## When to Update
 

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

@@ -30,7 +30,7 @@ AAS MCP does not scan the repository and does not decide which skills are best.
 > **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@15.3.0 -- aas mcp configure \
+npm exec --yes --ignore-scripts --package=agentic-awesome-skills@15.4.0 -- aas mcp configure \
   --host codex \
   --scope user \
   --config /absolute/path/to/codex/config.toml \

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,987+ | Total Bundles: 58_
+_Last updated: June 2026 | Total Skills: 1,988+ | Total Bundles: 58_

package/bundled-skills/docs/users/claude-code-skills.md

@@ -17,7 +17,7 @@ Configure AAS Core for Claude Code, describe the task and constraints, let Claud
 - It lets Claude search the verified local catalog without loading the full library into context.
 - It preserves Claude's exact selection without using metadata as an eligibility gate.
 - It keeps MCP discovery read-only and CLI changes approval-gated.
-- It includes 1,987+ skills instead of a narrow single-domain starter pack.
+- It includes 1,988+ skills instead of a narrow single-domain starter pack.
 - It supports the standard `.claude/skills/` path and the Claude Code plugin marketplace flow.
 - It also ships generated bundle plugins so teams can install focused packs like `Essentials` or `Security Developer` from the marketplace metadata.
 - It includes onboarding docs, bundles, and workflows so new users do not need to guess where to begin.

package/bundled-skills/docs/users/gemini-cli-skills.md

@@ -12,7 +12,7 @@ Install into the Gemini skills path, then ask Gemini to apply one skill at a tim
 
 - It installs directly into the expected Gemini skills path.
 - It includes both core software engineering skills and deeper agent/LLM-oriented skills.
-- It helps new users get started with bundles and workflows rather than forcing a cold start from 1,987+ files.
+- It helps new users get started with bundles and workflows rather than forcing a cold start from 1,988+ files.
 - It is useful whether you want a broad internal skill library or a single repo to test many workflows quickly.
 
 ## Install Gemini CLI Skills

package/bundled-skills/docs/users/kiro-integration.md

@@ -18,7 +18,7 @@ Kiro is AWS's agentic AI IDE that combines:
 
 Kiro's agentic capabilities are enhanced by skills that provide:
 
-- **Domain expertise** across 1,987+ specialized areas
+- **Domain expertise** across 1,988+ specialized areas
 - **Best practices** from Anthropic, OpenAI, Google, Microsoft, and AWS
 - **Workflow automation** for common development tasks
 - **AWS-specific patterns** for serverless, infrastructure, and cloud architecture

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

@@ -39,7 +39,7 @@ If you came in through a **Claude Code** or **Codex** plugin instead of AAS Core
 
 When you ran `npx agentic-awesome-skills` or cloned the repository, you:
 
-✅ **Downloaded 1,987+ skill files** to your computer (default: `~/.agents/skills/`; or a custom path like `~/.agent/skills/` if you used `--path`)
+✅ **Downloaded 1,988+ skill files** to your computer (default: `~/.agents/skills/`; or a custom path like `~/.agent/skills/` if you used `--path`)
 ✅ **Made them available** to your AI assistant
 ❌ **Did NOT enable them all automatically** (they're just sitting there, waiting)
 
@@ -231,7 +231,7 @@ Let's actually use a skill right now. Follow these steps:
 
 ## Direct-install Step 5: Pick Skills Manually
 
-Don't try to use all 1,987+ skills at once. Here's a sensible approach:
+Don't try to use all 1,988+ skills at once. Here's a sensible approach:
 
 If you want a tool-specific starting point before choosing skills, use:
 
@@ -362,7 +362,7 @@ Usually no, but if your AI doesn't recognize a skill:
 
 ### "Can I load all skills into the model at once?"
 
-No. Even though you have 1,987+ skills installed locally, you should **not** concatenate every `SKILL.md` into a single system prompt or context block.
+No. Even though you have 1,988+ skills installed locally, you should **not** concatenate every `SKILL.md` into a single system prompt or context block.
 
 The intended pattern is:
 

package/bundled-skills/docs/users/visual-guide.md

@@ -40,7 +40,7 @@ agentic-awesome-skills/
 ├── 📄 CONTRIBUTING.md                  ← Contributor workflow
 ├── 📄 CATALOG.md                       ← Full generated catalog
 │
-├── 📁 skills/                          ← 1,987+ skills live here
+├── 📁 skills/                          ← 1,988+ skills live here
 │   │
 │   ├── 📁 brainstorming/
 │   │   └── 📄 SKILL.md                 ← Skill definition
@@ -53,7 +53,7 @@ agentic-awesome-skills/
 │   │   └── 📁 2d-games/
 │   │       └── 📄 SKILL.md             ← Nested skills also supported
 │   │
-│   └── ... (1,987+ total)
+│   └── ... (1,988+ total)
 │
 ├── 📁 apps/
 │   └── 📁 web-app/                     ← Interactive browser
@@ -106,7 +106,7 @@ agentic-awesome-skills/
 
 ```
                     ┌─────────────────────────┐
-                    │  1,987+ SKILLS          │
+                    │  1,988+ SKILLS          │
                     └────────────┬────────────┘
                                  │
         ┌────────────────────────┼────────────────────────┐
@@ -207,7 +207,7 @@ If you want a workspace-style manual install instead, cloning into `.agent/skill
 │   ├── 📁 brainstorming/                 │
 │   ├── 📁 stripe-integration/            │
 │   ├── 📁 react-best-practices/          │
-│   └── ... (1,987+ total)                │
+│   └── ... (1,988+ total)                │
 └─────────────────────────────────────────┘
 ```
 

package/bundled-skills/docs/vietnamese/CONTRIBUTING.vi.md

@@ -221,7 +221,7 @@ fix: correct typo in stripe-integration skill
 ### Bạn mới sử dụng Git/GitHub?
 
 - [Hướng dẫn Hello World của GitHub](https://guides.github.com/activities/hello-world/)
-- [Cơ bản về Git](https://git-scm.com/book/en/v2/Getting-Started-Git-Basics)
+- [Cơ bản về Git](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository)
 
 ### Bạn mới sử dụng Markdown?
 

package/bundled-skills/loki-mode/examples/todo-app-generated/frontend/package-lock.json

@@ -785,9 +785,9 @@
       }
     },
     "node_modules/postcss": {
-      "version": "8.5.15",
-      "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.5.15.tgz",
-      "integrity": "sha512-FfR8sjd4em2T6fb3I2MwAJU7HWVMr9zba+enmQeeWFfCbm+UOC/0X4DS8XtpUTMwWMGbjKYP7xjfNekzyGmB3A==",
+      "version": "8.5.18",
+      "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.5.18.tgz",
+      "integrity": "sha512-xdB1oSLHbz1vRWgCDalrCqEFTWzFlhqFC5tIHLMOSUIjhm3XXQ1qrFy8S/ESr1JYRRXqM3c1QFiMZUJdUTqyMQ==",
       "dev": true,
       "funding": [
         {

package/bundled-skills/seo-drift/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: seo-drift
+description: "Snapshot a site's SEO state and detect ranking, indexation, metadata, canonical, robots, schema, and on-page regressions over time."
+category: marketing
+risk: safe
+source: https://github.com/nowork-studio/NotFair/tree/main/seo/seo-drift
+source_repo: nowork-studio/NotFair
+source_type: official
+date_added: "2026-07-22"
+author: nowork-studio
+tags: [seo, monitoring, search-console, technical-seo, regression-testing]
+tools: [claude, cursor, gemini, codex]
+license: MIT
+license_source: https://github.com/nowork-studio/NotFair/blob/main/LICENSE
+---
+
+# SEO Drift Monitoring
+
+## Overview
+
+Capture a known-good SEO baseline and compare later snapshots against it so regressions become visible. The skill combines search-performance data with live on-page checks to surface ranking drops, deindexation, overwritten metadata, directive changes, and missing schema before they quietly cost traffic.
+
+This portable version is adapted from the official [`seo-drift` skill in NotFair](https://github.com/nowork-studio/NotFair/tree/main/seo/seo-drift).
+
+## When to Use
+
+Use this skill when the user asks to:
+
+- baseline or monitor a site's SEO over time;
+- check whether a migration, redesign, CMS change, or redeploy damaged SEO;
+- compare current search performance and page metadata with a prior snapshot;
+- investigate titles, descriptions, canonicals, robots directives, or schema that changed unexpectedly;
+- identify rankings or indexed pages that disappeared.
+
+For a one-time comprehensive SEO audit with no historical comparison, use a general SEO audit skill instead.
+
+## Prerequisites
+
+Before capturing data:
+
+1. Confirm the site and the key URLs in scope. Prefer top organic landing pages, commercial pages, and any URLs affected by a recent release.
+2. Confirm baseline or compare mode. If no prior snapshot exists, use baseline mode and explain that there is nothing to compare yet.
+3. Ask where the snapshot should be stored. Use a local `seo-drift/` directory alongside the user's other audit reports only after confirming the intended project or reports location.
+4. Prefer a connected Google Search Console source for query, page, position, impression, click, and indexation signals.
+5. Use a browser or web-fetch capability for current on-page values. Respect robots directives and avoid high-volume crawling.
+
+If Search Console is unavailable, continue only with the on-page comparison and state that ranking and indexation drift could not be measured. Never infer missing Search Console values from a live crawl.
+
+## How It Works
+
+### 1. Choose the comparison boundary
+
+Record:
+
+- the site property and snapshot date supplied by the user or runtime;
+- whether the snapshot is a baseline or comparison;
+- the prior snapshot used for comparison, when applicable;
+- the exact URL set and search-data window;
+- any known migration, release, or CMS event that may explain expected changes.
+
+Do not invent dates or silently compare mismatched date windows.
+
+### 2. Capture the current snapshot
+
+For the agreed URL set, collect:
+
+- **Search performance:** query and page clicks, impressions, click-through rate, and average position for a stable window;
+- **Indexation:** indexed status or coverage evidence for each key URL when the connected source exposes it;
+- **Metadata:** title, meta description, and H1;
+- **Directives:** canonical URL, robots header, and meta-robots value;
+- **Structured data:** schema types present;
+- **Content shape:** word count and another stable content fingerprint or summary useful for detecting large changes.
+
+Persist both the values and their source. Keep unavailable fields as `unknown`; do not coerce them to zero or absent.
+
+### 3. Diff against the previous baseline
+
+Surface changes in five groups:
+
+1. **Rankings:** queries that dropped by the agreed threshold or disappeared from the observed window.
+2. **Indexation:** key pages that lost indexed status or a material drop in indexed-page count.
+3. **Metadata:** titles, descriptions, or H1s that changed, became blank, or fell back to a generic template.
+4. **Directives:** canonicals that changed or disappeared, and newly introduced `noindex` directives.
+5. **Schema:** structured-data types that disappeared from pages where they previously existed.
+
+Separate expected content changes from unexplained regressions. A changed value is evidence of drift, not proof of causation.
+
+### 4. Rank severity
+
+Use these default levels:
+
+- **Critical:** an important page is newly `noindex`, deindexed, or canonicalized to an unintended URL.
+- **Warning:** a material ranking decline, lost query visibility, blank or generic metadata, or missing schema.
+- **Info:** an expected content or metadata change with no observed search-performance harm.
+
+Put directive and indexation failures first because they can suppress the entire page regardless of content quality.
+
+### 5. Report and preserve evidence
+
+For every reported change, include:
+
+- URL and field or metric;
+- before and after values;
+- comparison dates and data window;
+- severity and likely cause, clearly labeled as an inference;
+- the next verification or repair action.
+
+End by offering to create a new baseline only after the user confirms that intended changes and critical repairs are complete.
+
+## Example
+
+```text
+User: Baseline SEO for https://example.com before Friday's redesign. Track /, /pricing, and /docs.
+
+Agent: I will capture a dated baseline for those three URLs, using Search Console for
+query/page performance and live fetches for metadata, directives, schema, and content
+shape. I will save it under the confirmed reports directory and use the same URL set and
+Search Console window for the post-redesign comparison.
+```
+
+## Best Practices
+
+- Keep the key URL set stable so comparisons remain interpretable.
+- Compare equivalent Search Console windows and call out incomplete or delayed data.
+- Preserve raw snapshot evidence separately from the narrative report.
+- Treat missing data as unknown, not as a decline.
+- Verify a critical directive or canonical change with a second live fetch before escalating it.
+- Label likely causes as hypotheses until repository, CMS, deployment, or change-history evidence confirms them.
+
+## Limitations
+
+- Search Console data can lag and may suppress low-volume queries.
+- A live crawl cannot prove that Google has indexed a page or adopted its canonical.
+- Position changes can reflect seasonality, SERP composition, location, device mix, or competitors rather than a site regression.
+- The skill does not replace server-log analysis, full-crawl tooling, or manual review of a large migration.
+- Comparisons are unreliable when URL sets, date windows, locales, or device filters differ without normalization.
+
+## Security & Safety Notes
+
+- Write snapshots only inside the user-confirmed project or reports directory.
+- Do not store authentication tokens, cookies, or raw credentials in snapshots.
+- Use read-only Search Console access and non-mutating page fetches.
+- Avoid aggressive crawling; honor access restrictions and keep requests bounded to the agreed scope.
+- Do not change production metadata, canonicals, robots directives, or deployment settings without a separate, explicit implementation request.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-skills-collection",
-  "version": "4.0.10",
+  "version": "4.0.11",
   "description": "OpenCode CLI plugin that automatically downloads and keeps skills up to date.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",