opencode-skills-collection 4.0.0 → 4.0.2

package/bundled-skills/ditto/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: ditto
+description: "Use when a user asks to mine or update a private, evidence-backed work profile from local Claude Code, Codex, Copilot CLI, or OpenCode sessions."
+category: agent-behavior
+risk: critical
+source: community
+source_repo: ohad6k/ditto
+source_type: community
+date_added: "2026-07-14"
+author: ohad6k
+tags: [personalization, context-engineering, session-mining, agent-memory]
+tools: [claude, cursor, gemini, codex-cli]
+license: "MIT"
+license_source: "https://github.com/ohad6k/ditto/blob/v0.3.6/LICENSE"
+---
+
+# Ditto
+
+## Overview
+
+Ditto mines only the user's words from real local coding-agent session logs and
+turns repeated, supported patterns into private work, design, and writing
+profiles. It keeps dated session receipts, rejects authored rules and memory as
+source evidence, and requires approval before model-backed mining begins.
+
+This standalone skill routes a compatible, already-installed Ditto runtime.
+Native namespaced routing is available through the upstream Ditto plugin.
+
+## When to Use This Skill
+
+- Use when the user explicitly asks to set up, run, update, re-mine, or deepen Ditto.
+- Use when the user wants an agent profile derived from real coding-session history rather than a questionnaire or rules file.
+- Use when native `ditto:mine` is unavailable and the user already has a compatible Ditto runtime installed.
+
+Do not trigger this skill merely because personalization might be useful. Mining
+requires an explicit user request.
+
+## How It Works
+
+### 1. Resolve an installed runtime
+
+Ask the user for the path to an existing, trusted Ditto runtime, or use the
+native upstream plugin when it is already installed. Retain the exact Python 3
+executable path as `PYTHON3`, the runtime path as `DITTO_PY`, and its matching
+`MINING_PROMPT.md` path. Confirm the installed version and source before use.
+
+Do not download or install executable code as part of this skill. If Ditto is
+not installed, stop and direct the user to the upstream installation guidance;
+installation is a separate, explicit decision.
+
+### 2. Show the read-only mining plan
+
+Mine only real user-authored sessions. Never synthesize a profile from
+`AGENTS.md`, `CLAUDE.md`, memory files, rules files, or a typed self-description.
+
+Run the full-history quality-default preflight:
+
+```bash
+"$PYTHON3" "$DITTO_PY" plugin preflight
+```
+
+Show the user the valid session count, post-dedupe source tokens, selected source
+tokens, cache hits, planned worker calls, and planned reducer calls. Wait for
+explicit approval of this displayed plan before any model-backed work.
+
+If the user explicitly asks for a quick preview, add `--preview` and say exactly:
+
+> Quick preview creates a starter profile from selected history, not the full profile.
+
+Never present preview as the default or as equivalent to the full-history result.
+
+### 3. Prepare the approved run
+
+Retain the displayed `approval_hash`, then prepare with the exact approved mode.
+For the full-history plan, run:
+
+```bash
+"$PYTHON3" "$DITTO_PY" plugin prepare --approved-plan-hash HASH
+```
+
+For an approved quick-preview plan, preserve preview mode explicitly:
+
+```bash
+"$PYTHON3" "$DITTO_PY" plugin prepare --preview --approved-plan-hash HASH
+```
+
+If the hash changes, show the new plan and obtain approval again. Retain the
+returned `run_id`, assigned segment and report paths, and `pack_path`.
+
+### 4. Mine and validate evidence
+
+For every uncached selected segment, run one worker over only that segment and
+the per-segment contract in the resolved `MINING_PROMPT.md`. Cache each JSON
+report with `plugin cache-report` and stop on rejection.
+
+Run one strongest-available reducer over only the validated reports and reducer
+contract. Write the complete pack to `pack_path`, validate it, and activate only
+the validated pack with `plugin activate`.
+
+### 5. Verify and report
+
+Run `plugin status`, render the profile card, and report:
+
+- active version and core profile path
+- active and inactive domains
+- selected source tokens and actual worker/reducer passes
+- cache reuse
+- card path
+- any exact targeted-deepen instruction
+
+If the current host already has the native Ditto plugin, do not create a
+competing direct profile installation.
+
+## Examples
+
+### Full-history setup
+
+```text
+User: run ditto on my coding history
+Agent: resolves the pinned runtime, shows the read-only full-history plan, and
+waits for explicit cost approval before starting any mining workers.
+```
+
+### Explicit quick preview
+
+```text
+User: give me a cheap ditto preview first
+Agent: runs preflight with --preview, labels it as a starter profile, and waits
+for approval of the displayed preview plan.
+```
+
+## Best Practices
+
+- Keep raw sessions, caches, receipts, and generated profiles private by default.
+- Report exact observed counts and paths; never estimate provider billing or coverage.
+- Preserve the approval hash and mode through the complete run.
+- Stop on validation failure instead of activating a partial profile.
+- Share the card or a short trait, not the full private profile or receipt appendix.
+
+## Limitations
+
+- Ditto models working behavior; it does not make the underlying model smarter.
+- Sparse or repetitive histories can leave design or writing domains inactive.
+- Provider system prompts, tool traffic, and billing overhead are outside Ditto's exact token accounting.
+- Quick preview has lower recall than the full-history quality default.
+- Automatic work, design, and writing routing requires the upstream native plugin.
+
+## Security & Safety Notes
+
+- This skill does not download executable code; it requires an existing trusted Ditto installation.
+- Extraction, redaction, caches, and generated profiles stay local. Selected redacted text is processed by the model provider the user chooses.
+- Redaction is best-effort. Tell the user to inspect private output before sharing it.
+- Never upload session logs or full profiles to a third party without explicit user approval.
+- Installation itself schedules no mining model calls; every prepared mining mode still requires approval of its displayed plan.
+
+## Common Pitfalls
+
+- **Problem:** No eligible sessions are found.
+
+  **Solution:** Report the supported source locations that were checked and ask whether the user has retained or exported session history.
+
+- **Problem:** The approval hash changed.
+
+  **Solution:** Do not reuse the old approval. Show the updated plan and obtain approval again.
+
+- **Problem:** A cached or reduced report fails validation.
+
+  **Solution:** Stop, preserve the failure evidence, and never activate the incomplete pack.
+
+## Related Skills
+
+- `@agenttrace-session-audit` - Use for cost, latency, failure, and health analysis of coding-agent sessions.
+- `@agent-memory` - Use for explicit persistent knowledge storage rather than evidence-based profile mining.

package/bundled-skills/docs/README.md

@@ -10,7 +10,7 @@
 - [`users/codex-cli-skills.md`](users/codex-cli-skills.md)
 - [`users/gemini-cli-skills.md`](users/gemini-cli-skills.md)
 - [`users/ai-agent-skills.md`](users/ai-agent-skills.md)
-- [`users/antigravity-awesome-skills-vs-awesome-claude-skills.md`](users/antigravity-awesome-skills-vs-awesome-claude-skills.md)
+- [`users/agentic-awesome-skills-vs-awesome-claude-skills.md`](users/agentic-awesome-skills-vs-awesome-claude-skills.md)
 - [`users/best-claude-code-skills-github.md`](users/best-claude-code-skills-github.md)
 - [`users/best-cursor-skills-github.md`](users/best-cursor-skills-github.md)
 - [`users/bundles.md`](users/bundles.md)

package/bundled-skills/docs/contributors/quality-bar.md

@@ -1,6 +1,6 @@
 # 🏆 Quality Bar & Validation Standards
 
-To transform **Antigravity Awesome Skills** from a collection of scripts into a trusted platform, every skill must meet a specific standard of quality and safety.
+To transform **Agentic Awesome Skills** from a collection of scripts into a trusted platform, every skill must meet a specific standard of quality and safety.
 
 ## The "Validated" Badge ✅
 

package/bundled-skills/docs/contributors/security-guardrails.md

@@ -1,6 +1,6 @@
 # 🛡️ Security Guardrails & Policy
 
-Antigravity Awesome Skills is a powerful toolkit. With great power comes great responsibility. This document defines the **Rules of Engagement** for all security and offensive capabilities in this repository.
+Agentic Awesome Skills is a powerful toolkit. With great power comes great responsibility. This document defines the **Rules of Engagement** for all security and offensive capabilities in this repository.
 
 ## 🔴 Offensive Skills Policy (The "Red Line")
 

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

@@ -1,11 +1,11 @@
 ---
 title: Jetski/Cortex + Gemini Integration Guide
-description: "Use antigravity-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,935+ skills."
+description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,962+ skills."
 ---
 
-# Jetski/Cortex + Gemini: safe integration with 1,935+ skills
+# Jetski/Cortex + Gemini: safe integration with 1,962+ skills
 
-This guide shows how to integrate the `antigravity-awesome-skills` repository with an agent based on **Jetski/Cortex + Gemini** (or similar frameworks) **without exceeding the model context window**.
+This guide shows how to integrate the `agentic-awesome-skills` repository with an agent based on **Jetski/Cortex + Gemini** (or similar frameworks) **without exceeding the model context window**.
 
 The common error seen in Jetski/Cortex is:
 
@@ -23,7 +23,7 @@ Never do:
 - concatenate all `SKILL.md` content into a single system prompt;
 - re-inject the entire library for **every** request.
 
-With 1,935+ skills, this approach fills the context window before user messages are even added, causing truncation.
+With 1,962+ skills, this approach fills the context window before user messages are even added, causing truncation.
 
 ---
 
@@ -277,4 +277,4 @@ To prevent recurrence:
 - Load skills **on demand** based on `@skill-id`.
 - Set clear limits (max skills per turn, token threshold).
 
-Following this pattern, Jetski/Cortex + Gemini can use the full `antigravity-awesome-skills` library safely, at scale, and within modern model context-window limits.
+Following this pattern, Jetski/Cortex + Gemini can use the full `agentic-awesome-skills` library safely, at scale, and within modern model context-window limits.

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

@@ -1,6 +1,6 @@
 # Jetski + Gemini Lazy Skill Loader (Example)
 
-This example shows one way to integrate **antigravity-awesome-skills** with a Jetski/Cortex‑style agent using **lazy loading** based on `@skill-id` mentions, instead of concatenating every `SKILL.md` into the prompt.
+This example shows one way to integrate **agentic-awesome-skills** with a Jetski/Cortex‑style agent using **lazy loading** based on `@skill-id` mentions, instead of concatenating every `SKILL.md` into the prompt.
 
 > This is **not** a production‑ready library – it is a minimal reference you can adapt to your own host/agent implementation.
 
@@ -21,7 +21,7 @@ This example shows one way to integrate **antigravity-awesome-skills** with a Je
 - 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,935+ skills installed.
+This pattern avoids context overflow when you have 1,962+ skills installed.
 
 Manifest contract references:
 
@@ -53,7 +53,7 @@ import {
   Message,
 } from "./loader.mjs";
 
-const REPO_ROOT = "/path/to/antigravity-awesome-skills";
+const REPO_ROOT = "/path/to/agentic-awesome-skills";
 const SKILLS_ROOT = REPO_ROOT;
 const INDEX_PATH = path.join(REPO_ROOT, "skills_index.json");
 

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,962+ 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,962+ 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,962+ 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,962+ 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.