opencode-skills-collection 4.0.0 → 4.0.1

package/bundled-skills/docs/maintainers/ci-drift-fix.md

@@ -23,7 +23,7 @@ The workflow expects the repository to be clean after those sync steps finish. A
 ## Pull Requests vs Main
 
 - **Pull requests**: PRs are now **source-only**. Contributors should not commit derived registry artifacts (`CATALOG.md`, `skills_index.json`, `data/*.json`). CI blocks those direct edits and reports generated drift as an informational preview only.
-- **`main` pushes**: drift is still strict. `main` must end the workflow clean after the auto-sync step.
+- **`main` pushes**: drift is still strict. The workflow may publish only managed drift through `automation/canonical-repo-state`; required CI must reproduce that PR as the exact expected Git tree before an immediate protected merge.
 
 ## How to Fix on `main`
 
@@ -40,23 +40,25 @@ The workflow expects the repository to be clean after those sync steps finish. A
    git diff
    ```
 
-3. If the sync produced only canonical/generated changes, stage and commit them. Prefer the generated-files contract instead of a hand-maintained file list:
+3. If the sync produced only canonical/generated changes, open a source-free PR rather than pushing to protected `main`. Prefer the generated-files contract instead of a hand-maintained file list:
 
    ```bash
    node tools/scripts/generated_files.js --include-mixed
    git add $(node tools/scripts/generated_files.js --include-mixed)
+   git switch -c chore/canonical-artifact-repair
    git commit -m "chore: sync canonical artifacts"
-   git push
+   git push -u origin chore/canonical-artifact-repair
+   gh pr create --base main --fill
    ```
 
-4. If `sync:repo-state` leaves unrelated or unmanaged drift, stop and inspect it. The bot on `main` is only allowed to push the canonical/generated subset; anything else should fail the workflow instead of being silently auto-committed.
+4. If `sync:repo-state` leaves unrelated or unmanaged drift, stop and inspect it. The bot is only allowed to publish the canonical/generated subset; anything else must fail instead of being silently included.
 
 ## Maintainer guidance for PRs
 
 - Validate the source change, not the absence of committed generated artifacts.
 - If a contributor PR includes direct edits to `CATALOG.md`, `skills_index.json`, or `data/*.json`, ask them to drop those files from the PR or remove them while refreshing the branch.
 - If merge conflicts touch generated registry files, keep `main`'s version for those files and let `main` auto-sync the final generated artifact set after merge.
-- If CI on `main` later creates a bot commit with `[ci skip]`, that is expected only for the canonical/generated subset. It is not a license to push arbitrary extra drift.
+- If CI on `main` detects drift, expect one `chore: synchronize canonical repository state` PR. Its special lane still requires managed-only paths and exact reproducibility; it is not a license to include arbitrary changes.
 
 **Summary**:
 Use generator drift as a hard failure only on `main`. On PRs, the contract is simpler: source-only changes are reviewed, generated output is previewed, and `main` produces the final canonical artifact set.

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

@@ -1,10 +1,11 @@
 # Merge Batch
 
-`merge:batch` is the maintainer shortcut for merging multiple PRs in order while keeping the GitHub-only squash rule and the post-merge contributor sync.
+`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`.
+- 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.
@@ -17,31 +18,44 @@ 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:
+
+```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.
+
 ## Happy Path
 
 `merge:batch` will:
 
 - refresh the PR body when the Quality Bar checklist is missing
 - close and reopen the PR if stale metadata needs a fresh `pull_request` event
-- approve fork runs waiting on `action_required`
+- 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
+- approve fork runs waiting on `action_required` only when every path, mode, object, size, and workflow identity is allowlisted
 - wait for the fresh required checks on the current head SHA
-- merge with GitHub squash merge
-- pull `main`, run `sync:contributors`, and push a README-only follow-up if needed
+- 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
 
 - PR body normalization against the repository template
 - stale PR metadata refresh
 - required-check polling for the current PR head
-- the post-merge contributor sync step
-- the retry loop for `Base branch was modified`
+- handoff of post-merge contributor and artifact drift to the canonical-sync PR lane
 
 ## What It Does Not Automate
 
 - conflict resolution on the PR branch
 - manual judgment for risky skill changes
+- semantic review when the distinct `manual-review-required` check is present
 - 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
+- auto-merge and merge-queue enrollment; deferred merge state is rejected
 
 ## When To Stop
 
@@ -50,6 +64,9 @@ 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
+- the 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/pr-autonomy.md

@@ -0,0 +1,89 @@
+# 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.
+
+## 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
+
+The Skill Review workflow separates three outcomes:
+
+- `review`: a semantic review actually ran using trusted base scripts;
+- `manual-review-required`: repository secrets were unavailable to a fork, so a maintainer must review and attest to the exact head SHA;
+- `missing-review-credentials`: an internal branch expected semantic-review credentials but none were configured, so the check fails closed.
+
+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. 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. 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;
+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.
+
+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.
+
+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.
+
+## 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.
+
+## 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. Add immutable upstream commit/path/hash provenance and a delta-based exception ledger.
+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/release-notes-7.2.0.md

@@ -29,4 +29,4 @@ This release cleans up the registry (removal of 44 SKILL.md files that contained
 
 ---
 
-_Upgrade: `git pull origin main` or `npx antigravity-awesome-skills`._
+_Upgrade: `git pull origin main` or `npx agentic-awesome-skills`._

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

@@ -49,7 +49,7 @@ Use this as a diagnostic signal. It is useful for spotting legacy quality debt,
 - 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 maintainers used `npm run sync:risk-labels` or a comparable cleanup flow during the cycle, make sure the maintainer docs still describe the current audit -> sync -> repo-state loop.
 
-5. Prepare the release commit and tag locally:
+5. Prepare the protected release PR:
 
 ```bash
 npm run release:prepare -- X.Y.Z
@@ -62,16 +62,16 @@ This command:
 - runs the full release suite
 - refreshes release metadata in `README.md`
 - stages canonical release files
-- creates `chore: release vX.Y.Z`
-- creates the local tag `vX.Y.Z`
+- creates and pushes `release/vX.Y.Z`
+- opens a release PR containing the scripted canonical release state
 
-6. Publish the GitHub release:
+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 pushes `main`, pushes `vX.Y.Z`, and creates the GitHub release object from the matching `CHANGELOG.md` section.
+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. It never pushes `main` directly and can be retried after a partial tag/release failure.
 
 7. Publish to npm if needed:
 
@@ -84,12 +84,12 @@ That workflow now reruns `sync:release-state`, installs Python dependencies from
 
 ## Canonical Sync Bot
 
-`main` still uses the repository's auto-sync model for canonical generated artifacts, but with a narrow contract:
+`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 commit generated canonical files directly to `main` with `[ci skip]`.
-- Those bot commits still skip CI, so the sync contract must stay narrow and predictable: only canonical/generated files may be staged, and any unmanaged drift must fail the workflow instead of being silently pushed.
-- The bot commit is only allowed to stage files resolved from `tools/scripts/generated_files.js --include-mixed`.
+- 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.
 

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:
 
-> Installable GitHub library of 1,935+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and other AI coding assistants.
+> Installable GitHub library of 1,958+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and other AI coding assistants.
 
 Key framing:
 
@@ -20,15 +20,15 @@ Key framing:
 
 Preferred description:
 
-> Installable GitHub library of 1,935+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and more. Includes installer CLI, bundles, workflows, and official/community skill collections.
+> Installable GitHub library of 1,958+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and more. Includes installer CLI, bundles, workflows, and official/community skill collections.
 
 Preferred homepage:
 
-> `https://github.com/sickn33/antigravity-awesome-skills`
+> `https://github.com/sickn33/agentic-awesome-skills`
 
 Preferred social preview:
 
-- use a clean preview image that says `1,935+ Agentic Skills`;
+- use a clean preview image that says `1,958+ Agentic Skills`;
 - mention Claude Code, Cursor, Codex CLI, and Gemini CLI;
 - avoid dense text and tiny logos that disappear in social cards.
 
@@ -79,7 +79,7 @@ Suggested release template:
 
 Start here:
 
-- Install: `npx antigravity-awesome-skills`
+- Install: `npx agentic-awesome-skills`
 - Choose your tool: `README.md#choose-your-tool`
 - Specialized plugins: `README.md#recommended-specialized-plugins`
 - Bundles: `docs/users/bundles.md`

package/bundled-skills/docs/maintainers/skills-date-tracking.md

@@ -209,7 +209,7 @@ Make sure the date is in `YYYY-MM-DD` format:
 
 Make sure you're running from the project root:
 ```bash
-cd path/to/antigravity-awesome-skills
+cd path/to/agentic-awesome-skills
 python tools/scripts/manage_skill_dates.py list
 ```
 

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

@@ -1,6 +1,6 @@
 # Skills Update Guide
 
-This guide explains how to update the skills in the Antigravity Awesome Skills web application.
+This guide explains how to update the skills in the Agentic Awesome Skills web application.
 
 ## Automatic Updates (Recommended)
 
@@ -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,935+ skills from the skills directory
+- All 1,958+ skills from the skills directory
 
 ## When to Update
 

package/bundled-skills/docs/users/{antigravity-awesome-skills-vs-awesome-claude-skills.md → agentic-awesome-skills-vs-awesome-claude-skills.md}

@@ -1,17 +1,17 @@
-# Antigravity Awesome Skills vs Awesome Claude Skills
+# Agentic Awesome Skills vs Awesome Claude Skills
 
-If you are comparing **Antigravity Awesome Skills** with **Awesome Claude Skills**, the decision usually comes down to breadth vs curation.
+If you are comparing **Agentic Awesome Skills** with **Awesome Claude Skills**, the decision usually comes down to breadth vs curation.
 
 For clarity: the repository many people still refer to as `awesome-claude-skills` now lives at [VoltAgent/awesome-agent-skills](https://github.com/VoltAgent/awesome-agent-skills).
 
 ## TL;DR
 
-- Choose **Antigravity Awesome Skills** if you want a large installable library, broad tool coverage, and strong onboarding.
+- Choose **Agentic Awesome Skills** if you want a large installable library, broad tool coverage, and strong onboarding.
 - Choose **VoltAgent Awesome Agent Skills** if you want a curated list with a strong official-team angle and a tighter scope.
 
 ## At-a-glance comparison
 
-| Criteria | Antigravity Awesome Skills | VoltAgent Awesome Agent Skills |
+| Criteria | Agentic Awesome Skills | VoltAgent Awesome Agent Skills |
 | --- | --- | --- |
 | Best for | Breadth, installation, multi-tool daily use | Curated discovery and official/community highlights |
 | Catalog shape | Large installable library with bundles, workflows, docs, and generated catalog | Curated awesome-list style collection |
@@ -19,7 +19,7 @@ For clarity: the repository many people still refer to as `awesome-claude-skills
 | Onboarding | Installation docs, bundles, workflows, getting-started guides | Curated README and categorized references |
 | Good fit when | You want one repo to install and work from | You want a smaller list to browse and evaluate |
 
-## Why choose Antigravity Awesome Skills
+## Why choose Agentic Awesome Skills
 
 - You want a single GitHub repository that acts as both a skill source and an installable working library.
 - You care about onboarding assets like [`bundles.md`](bundles.md), [`workflows.md`](workflows.md), and tool-specific guides.

package/bundled-skills/docs/users/ai-agent-skills.md

@@ -2,7 +2,7 @@
 
 If you are researching **AI agent skills** on GitHub, the biggest decision is usually not "which single skill is best?" but "do I want a broad installable library or a smaller curated collection?"
 
-Antigravity Awesome Skills is built for the first path: broad coverage, multiple supported tools, installation help, onboarding docs, bundles, workflows, and a catalog that supports both beginner and advanced users.
+Agentic Awesome Skills is built for the first path: broad coverage, multiple supported tools, installation help, onboarding docs, bundles, workflows, and a catalog that supports both beginner and advanced users.
 
 ## What to look for in an AI agent skills library
 
@@ -12,7 +12,7 @@ Antigravity Awesome Skills is built for the first path: broad coverage, multiple
 - **Onboarding quality**: are there docs, bundles, workflows, and examples, or only raw files?
 - **Trust model**: does the repo identify official sources, security posture, and community review expectations?
 
-## When Antigravity Awesome Skills is a good fit
+## When Agentic Awesome Skills is a good fit
 
 - You want one library that spans planning, coding, debugging, testing, security, infra, product, and marketing.
 - You care about installation paths and practical onboarding, not only catalog size.
@@ -34,12 +34,12 @@ Antigravity Awesome Skills is built for the first path: broad coverage, multiple
 
 ## Compare broad vs curated libraries
 
-- [`antigravity-awesome-skills-vs-awesome-claude-skills.md`](antigravity-awesome-skills-vs-awesome-claude-skills.md)
+- [`agentic-awesome-skills-vs-awesome-claude-skills.md`](agentic-awesome-skills-vs-awesome-claude-skills.md)
 - [`best-claude-code-skills-github.md`](best-claude-code-skills-github.md)
 - [`best-cursor-skills-github.md`](best-cursor-skills-github.md)
 
 ## Quick recommendation
 
-- Choose **Antigravity Awesome Skills** if you want a large, installable, multi-tool library with onboarding help.
+- Choose **Agentic Awesome Skills** if you want a large, installable, multi-tool library with onboarding help.
 - Choose a smaller curated repo if you want fewer choices and more editorial filtering.
 - If you are unsure, install this repo first, start with [`bundles.md`](bundles.md), and then compare alternatives once you know your preferred workflow.

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

@@ -4,7 +4,7 @@ If you are looking for the **best Claude Code skills on GitHub**, there is no si
 
 ## Best overall installable library
 
-### 1. [sickn33/antigravity-awesome-skills](https://github.com/sickn33/antigravity-awesome-skills)
+### 1. [sickn33/agentic-awesome-skills](https://github.com/sickn33/agentic-awesome-skills)
 
 Best for teams and individual developers who want one large installable library with onboarding docs, bundles, workflows, and support for more than just Claude Code.
 
@@ -52,11 +52,11 @@ Choose this if you want:
 
 ## How to choose quickly
 
-- Choose **Antigravity Awesome Skills** if you want the most practical install-and-use path.
+- Choose **Agentic Awesome Skills** if you want the most practical install-and-use path.
 - Choose **VoltAgent Awesome Agent Skills** if you want the strongest curated shortlist.
 - Choose **anthropics/skills** if official vendor reference matters most.
 - Choose **karanb192/awesome-claude-skills** if you want a smaller community-first Claude library.
 
 ## Recommended next step
 
-If you want to get productive quickly, install [Antigravity Awesome Skills](https://github.com/sickn33/antigravity-awesome-skills) and start with [`claude-code-skills.md`](claude-code-skills.md) plus [`bundles.md`](bundles.md).
+If you want to get productive quickly, install [Agentic Awesome Skills](https://github.com/sickn33/agentic-awesome-skills) and start with [`claude-code-skills.md`](claude-code-skills.md) plus [`bundles.md`](bundles.md).

package/bundled-skills/docs/users/best-cursor-skills-github.md

@@ -4,7 +4,7 @@ If you are searching for the **best Cursor skills on GitHub**, the best option d
 
 ## Best overall installable library
 
-### 1. [sickn33/antigravity-awesome-skills](https://github.com/sickn33/antigravity-awesome-skills)
+### 1. [sickn33/agentic-awesome-skills](https://github.com/sickn33/agentic-awesome-skills)
 
 Best for developers who want one repository they can install into Cursor and keep using across frontend, backend, testing, infra, product, and growth work.
 
@@ -52,11 +52,11 @@ Choose this if you want:
 
 ## How to choose quickly
 
-- Choose **Antigravity Awesome Skills** if you want the strongest install-and-use path for real day-to-day Cursor work.
+- Choose **Agentic Awesome Skills** if you want the strongest install-and-use path for real day-to-day Cursor work.
 - Choose **VoltAgent Awesome Agent Skills** if you want curation first and installation later.
 - Choose **Ai-Agent-Skills** if you want a smaller installable library.
 - Choose **cursor-skills** if you want the most Cursor-specific starting point.
 
 ## Recommended next step
 
-If your goal is to start working in Cursor today, install [Antigravity Awesome Skills](https://github.com/sickn33/antigravity-awesome-skills) and continue with [`cursor-skills.md`](cursor-skills.md).
+If your goal is to start working in Cursor today, install [Agentic Awesome Skills](https://github.com/sickn33/agentic-awesome-skills) and continue with [`cursor-skills.md`](cursor-skills.md).