opencode-skills-collection 4.0.4 → 4.0.5

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

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "updatedAt": "2026-07-18T01:17:51.174Z",
+  "updatedAt": "2026-07-19T01:23:41.256Z",
   "entries": [
     "00-andruia-consultant",
     "007",
@@ -103,6 +103,7 @@
     "anti-sycophancy",
     "antigravity-agent-manager",
     "antigravity-design-expert",
+    "antigravity-maintainer-batch-release",
     "antigravity-skill-orchestrator",
     "antigravity-workflows",
     "anywrite",
@@ -849,6 +850,7 @@
     "game-development",
     "game-development/2d-games",
     "game-development/3d-games",
+    "game-development/engine-selection",
     "game-development/game-art",
     "game-development/game-audio",
     "game-development/game-design",
@@ -1194,6 +1196,7 @@
     "mobile-developer",
     "mobile-security-coder",
     "mock-hunter",
+    "modellix",
     "modern-javascript-patterns",
     "molykit",
     "monday-automation",

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

@@ -0,0 +1,150 @@
+---
+name: antigravity-maintainer-batch-release
+description: "Run protected AAS maintainer sweeps, PR merge batches, canonical sync, Core preview checks, and scripted releases. Use for repository maintenance, main alignment, CLI/MCP/Workbench changes, or release work; not ordinary contribution tasks."
+risk: critical
+source: self
+date_added: "2026-07-18"
+---
+
+# Antigravity Maintainer Batch Release
+
+## When to Use
+
+Use this skill for repository-wide AAS maintenance, maintainer-side PR repair or merge batches, canonical synchronization, AAS Core or Workbench changes, protected releases, and hosted catalog or legacy redirect infrastructure. Do not use it for ordinary contribution work that does not require maintainer privileges or canonical convergence.
+
+## Protected-Main Contract
+
+Treat the repository root containing this skill as pull-request-only:
+
+- Read `AGENTS.md`, `.github/MAINTENANCE.md`, and current maintainer docs before mutation.
+- Never commit or push directly to `main`, even when the user says “push to main.” That phrase names the final target state.
+- Preserve unrelated dirty work. Use a clean temporary clone or a topic branch for maintainer changes.
+- Use `npm run merge:batch` for accepted source PRs. Do not substitute a raw merge API, generic GitHub skill, or generic push helper.
+- Let `automation/canonical-repo-state` own generated artifacts and contributor-credit convergence after the source batch.
+- Use `release:prepare` and `release:publish` for releases. They never authorize a direct `main` push.
+
+## Source Checks
+
+Before changing anything:
+
+1. Fetch `origin/main`; prove the clean maintainer checkout is on `main` and equals `origin/main`.
+2. Inspect live PRs, issues, discussions in scope, Actions failures, Dependabot, CodeQL, secret scanning, and `npm audit` where relevant.
+3. Confirm current scripts from `package.json`; do not rely on remembered release behavior.
+4. Capture user worktree status separately and keep those files out of maintainer commits.
+
+## Maintainer Sweep
+
+1. Triage every open PR before editing.
+   - Separate valid source changes, repairable PRs, conflicts, generated-only noise, promotional links, and unsupported ownership/license changes.
+   - Review semantics, safety, provenance, risk labels, limitations, source credits, and changed-skill evidence.
+   - Prefer narrow maintainer repairs on the contributor branch when maintainer edits are enabled.
+
+2. Validate changed skills truthfully.
+   - Run `npm run validate`, `npm run validate:references`, `npm run security:docs`, changed-skill evidence, and the relevant tests.
+   - Inspect semantics, safety, provenance, declared risk, limitations, and all tracked bundle files directly. Treat inferred risk labels and heuristic quality scores as non-authoritative; do not change a skill merely to satisfy a lexical signal.
+   - Inspect the `skill-review` workflow on the exact current head SHA.
+   - `review` means Tessl semantic review actually ran or a valid identical-content result was reused.
+   - `manual-review-required` means Tessl credentials or credits were unavailable, or Tessl did not produce a passing result. Perform the maintainer semantic review and attest with `--reviewed-head <full-40-character-sha>`.
+   - Any non-passing Tessl outcome produces `manual-review-required`; complete the semantic review and bind the judgment to the exact head instead of treating a heuristic score as merge authority.
+   - Never report `manual-review-required` as “Tessl passed.”
+
+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.
+
+4. Merge accepted source PRs in conflict-aware order.
+   - Run a dry classification first when useful.
+   - For changed skill content, review the exact head and run:
+
+     ```bash
+     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.
+   - 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`.
+
+5. Converge canonical state once after the source batch.
+   - Wait for the protected `automation/canonical-repo-state` PR.
+   - Verify its managed-only diff, required checks, merge result, and the resulting `origin/main`.
+   - If an unmanaged repair remains, use a topic PR; never patch `main` directly.
+
+## Hosted Catalog and Legacy Redirect Bridge
+
+Treat the current catalog and the legacy user-site bridge as one public system:
+
+- Current catalog: `sickn33/agentic-awesome-skills` at `https://sickn33.github.io/agentic-awesome-skills/`.
+- Legacy bridge: `sickn33/sickn33.github.io` at `https://sickn33.github.io/antigravity-awesome-skills/`.
+
+For SEO, indexing, Pages, redirect, or infrastructure changes:
+
+1. Change the generator and verifier in the source repository through a protected source PR and `npm run merge:batch`.
+2. Keep the legacy deployment managed allowlist exact: `.nojekyll`, `redirect-manifest.json`, and `antigravity-awesome-skills/**`. Reject any unmanaged sync diff or PR file.
+3. Preserve Google verification byte-for-byte and the Bing `msvalidate.01` meta on the legacy root. Record both in manifest evidence.
+4. Keep skill counts dynamic, but retain intentional curated sitemap locks. Version manifest contract changes and record source provenance.
+5. Let `legacy-redirect-sync.yml` generate or update the fixed automation PR. Bind a fresh verifier run to the exact target head SHA, validate its run identity and managed file set, publish the required status only after that proof, then use protected auto-merge.
+6. Recheck source `main` before merge, request the legacy Pages build explicitly after bot-authored merges, and wait for the exact merged commit to be built.
+7. Verify locally generated output byte-for-byte, then verify all live legacy/current redirect pairs for a full audit. Retry transient CDN failures with the full audit rather than accepting a partial probe.
+8. Prove idempotence with a no-drift sync: no replacement, PR, verification, or merge steps should run; Pages and live probes must still pass.
+
+Keep both repositories on least-privilege Actions defaults (`read`) and require external actions to be pinned to full commit SHAs. When changing these settings or action versions, rerun source CI, CodeQL, Pages, and a legacy no-drift sync before declaring completion.
+
+## AAS Core Preview Acceptance
+
+For AAS CLI, MCP, stack, catalog-cache, or Workbench changes:
+
+1. Use the current scripts declared in `package.json`; do not resurrect retired evaluator, benchmark, tuning-gold, transaction-fault, race, or frozen-matrix gates as routine prerequisites.
+2. Run the focused Core tests with `npm run test:aas-v1`, the catalog integrity check with `npm run check:aas-v1-catalog`, and the relevant Workbench tests/build when its contracts or copy change.
+3. Keep MCP local, offline, read-only, bounded, and non-mutating. The coding agent inspects the project and sends an explicit profile; MCP searches, inspects, recommends, and compares without scanning the repository or writing to it.
+4. Keep the supported public path at manifest validation and immutable plan preview. Planning may write only the requested plan artifact; it must not materialize skill payloads or AAS managed state in the target.
+5. Treat apply and recovery as experimental opt-ins outside the supported preview claim. Do not add apply/recovery, benchmark, fuzz, crash/race, or synthetic verifier work unless the user explicitly places it in scope.
+6. When the task asks for end-to-end client proof, use a real supported client that discovers and invokes the local AAS MCP tools; direct stdio probes and automated tests do not substitute for that evidence.
+7. Do not tag, publish npm, deploy Pages, or write real user MCP configuration without the separately required publication approval.
+
+## Protected Release
+
+Release only when requested.
+
+1. Include the target changelog entry in the maintainer batch PR so it is already on protected `main`; avoid a separate release-notes-only PR.
+2. From clean, current `main`, run `npm run release:preflight` and required security checks.
+3. Run `npm run release:prepare -- X.Y.Z`. This creates and pushes `release/vX.Y.Z` and opens the protected release PR.
+4. Merge that release PR through its required checks, update local `main` to equal `origin/main`, and wait for any canonical-sync PR to close.
+5. Run `npm run release:publish -- X.Y.Z`. It verifies the exact protected merge before creating or reusing the tag and GitHub Release.
+6. Wait for publishing workflows, then verify the tag/ref, GitHub Release, npm version and dist-tag, CI, Pages, CodeQL, live `llms.txt`, `skills.json`, and changed catalog routes.
+
+Never rebase a published release tag, force stale release state, reuse a failed published version, or claim npm publication from the GitHub Release alone.
+
+## Stop Condition
+
+Finish only when:
+
+- every in-scope PR, issue, and alert is resolved or has one exact blocker;
+- no open source or canonical-sync PR remains unintentionally;
+- `main`, `origin/main`, required workflows, generated state, and public surfaces agree;
+- the source and legacy repositories have no unintended infrastructure PR, their protected branches and Actions settings remain enforced, and the live manifest identifies the source repository;
+- the user worktree is unchanged except for files the user explicitly placed in scope;
+- release proof is complete when a release was requested.
+
+## Failure Rules
+
+- A protected-branch rejection means switch to the PR path; never retry direct `main` pushes.
+- A missing PR checklist is informational; never mutate, close, or reopen a PR merely to refresh template metadata.
+- Preserve unrelated dirty files and never stage them into maintainer work.
+- Do not bypass `merge:batch`, canonical-sync, or scripted release commands with generic Git helpers.
+- Do not weaken a test or policy gate merely to make a batch pass. Retire a gate only after explicit maintainer authorization, then update branch protection, workflow files, merge automation, documentation, and maintainer skills together so no phantom requirement remains.
+
+## Examples
+
+For a reviewed source PR whose exact head is `0123456789abcdef0123456789abcdef01234567`, exercise the protected path before merging:
+
+```bash
+npm run merge:batch -- --prs 914 --dry-run --reviewed-head 0123456789abcdef0123456789abcdef01234567
+```
+
+Run the same command without `--dry-run` only after every required check passes and the attested head remains unchanged.
+
+## Limitations
+
+- This skill orchestrates the repository's existing scripts and protected workflows; it does not grant GitHub, npm, Pages, or local-client permissions.
+- Stop at the exact approval or credential boundary when publication, authenticated configuration, or another externally visible action was not authorized.
+- Re-read the current repository policy and `package.json` on every run because branch protection, checks, and supported preview commands may change.

package/bundled-skills/create-pr/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: create-pr
-description: Alias for sentry-skills:pr-writer. Use when users explicitly ask for "create-pr" or reference the legacy skill name. Redirects to the canonical PR writing workflow.
+description: Alias for pr-writer. Use when users explicitly ask for "create-pr" or reference the legacy skill name. Redirects to the canonical PR writing workflow.
 risk: unknown
 source: community
 ---
@@ -11,12 +11,12 @@ This skill name is kept for compatibility.
 
 ## When to Use
 - The user explicitly asks for `create-pr` or refers to the legacy skill name.
-- You need to redirect pull request creation work to the canonical `sentry-skills:pr-writer` workflow.
+- You need to redirect pull request creation work to the canonical `pr-writer` workflow.
 - The task is specifically about writing or updating a pull request rather than general git operations.
 
-Use `sentry-skills:pr-writer` as the canonical skill for creating and editing pull requests.
+Use the available `pr-writer` skill as the canonical workflow for creating and editing pull requests. If the client requires qualified skill names, use the qualifier for the plugin that supplied this skill rather than assuming an external namespace.
 
-If invoked via `create-pr`, run the same workflow and conventions documented in `sentry-skills:pr-writer`.
+If invoked via `create-pr`, run the same workflow and conventions documented in `pr-writer`.
 
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.

package/bundled-skills/docs/README.md

@@ -2,6 +2,7 @@
 
 ## Users
 
+- [`users/aas-core.md`](users/aas-core.md) — canonical AAS Core preview guide
 - [`users/getting-started.md`](users/getting-started.md)
 - [`users/usage.md`](users/usage.md)
 - [`users/faq.md`](users/faq.md)

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

@@ -65,7 +65,7 @@ Use `npm run audit:skills` when you need a repo-wide report that goes beyond sch
 - which skills are missing examples or limitations,
 - and which skills have the highest concentration of warnings/errors.
 
-Maintainers can pair that report with `npm run sync:risk-labels` for conservative legacy cleanup. That sync only rewrites `risk: unknown` when the suggested label is explicit and high-confidence enough to automate safely, and it preserves the contributor-facing rule that new or uncertain submissions can still start as `unknown`.
+Risk labels remain declared metadata. The audit validates their presence and shape, while ambiguous `risk: unknown` cases require semantic review rather than lexical inference.
 
 ---
 
@@ -97,7 +97,6 @@ Notes:
 
 - `npm run validate` is the operational contributor gate.
 - `npm run audit:skills` is the maintainer-facing compliance/usability report for the full library.
-- `npm run sync:risk-labels` is a maintainer cleanup tool for high-confidence legacy `risk:` fixes.
 - `npm run security:docs` is required for command-heavy or risky skill content.
 - PRs that touch `SKILL.md` also get an automated `skill-review` GitHub Actions check.
 - Skill changes and risky guidance still require a manual logic review before merge, even when the automated gates pass.

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

@@ -1,9 +1,11 @@
 ---
 title: Jetski/Cortex + Gemini Integration Guide
-description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,965+ skills."
+description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,968+ skills."
 ---
 
-# Jetski/Cortex + Gemini: safe integration with 1,965+ skills
+# Jetski/Cortex + Gemini: safe integration with 1,968+ 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 verified local catalog discovery and deterministic recommendations through a bounded, read-only MCP server.
 
 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**.
 
@@ -23,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,965+ skills, this approach fills the context window before user messages are even added, causing truncation.
+With 1,968+ 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

@@ -1,5 +1,7 @@
 # Jetski + Gemini Lazy Skill Loader (Example)
 
+> **Custom-host example:** This is a low-level, direct-manifest integration for Jetski/Cortex-style hosts. Codex and Claude Code users should start with [AAS Core](../../users/aas-core.md), which exposes verified local catalog discovery and deterministic recommendations through a bounded, read-only MCP server.
+
 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 +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,965+ skills installed.
+This pattern avoids context overflow when you have 1,968+ skills installed.
 
 Manifest contract references:
 

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

@@ -0,0 +1,141 @@
+# AAS Agent-First Control Plane Preview Profile
+
+Status: approved intermediate release profile
+Date: 2026-07-17
+Certified design: `docs/maintainers/aas-agent-first-control-plane-v1-design.md`
+
+## Purpose
+
+This profile validates whether Codex, Claude Code, and comparable agents can
+use AAS to compose useful local skill stacks without implying the retired
+certified-v1 benchmark or transaction-verifier guarantees. The certified-v1
+design and goal documents are retained as historical architecture records;
+their verifier corpus and routine workflow were removed on 2026-07-18.
+
+The permitted preview claim is:
+
+> AAS Agent-First Preview helps Codex and Claude compose a local, explainable,
+> reproducible skill stack. Full-catalog recommendation quality and
+> transactional apply/recovery safety are not yet certified.
+
+Preview output must not use `implementationVerified`, `releaseReady`,
+`released`, `certified`, or an equivalent unqualified claim.
+
+## Included preview surfaces
+
+- Minimal, schema-validated `aas-stack.json` with pinned catalog identity,
+  targets, approved intent and policy, and exact skill IDs.
+- CLI `stack init`, `stack recommend`, `stack validate`, `stack plan`, and
+  `stack doctor` from the packed npm candidate.
+- The local stdio MCP with exactly `search_skills`, `get_skill`,
+  `recommend_stack`, `inspect_stack`, `diff_stack`, and
+  `aas://skills/{id}`.
+- Deterministic recommendation with structured factors, two visible lanes
+  (`recommended` and `discoveryCandidates`), explicit unknowns, stable
+  tie-breaking, and fail-closed policy decisions.
+- Essential packed-product coverage on Linux and Node 22 from one exact
+  content-addressed tarball.
+- Workbench schema/import/render tests and a local production build. A live
+  Pages deployment remains outside the preview until separately approved.
+
+## Experimental writes
+
+`stack apply` and `stack recover` are present for controlled development but
+are not preview-supported safety claims. They are disabled by default:
+
+- apply requires the additional `--experimental-apply` flag and the existing
+  exact plan-digest approval;
+- recovery requires `--experimental-recovery` and retains its existing
+  recovery-plan approval;
+- successful experimental writes return `releaseProfile: "preview"` and
+  `certificationStatus: "experimental"`;
+- absence of the opt-in fails before runtime resolution or target writes with
+  a structured policy error.
+
+Internal transaction tests are development evidence only. Apply and recovery
+remain experimental and outside the supported preview claim.
+
+## Preview functional gate
+
+The preview job must install the exact candidate tarball with lifecycle scripts
+disabled and run without checkout-only runtime dependencies. It is an essential
+end-to-end smoke test, not an OS/runtime certification matrix.
+
+Required functional suites are:
+
+1. **Package and entrypoints** — allowlisted package contents; `aas`,
+   `aas-mcp`, and the legacy alias exist; legacy invocation creates no stack
+   state implicitly.
+2. **Stack lifecycle** — `init -> recommend -> validate -> plan -> doctor`
+   succeeds in isolated roots and does not materialize target skills or AAS
+   managed state.
+3. **Determinism and explanation** — repeated identical inputs produce the
+   same canonical recommendation payload and expose factor, coverage, evidence,
+   exclusion, and unknown fields.
+4. **Policy** — proved incompatibility or forbidden risk is excluded;
+   incomplete evidence remains visible; malformed or over-limit input fails
+   closed.
+5. **MCP contract** — the five tools and one resource template work over real
+   stdio framing; project and cache snapshots remain unchanged by tool calls.
+6. **Write guard** — apply and recovery without their experimental flags fail
+   with structured policy codes and leave project, cache, and managed state
+   unchanged.
+7. **Workbench** — bounded text-only import/review tests and production build
+   pass without ambient filesystem access.
+
+The preview receipt must declare:
+
+```json
+{
+  "assuranceProfile": "agent-first-preview-1",
+  "previewQualified": true,
+  "certifiedV1": false,
+  "notEvaluated": [
+    "native-network-and-filesystem-attempt-observation",
+    "transactional-crash-and-race-certification",
+    "benchmark-80-90-100",
+    "real-host-configuration-writes",
+    "public-release"
+  ]
+}
+```
+
+Missing receipts, crashes, timeouts, canonical drift, or any failed functional
+suite make `previewQualified` false.
+
+## Explicitly not certified by preview
+
+- ETW, `fs_usage`, or `strace` proof of zero network attempts and zero
+  persistent MCP writes.
+- Production-binary fault injection at every transaction boundary or every
+  declared race class.
+- Full benchmark thresholds: at least 80% verified coverage, 90% inclusion
+  precision, and 100% correct abstention for each supported intent and in
+  macro-average.
+- Complete property/fuzz/hostile budgets required by certified v1.
+- Real Codex or Claude configuration writes, public Pages deployment, npm
+  publication, GitHub release, or announcement.
+
+These are explicitly outside the current product claim. The repository does
+not maintain a blocking certified-v1 release gate.
+
+## Product-learning gate
+
+After the functional matrix passes, preview evaluation should measure whether
+agents actually produce useful proposals:
+
+- task completion rate from a repository profile to a reviewable stack;
+- human accept/replace/remove rates for recommended skills;
+- uncovered goals and discovery-candidate promotions;
+- deterministic replay rate for the same normalized input and catalog digest;
+- time and interaction count from request to approved manifest.
+
+No repository profile, source file, secret, or raw path is uploaded by default.
+Publishing or sharing any collected result requires a separate explicit
+decision and privacy review.
+
+## Relationship to certified v1
+
+The preview receipt must report `previewQualified: true` and
+`certifiedV1: false`. The historical certified-v1 design is not a current
+release gate and must not be inferred from a green preview.