Antigravity Maintainer Batch Release

When to Use

Use for AAS maintainer sweeps, PR repairs and merge batches, runtime/catalog releases, installed maintainer-skill alignment, and public deployment verification. Ordinary contributors do not need maintainer privileges.

Operating sequence

1. Preserve dirty work. Use an isolated current-main checkout. Read the exact-base AGENTS.md, .github/MAINTENANCE.md, package.json, and maintenance contract. Mandatory tools must exist on that base; never import retired procedures from another checkout.
2. Triage the full authorized scope. Repair source PRs, run the component plan, review the entire tracked skills/<skill-id>/** subtree, and inspect relevant advisories. Do not substitute a heuristic score for semantic review.
3. Use npm run merge:batch only. Keep strict protected main and admin enforcement. Safe analysis may precede review; merge still requires current checks and either real Tessl review or exact-head maintainer attestation. Private signed receipts may reuse unchanged content/context review. Preserve owner-only sensitive-change and protected-base fork-ledger restrictions.
4. Resume with a private external --state-dir. Re-fetch PR state and protection every time. Continue independent PRs after a blocked PR; report failures. Do not rewrite PR metadata, automatically retry base drift, or use GitHub auto-merge.
5. Ordinary source merges generate ephemeral validation state only. Tracked distribution snapshots and contributor credits refresh in the protected release PR; no ordinary canonical-sync PR is required.
6. When authorized, use release:prepare and release:publish. Merge the prepared release PR through protection. The immutable candidate is built once, checked on supported platforms, and consumed unchanged by npm/Pages. Main may advance while the released commit remains protected ancestry.
7. For compatible catalog-only publication, use the independent catalog workflow and immutable revision/SRI. Preserve offline operation, rollback and agent-owned selection. Do not bump or republish runtime just to update catalog data.
8. Complete the full-release-alignment gate in the contract. Verify actual public bytes and live surfaces. Report personal MCP configuration and session reload separately. Update installed maintainer skills from the adopted canonical source, preserving unrelated installations.

Examples

Prepare safe analyses without merging:

npm run merge:batch -- --prs 123,124 --prepare-only

After actual semantic review, persist the evidence and merge:

npm run merge:batch -- --prs 123,124 --state-dir /absolute/private/state --reviewed-head FULL_40_CHARACTER_SHA --reviewer maintainer --review-evidence 'Complete bundle, provenance, safety and limitations reviewed'

Use real IDs, paths and a full immutable SHA. The state directory must already exist, be privately owned and mode 0700, and be outside source checkouts.

Validation

Read component validation and the maintenance contract for exact checks, release proof, catalog compatibility and timing methodology. Required checks remain pr-policy, pr-evidence, source-validation, artifact-preview. Unknown/shared/policy changes receive full validation.

Limitations

This skill grants no additional publication or messaging authority. Tessl unavailable means manual-review-required, not a passing review. Jev, SkillSpector and timing reports are advisory. Never use direct main push, admin bypass, mutable artifact identity, PR-controlled review receipts, or invented native-client reload proof. Local timings do not establish whole-cycle improvement.

Consult scanner interpretation when triaging SkillSpector and Core preview acceptance for runtime changes.

Follow public surface verification for catalog, Pages and legacy redirect changes.