📦 deps(thirdparty): update snapshots

2026-07-29 07:59:17 +00:00
parent 60364c6660
commit 0c634043e3
427 changed files with 26138 additions and 2336 deletions
@@ -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,993+ skills."
 ---

-# Jetski/Cortex + Gemini: safe integration with 1,987+ skills
+# Jetski/Cortex + Gemini: safe integration with 1,993+ 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,993+ skills, this approach fills the context window before user messages are even added, causing truncation.

 ---

@@ -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,993+ skills installed.

 Manifest contract references:

@@ -131,7 +131,7 @@ The server exposes only:

 Full skill text is returned only on request and is separated as `untrustedContent`; metadata and prose cannot acquire instruction authority. The server can signal this trust boundary but cannot guarantee how an external model will behave.

-Every structured response declares `protocolVersion`, `coreVersion`, `metadataSchemaVersion`, `scorerVersion`, and catalog digest. Incompatible versions fail explicitly.
+Every structured response declares `protocolVersion`, `coreVersion`, `metadataSchemaVersion`, `scorerVersion`, and catalog digest. MCP initialization responds with the server-supported protocol revision so the client can accept it or disconnect; incompatible artifact and schema versions still fail explicitly.

 ## CLI lifecycle

@@ -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:
@@ -33,6 +42,7 @@ Use `--dry-run` to exercise local classification without approving a run or merg
 - fetch the exact base/head objects and classify the complete raw Git diff
 - recompute changed-skill evidence with evaluator code materialized from the trusted `main` commit
 - reject incomplete evidence coverage, deterministic quality/security/provenance regressions, and base/head drift
+- allow only exact `source_repo` transitions recorded in the trusted protected-base provenance exception ledger; unrecorded or malformed transitions still fail closed
 - for external PRs, poll for asynchronously-created fork runs and approve only runs waiting on `action_required` when every path, mode, object, size, and workflow identity is allowlisted
 - for sensitive same-repository source changes, allow the guarded exception only when the PR author is the repository owner and the exact full head SHA is attested; collaborator-authored sensitive changes fail closed under the external safety policy
 - wait for the latest required checks bound to the exact head SHA
@@ -46,12 +56,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
@@ -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;
@@ -58,10 +62,10 @@ A successful `manual-review-required` check means only that the requirement was
 4. for external PRs, rejects unsafe paths, modes, symlinks, gitlinks, executable files, unknown types, oversized blobs, incomplete metadata, or non-allowlisted workflows;
 5. verifies workflow event, workflow identity, pull-request number, and head SHA;
 6. recomputes changed-skill evidence over the exact merge-base-to-head record set and requires one-to-one coverage of every skill-content Git record;
-7. rejects operational errors, malformed evidence, incomplete snapshots, score-component regressions, provenance identity regressions, or any other deterministic blocker;
+7. rejects operational errors, malformed evidence, incomplete snapshots, score-component regressions, provenance identity regressions, or any other deterministic blocker; an exact `source_repo` rename may pass only when the trusted protected-base ledger records the skill, old slug, new slug, upstream repository ID, verification date, and canonical GitHub URL;
 8. re-reads both pull-request base and head before and after approval and immediately before merge.

-A real merge also requires effective server-side protection for `main`: the four exact GitHub-Actions-owned checks (`pr-policy`, `pr-evidence`, `source-validation`, and `artifact-preview`), strict up-to-date enforcement, pull-request-only changes, administrator enforcement, no applicable ruleset bypass actors, and no merge queue. If that enforcement cannot be proven, `merge:batch` refuses non-dry-run operation. 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

@@ -84,7 +96,7 @@ Each phase requires evidence from the previous phase before activation:
 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.
+6. Expand immutable upstream commit/path/hash provenance. The first narrow delta exception ledger now covers maintainer-verified `source_repo` renames only; broader provenance exceptions remain out of scope.
 7. Consider auto-merge only for empirically proven documentation or metadata classes. New skills, security-sensitive content, workflows, installers, releases, provenance exceptions, and policy changes remain human decisions.

 Merge queue is not part of the current plan. The repository is personally owned, and its workflows do not currently support a `merge_group` event.
@@ -0,0 +1,14 @@
+{
+  "schema_version": 1,
+  "exceptions": [
+    {
+      "skill_id": "modellix",
+      "field": "source_repo",
+      "before": "Modellix/modellix-skill",
+      "after": "Modellix/modellix-plugin",
+      "upstream_repository_id": 1150322983,
+      "verified_at": "2026-07-28",
+      "evidence_url": "https://github.com/Modellix/modellix-plugin"
+    }
+  ]
+}
@@ -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

@@ -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,993+ 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.

@@ -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,993+ skills from the skills directory

 ## When to Update

@@ -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.6.0 -- aas mcp configure \
  --host codex \
  --scope user \
  --config /absolute/path/to/codex/config.toml \
@@ -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,993+ | Total Bundles: 58_
@@ -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,993+ 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.
@@ -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,993+ 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
@@ -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,993+ 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
@@ -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,993+ 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,993+ 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,993+ skills installed locally, you should **not** concatenate every `SKILL.md` into a single system prompt or context block.

 The intended pattern is:

@@ -40,7 +40,7 @@ agentic-awesome-skills/
 ├── 📄 CONTRIBUTING.md                  ← Contributor workflow
 ├── 📄 CATALOG.md                       ← Full generated catalog
 │
-├── 📁 skills/                          ← 1,987+ skills live here
+├── 📁 skills/                          ← 1,993+ 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,993+ total)
 │
 ├── 📁 apps/
 │   └── 📁 web-app/                     ← Interactive browser
@@ -106,7 +106,7 @@ agentic-awesome-skills/

 ```
                    ┌─────────────────────────┐
-                    │  1,987+ SKILLS          │
+                    │  1,993+ 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,993+ total)                │
 └─────────────────────────────────────────┘
 ```

@@ -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?