Antigravity Maintainer Batch Release

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. That lane runs sync:repo-state, which now also recomputes the README ## Top Contributors leaderboards through sync:top-contributors: never hand-edit those tables, and treat a stale ranking as a generator or exclusion-list defect instead.
• 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 and the workflow files listed in Current CI workflow; do not rely on remembered CI or release behavior.
4. Capture user worktree status separately and keep those files out of maintainer commits.

Current CI workflow

Read .github/workflows/ci.yml, .github/workflows/skill-review.yml, .github/workflows/skillspector-advisory.yml, and their protected-base scripts on the exact task base. Job dependencies define execution order; file order and a green workflow badge do not define merge authority.

Required PR checks and independent review

The four routine protected checks remain pr-policy, pr-evidence, source-validation, and artifact-preview. Review skill-content changes truthfully and use merge:batch with exact-head attestation where required. SkillSpector, Jev, shadow decisions, and timing telemetry neither satisfy these checks nor authorize a merge. Inspect available advisory findings during semantic review, but do not add an advisory workflow to branch protection, fork-run approval prerequisites, or merge:batch without a separately authorized contract change.

For protected canonical-sync PRs, pr-policy reproduces the exact managed tree from trusted main; source-validation and pr-evidence record lightweight successful boundaries, while artifact-preview regenerates to confirm no drift. Do not describe those boundary jobs as fresh source tests or semantic scans. On merged main, main-validation-and-sync performs the repository-state sync, reference validation, dependency audit, full tests, web coverage, and documentation security checks. It creates or updates the protected canonical PR only when managed drift exists. Wait for that PR's guarded merge, then verify the final main CI, CodeQL, clean tree, and idempotent generated state. This path does not authorize a release or Pages deployment.

SkillSpector advisory CI

Use the current .github/workflows/skillspector-advisory.yml and tools/scripts/skillspector_advisory.py as the implementation contract:

1. evidence-ready polls the exact head's checks for a pr-evidence result from GitHub Actions app ID 15368 associated with the same PR number. It makes up to 60 polls separated by 10 seconds, with a 12-minute job timeout. A failed evidence check or timeout means no scan ran. This workflow has only the pull_request trigger for main; it has no manual, push, or privileged trigger.
2. The advisory job checks out the PR's protected base with persisted Git credentials disabled, fetches the immutable PR head as data, and plans changed canonical skills/<skill-id>/** directories. A copy changes only its destination; a rename examines both roots. Plugin-only mirror changes are outside this scanner's canonical scope. Deleted roots without a SKILL.md are recorded as deleted-or-no-skill.
3. When the planned skill list is empty, installation and scanning are skipped. Inspect manifest.json first: an empty list with errors can mean an exceeded limit, not an empty or successful scan. A missing wrapper on the protected base produces the documented bootstrap skip. A green bootstrap or planning-only run is not proof that SkillSpector executed.
4. For planned skills, install NVIDIA SkillSpector v2.12.0 at immutable commit c7958a3268d9498644b22edb75d0f051bbc8cbfc using Python 3.12, uv==0.8.22, and uv sync --frozen --no-dev. Copy complete changed canonical trees from Git into private inert snapshots. Executable blobs are copied with mode 0600 and listed under executable_git_blobs; they are never invoked. Links, gitlinks, unsupported modes, and invalid paths are rejected. This scanner snapshot is separate from the deterministic evidence evaluator's stricter executable-file rejection.
5. Run --no-llm inside a Linux network namespace as the runner user, with a sanitized scanner environment and tracing disabled. Static mode alone does not guarantee offline behavior; the namespace also prevents OSV and other network requests. No contributed baseline or automatic suppression is applied.
6. Observe the implementation bounds: at most 50 changed skill roots, 1,000 files and 16 MiB per skill, 60 seconds per scanner invocation, a 600-second aggregate budget checked between skills, 8 MiB per JSON report, and a 15-minute advisory job timeout. Missing, malformed, oversized, timed-out, or unsupported inputs remain incomplete; never treat absent output as a clean scan.
7. Read the skillspector-advisory-<PR_NUMBER> artifact, retained for 14 days, and the scan-step outcome. The manifest's head_sha is the exact scanned head; base_sha is the resolved Git merge base. Compare those bindings before using the report. The job has continue-on-error: true, so its green overall result alone is not a scanner pass or safety certificate.

Interpret manifest states from the actual report, not from a workflow badge:

Review findings individually during the pilot. Missing allowed-tools, environment credentials sent to an API, low risk scores, and offensive educational examples require context and declared purpose. Do not bulk-accept a baseline or silently suppress reports. Any later suppression policy or blocking rule needs a separately reviewed workflow-contract change. The official skill-content review remains Tessl or exact-head maintainer attestation.

SkillSpector triage calibration

Calibrate raw finding counts against the repository's own corpus shape before treating them as defect counts. A full static maintenance sweep prints thousands of findings, most of which are the scanner describing documentation, not the skill acting:

• Prose dominates. Roughly nine in ten findings sit in SKILL.md, README, and references/** prose. A security reference that documents Ignore all previous instructions or .env handling is describing an attack, not performing one. Triage the executable surface first: a finding in a shipped .py/.js/.sh/.ts, not in a .md, is the one worth a code review.
• Credential Access on a .env, access_token, or keychain token is usually configuration reading, and can even be a guard such as --exclude='.env'. Confirm intent by reading the line before treating it as privilege escalation.
• Offensive-by-design skills (pentest, exploit, privilege-escalation, reverse-engineering) match offensive patterns because that is their declared purpose and risk label. Do not count them as regressions or use their score to gate them.
• partial / incomplete analysis is the static-mode default, not a repository defect. It means at least one analyzer was degraded or a bounded parser hit its span limit.
• Bundled fixture trees (generated apps, benchmarks, examples/**, recorded sessions) inflate a skill's score with code the skill does not ship as guidance. Clean the packaging; do not patch fixture vulnerabilities.

When a real executable defect is confirmed, fix it in the source skill with the normal validation and PR path, and treat the scanner as advisory input. A near-total reduction in headline findings after calibration is expected and is not an unexplained gap.

The official skill-content review remains Tessl or exact-head maintainer attestation.

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.
   • Optional accelerator before editing: run npm run maintainer:sweep for repo health, open PR check rollup, advisory download of CI pr-evidence-* artifacts (when pr-evidence succeeded), optional Jev triage (TYPESAFE_API_KEY in .env.local), merge:batch --dry-run on CI-ready PRs, and a Next actions hint list. Prefer CI evidence over re-running npm run pr:evidence locally when the artifact head matches. For a single head only, use npm run maintainer:jev-hints -- --base origin/main --head <head-sha>. Sweep/Jev/CI summaries are advisory only; merge:batch recomputes from trusted main, and Tessl plus --reviewed-head attestation remain authoritative. See docs/maintainers/maintainer-sweep.md and docs/maintainers/jev-hints.md.

2. Validate changed skills truthfully.

   • Run npm run validate, npm run validate:references, npm run security:docs, changed-skill evidence, and the relevant tests.
   • Treat the entire tracked skills/<skill-id>/** subtree as skill content. Inspect semantics, safety, provenance, declared risk, limitations, and every bundled file directly, including nested examples, scripts, lockfiles, references, and assets. Never reduce evidence or review to SKILL.md or a fixed support-directory allowlist.
   • Require changed-skill evidence to cover every Git record in each changed canonical skill subtree. Require the skill-review workflow for changes under skills/** or plugins/**/skills/**; its reusable result must be keyed by the complete nearest skill-directory fingerprint on the exact current head SHA.
   • Keep canonical skill ownership lookup proportional to changed-path depth, not total registry size, and preserve the five-minute trusted evaluator budget so repository-wide evidence completes without weakening fail-closed checks. Parse a legacy executable-mode canonical SKILL.md only as private, non-executable snapshot data; keep it reported as unsafe and never materialize symlinks, gitlinks, or other executable files.
   • 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.”
   • Scoped content-review fingerprints document exact bytes and observed checks, not general reliability. Keep explicit compatibility aliases and their complete local support bundles synchronized; the alias-integrity regression checks equality without affecting selection eligibility. Report remaining corpus debt rather than awarding an unqualified validation badge.
   • A verified upstream repository rename may bypass the provenance-identity blocker only through an exact entry in the trusted protected-base exception ledger. Record the skill ID, old and new source_repo, stable upstream repository ID, verification date, and canonical GitHub URL; all other provenance changes remain blocked.

3. Run checks in parallel where independent.

   • Follow the Current CI workflow lanes below the source checks. Read available SkillSpector reports with their manifest states and exact-head bindings; never confuse a planning-only, partial, or green advisory run with complete semantic review.
   • 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.
   • For source-only changed paths, a Git copy changes only its destination; renames change both paths. Treat a Git copy origin as read-only in the fork classifier too: Git pairs a copy by similarity against any path already in the base tree, so that origin's path class is not author-controlled and the same new canonical skill must not pass or fail depending on which existing file Git chose. Keep its raw-record, mode, object, size and total-budget checks, and keep editing, renaming or deleting that origin as definite failures.
   • Treat pr-policy fork classification from the exact protected-base implementation as an unprivileged fail-fast gate before dependent work, never as approval authority. Install and resolve every dependency used by that classifier from the same protected-base worktree; never expose it to pull-request-controlled node_modules. merge:batch must still recompute the current trusted decision before approving any fork run or merging. The intake allowlist also covers browser source under apps/web-app/src/** (.css, .ts, .tsx); those fork runs may be approved, but every web-app source change still requires an exact-head maintainer attestation before merge. Keep every read-only PR-only workflow that runs on fork pull requests in the approval allowlist too: a workflow missing from it leaves those PRs stuck on action_required with no gate to merge, even when the workflow itself declares only read permissions, uses no secrets, and pins its actions to full SHAs.
   • Treat impact_profile as shadow-only telemetry. It must not skip, downgrade, or satisfy any required check.
   • For ordinary source PRs, require source-validation to generate preview state once and artifact-preview to verify the manifest bound to the exact head and run identity. For canonical-sync PRs, rely on pr-policy exact-tree reproduction, keep source-validation lightweight, require artifact-preview to confirm no drift, and retain final CI and CodeQL on the merged main commit.
   • Keep timing observational and test sharding opt-in. Required CI must continue to run the full unsharded npm run test; deterministic local shards may be used only through npm run test:local -- --shard-index N --shard-count M.

4. Merge accepted source PRs in conflict-aware order.

   • Run a dry classification first when useful.

   • For changed skill content, review the exact head and run:

     npm run merge:batch -- --prs <PR_LIST> --reviewed-head <FULL_HEAD_SHA>

   • merge:batch does not rewrite the PR body and does not close or reopen the PR. It evaluates the current immutable PR tuple and may approve only workflow runs bound to that PR and exact head SHA.

   • Same-repository location is not sufficient authority for sensitive changes. The guarded same-repository exception is limited to a PR authored by the repository owner and requires an exact full-head attestation; collaborator-authored sensitive PRs fail closed under the external safety policy.

   • The routine protected checks are pr-policy, pr-evidence, source-validation, and artifact-preview. The retired aas-v1-baseline workflow is not a merge prerequisite and must not be awaited or approved during source or canonical-sync batches.

   • If the PR head or base changes, discard stale evidence, refresh to the current origin/main, and rerun the batch. The command does not retry base drift automatically.

5. Converge canonical state once after the source batch.

   • Wait for the protected automation/canonical-repo-state PR.
   • 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.

Reviewed fork bundle exceptions

tools/config/reviewed-fork-skills.json is a protected-base ledger for the explicitly reviewed fork contributions. Each entry binds the base repository, fork repository, PR number, original full reviewed head and complete Git skill-tree object. The baseline rule permits only Markdown/assets/references support files, Python files under that skill's scripts/ subtree and its root LICENSE, with a read-only Git copy origin when needed. An entry may opt in to at most 16 extra exact paths inside its own skill root; the validator can only represent root manifest files (.gitignore, README.md, LICENSE) and scripts/*.py, so it can never become a general extension allowlist. It does not allow workflows, arbitrary script types, generated-file mutations, unsafe modes, links, invalid paths/objects or oversized content.

Both CI intake and merge:batch load the ledger from their trusted evaluator checkout, never the PR's repository directory. Any change anywhere in the skill subtree invalidates the exception. A base-only merge may reuse identical content, but the maintainer must inspect the new complete PR diff and attest its exact current head with --reviewed-head. Evidence, source-only checks, truthful skill review, immutable PR/workflow binding and strict branch protection all remain mandatory. Missing or malformed ledger data fails closed. Further exceptions or policy expansions need explicit maintainer authorization and protected review.

Workflow Contract Change Gate

When changing maintainer scripts, workflows, or policy, update the canonical skill, maintainer documentation, and regression tests in the same source PR. Add a negative test for every failure mode being fixed, run the relevant dry-run path, and reject any implementation/documentation mismatch. Source PRs must exclude generated registries and plugin mirrors; the protected canonical-sync PR owns that derived state, except for files intentionally staged by the scripted protected-release flow.

Repository documentation consistency

When auditing repository documentation, compare operational guides and translations with exact-base scripts and workflow behavior. Check local links, heading anchors and documented npm commands with tools/scripts/tests/test_documentation_consistency.py; dated evidence and backup snapshots are historical, not current instructions. Keep canonical guides discoverable from docs/README.md, distinguish source merge from release availability, and report the scope of the audit without claiming that all skill procedures or external integrations ran.

Specialized Plugin Consistency

Use data/specialized-plugin-candidates.json for specialized-plugin membership and data/editorial-bundles.json for the installable composition, descriptions, limits and starter prompts. Review changes against canonical skills_index.json; keep IDs stable unless a migration is explicitly requested. Derive the web catalog and prerender/live-verifier counts from these sources instead of maintaining copied lists or fixed counts. Verify full skill-list expansion, source-to-web parity and a negative stale-count case. The specialized-resource regression must reject missing prose-declared local support paths and verify their bytes in generated specialized bundles; fenced application examples remain a separate semantic review. Run the pure-example regressions when editing documented calculations or chunking behavior. Regenerate plugin artifacts as evidence, but leave their commit to the protected canonical-sync lane. A source refresh does not authorize release or deployment.