反重力维持装置批量发布

antigravity-maintainer-batch-release

分类编程

作者Agentic Awesome Skills 社区

许可MIT

评分4.20/5

使用3.3K

Antigravity 维护者批量发布

使用场景

本技能适用于全仓库范围的 AAS 维护、维护者侧的 PR 修复或批量合并、规范同步、AAS Core 或 Workbench 变更、受保护的发布，以及托管目录或遗留重定向基础设施。请勿将其用于不需要维护者权限或规范收敛的普通贡献工作。

受保护主分支合约 (Protected-Main Contract)

将包含此技能的仓库根目录视为“仅限拉取请求 (pull-request-only)”：

在进行变更前，请阅读 AGENTS.md、.github/MAINTENANCE.md 及当前的维护者文档。

绝不要直接 commit 或 push 到 main 分支，即使由于用户要求“push to main”时也是如此（该短语仅指代最终的目标状态）。

保留无关的脏工作 (dirty work)。对于维护者变更，请使用干净的临时克隆或主题分支。

对于已接受的源 PR，请使用 npm run merge:batch。不要使用原始合并 API、通用 GitHub 技能或通用 push 助手替代。

在源批量处理后，由 automation/canonical-repo-state 负责生成的产物和贡献者信用收敛。

发布时请使用 release:prepare 和 release:publish。它们绝不授权直接 push 到 main。

源检查

在进行任何变更前：

1. 获取 origin/main；证明干净的维护者检出处于 main 分支且与 origin/main 一致。
2. 检查范围内的实时 PR、Issue、讨论、Actions 失败记录、Dependabot、CodeQL、密钥扫描以及相关的 npm audit。
3. 从 package.json 确认当前脚本；不要依赖记忆中的发布行为。
4. 单独记录用户工作区状态，并将这些文件排除在维护者 commit 之外。

维护者清理 (Maintainer Sweep)

1. 在编辑前对每个开启的 PR 进行分拣。
- 将有效的源变更、可修复的 PR、冲突、仅生成的噪音、推广链接以及不受支持的所有权/许可证变更分开。
- 审查语义、安全性、来源、风险标签、局限性、源信用以及变更技能的证据。
- 当允许维护者编辑时，优先在贡献者分支上进行小范围的维护者修复。

2. 真实地验证变更的技能。
- 运行 npm run validate、npm run validate:references、npm run security:docs、变更技能证据及相关测试。
- 将整个被追踪的 skills/<skill-id>/ 子树视为技能内容。直接检查语义、安全性、来源、声明的风险、局限性以及每个捆绑文件（包括嵌套示例、脚本、lockfiles、引用和资产）。绝不能将证据或审查简化为仅查看 SKILL.md 或固定的支持目录白名单。
- 要求变更技能证据覆盖每个变更的规范技能子树中的每一条 Git 记录。对于 skills/ 或 plugins//skills/ 下的变更，必须要求执行 skill-review 工作流；其可复用结果必须以当前 head SHA 下最近技能目录的完整指纹作为键值。
- 保持规范技能所有权查找与变更路径深度成正比，而非与总注册表大小成正比，并保留五分钟的信任评估预算，以便在不削弱“故障关闭 (fail-closed)”检查的情况下完成全仓库证据收集。解析遗留执行...

将可变模式（utable-mode）的规范 SKILL.md 仅视为私有的、不可执行的快照数据；将其报告为不安全，且绝不实例化符号链接（symlinks）、gitlinks 或其他可执行文件。

- review 表示 Tessl 语义审查已实际运行，或复用了有效的相同内容结果。
- manual-review-required 表示 Tessl 凭据或额度不可用，或者 Tessl 未能产生通过的结果。请执行维护者语义审查，并使用 --reviewed-head <完整40位SHA> 进行证明。
- 任何未通过的 Tessl 结果均产生 manual-review-required；请完成语义审查并将判定绑定到确切的 head，而非将启发式评分视为合并权限。
- 绝不能将 manual-review-required 报告为“Tessl 已通过”。
- 经过验证的上游仓库重命名仅能通过受信任的 protected-base 异常账本中的精确条目来绕过来源身份（provenance-identity）拦截。需记录 skill ID、旧的和新的 source_repo、稳定的上游仓库 ID、验证日期以及规范的 GitHub URL；所有其他来源变更仍被拦截。

3. 在独立的情况下并行运行检查。
- 根据变更文件运行所需的仓库验证（repository validation）、测试（test）、文档安全（docs-security）、源码信用（source-credit）、引用（reference）、警告预算（warning-budget）以及针对性应用检查。
- 在源码中修复确定性的策略失败；不要像对待不稳定的 CI 一样等待它们。
- 将来自确切 protected-base 实现的 pr-policy 分叉分类视为依赖工作之前的非特权快速失败门禁（fail-fast gate），绝不能将其视为审批权限。从同一个 protected-base 工作树中安装并解析该分类器使用的每个依赖项；绝不要将其暴露给由拉取请求控制的 node_modules。merge:batch 在批准任何分叉运行或合并之前，必须重新计算当前的信任决策。
- 将 impact_profile 视为仅用于影子遥测（shadow-only telemetry）。它不得跳过、降级或满足任何必需的检查。
- 对于普通源码 PR，要求 source-validation 生成一次预览状态，且 artifact-preview 验证绑定到确切 head 和运行身份的清单（manifest）。对于 canonical-sync PR，依赖 pr-policy 的精确树重现，保持 source-validation 轻量化，要求 artifact-preview 确认无漂移，并在合并后的 main 提交上保留最终的 CI 和 CodeQL。
- 保持计时仅用于观察，测试分片（sharding）为可选。必需的 CI 必须继续运行完整的非分片 npm run test；确定性的本地分片仅能通过 npm run test:local -- --shard-index N --shard-count M 使用。

4. 按冲突感知顺序合并已接受的源码 PR。
- 在有用时先运行一次干跑分类（dry classification）。
- 对于变更的 skill 内容，审查确切的 head 并运行：

bash

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

- merge:batch 不重写 PR 正文，也不关闭或重新打开 PR。它评估当前的不可变 PR 元组，且可能仅批准绑定到该 PR 和确切 head SHA 的工作流运行。
- 对于敏感变更，仅凭同一仓库位置不足以作为权限证明。受保护的同一仓库异常仅限于由仓库所有者创建的 PR，且需要确切的全 head 证明；由协作人员创建的敏感 PR 在外部安全策略下默认失败（fail closed）。
- 常规的受保护检查包括 pr-policy、pr-evidence、source-validation 和 artifact-preview。已退役的 aas-v1-baseline 工作流不再是...

必须作为前置条件，且在 source 或 canonical-sync 批处理期间不得对其进行 await 或审批。

- 若 PR 的 head 或 base 发生变化，请丢弃过时的证据，刷新至当前的 origin/main 并重新运行批处理。该命令不会自动重试 base drift。

5. 在 source 批处理后仅进行一次 canonical 状态收敛。
- 等待受保护的 automation/canonical-repo-state PR。
- 验证其 managed-only diff、必要检查、合并结果以及最终的 origin/main。
- 若仍存在未管理的修复，请使用 topic PR；严禁直接 patch main。

工作流契约变更门禁 (Workflow Contract Change Gate)

在修改维护者脚本、工作流或策略时，必须在同一个 source PR 中同步更新 canonical skill、维护者文档和回归测试。针对每个修复的故障模式添加一个负面测试，运行相关的 dry-run 路径，并拒绝任何实现与文档不一致的情况。Source PR 必须排除生成的注册表和插件镜像；除非是受保护的 protected-release 流程脚本有意暂存的文件，否则该派生状态由受保护的 canonical-sync PR 掌控。

托管目录与旧版重定向桥接 (Hosted Catalog and Legacy Redirect Bridge)

将当前的目录（catalog）和旧版用户站点桥接视为一个统一的公共系统：

当前目录：sickn33/agentic-awesome-skills，地址为 https://sickn33.github.io/agentic-awesome-skills/。

旧版桥接：sickn33/sickn33.github.io，地址为 https://sickn33.github.io/antigravity-awesome-skills/。

针对 SEO、索引、Pages、重定向或基础设施的变更：

1. 通过受保护的 source PR 和 npm run merge:batch 修改源仓库中的生成器（generator）和验证器（verifier）。
2. 保持旧版部署的 managed allowlist 精确一致：.nojekyll、redirect-manifest.json 和 antigravity-awesome-skills/**。拒绝任何未管理的 sync diff 或 PR 文件。
3. 在旧版根目录下逐字节保留 Google 验证文件和 Bing msvalidate.01 meta 标签。在 manifest 证据中记录两者。
4. 保持 skill 计数动态更新，但保留刻意策划的 sitemap 锁定。对 manifest 契约变更进行版本化并记录源出处。
5. 由 legacy-redirect-sync.yml 生成或更新固定的自动化 PR。将新的验证器运行绑定到精确的目标 head SHA，验证其运行标识和 managed 文件集，仅在证明通过后发布所需状态，然后使用受保护的自动合并。
6. 合并前重新检查 source main；在机器人执行合并后显式请求 legacy Pages 构建，并等待该合并提交完成构建。
7. 逐字节验证本地生成的输出，然后验证所有实时的 legacy/current 重定向对以进行全面审计。针对瞬时 CDN 失败，应通过全面审计重试，而非接受部分探测结果。
8. 通过无漂移同步（no-drift sync）证明幂等性：不应运行任何替换、PR、验证或合并步骤；同时 Pages 和实时探测必须依然通过。

将两个仓库均保持在最小权限的 Actions 默认设置（read），并要求外部 action 必须固定到完整的 commit SHA。在更改这些设置或 action 版本时，在宣布完成前需重新运行 source CI、CodeQL、Pages 和一次 legacy no-drift sync。

AAS Core 预览验收

针对 AAS CLI、MCP、stack、catalog-cache 或 Workbench 的变更：

1. 使用 package.json 中声明的当前脚本；不要将已弃用的 evaluator、benchmark、tuning-gold、transaction-fault、race 或 frozen-matrix 门禁作为常规前置条件重新启用。
2. 运行 npm run test:aas-v1 执行核心测试，运行 npm run 执行目录完整性检查。
检查 aas-v1-catalog，并在其合约或文案变更时运行相关的 Workbench 测试/构建。
3. 保持 MCP 的本地化、离线、只读、有界且非 mutating（非变更）。编码代理负责检查项目、搜索并阅读完整目录，并选择准确的 skill ID。MCP 负责搜索、读取、验证代理拥有的组合并进行对比，且无需扫描仓库或向其写入。Core 不得对 skill 进行排序、推荐、排除或禁用；元数据仅供参考。
4. 保持 aas-stack.json 不包含 Core 选择策略。它仅固定目录标识、目标、目标值以及代理选择的准确 ID。compose_stack 负责验证并记录该选择；缺失或警告性的元数据绝不能导致规范的 skill 变得不可选或不可用。
5. 将支持的公共路径限制在清单验证（manifest validation）和不可变计划预览（immutable plan preview）阶段。规划阶段仅能写入请求的计划产物（plan artifact）；不得在目标中实例化 skill 负载或 AAS 管理状态。
6. 将 apply 和 recovery 视为支持预览范围之外的实验性可选功能。除非用户明确将其纳入范围，否则不要添加 apply/recovery、基准测试、模糊测试、崩溃/竞态测试或合成验证器工作。
7. 当任务要求端到端客户端证明时，请使用真实的受支持客户端来发现并调用本地 AAS MCP 工具；直接的 stdio 探测和自动化测试不能替代此类证据。
8. 在获得单独的发布批准之前，不要进行打标签、发布 npm、部署 Pages 或编写真实的用户 MCP 配置。

受保护的发布 (Protected Release)

仅在请求时发布。

每个稳定版或预发布版本都需要完整的发布对齐。创建标签、GitHub Release 或 npm 包仅是中间里程碑，而非完成条件。

1. 将目标变更日志条目包含在维护者批量 PR 中，确保其已进入受保护的 main 分支；避免创建仅包含发布说明的独立 PR。
2. 从干净且最新的 main 分支开始，运行 npm run release:preflight 及必要的安全检查。
3. 运行发布状态生成器及其明确的插件门禁。在发布前要求进行第二次无漂移（no-drift）检查：npm run sync:release-state、npm run plugin-compat:check 和 npm run bundles:check 必须保持树结构干净。检查 package.json、package-lock.json、生成的注册表和离线目录、跟踪的 Web 资产、.agents/plugins/marketplace.json、.claude-plugin/plugin.json、.claude-plugin/marketplace.json、每个已发布的 Codex/Claude 插件镜像，以及每个符合条件的 Agent Plugins 编辑捆绑清单。每个发布拥有的清单版本必须等于 X.Y.Z。
4. 运行 npm run release:prepare -- X.Y.Z。这将创建并推送 release/vX.Y.Z 并开启受保护的发布 PR。
5. 通过必要的检查合并该发布 PR，将本地 main 更新至与 origin/main 一致，并等待发布路径上的所有源码、发布或规范同步 PR 关闭。如果受保护的 main 分支发生了变动，请重新运行发布状态和插件门禁。
6. 运行 npm run release:publish -- X.Y.Z。它必须从同一仓库中解析出且仅有一个已合并的发布 PR，且该 PR 必须由仓库所有者创建，基准分支为 main，标题准确为 chore: release vX.Y.Z，头部分支为 release/vX.Y.Z。零个或多个候选者将导致失败（fail closed）；绝不要选择最新的近似匹配项。随后，该命令在创建或复用标签和 GitHub Release 之前，会验证该准确的受保护合并。
npm 发布工作流必须首先检出受保护的 main 分支，验证 t
确认剥离的 release 标签是当前 origin/main 的祖先，直接从该标签的 package.json 验证版本，随后才检出或执行标签控制的代码。该流程没有手动触发的绕过机制。

7. 等待发布工作流完成，然后将每项证明绑定到确切的发布提交：验证标签/引用、GitHub Release、npm 版本及预期的 dist-tag、必要的 CI、CodeQL，以及从不可变的 vX.Y.Z 标签明确触发的仅限发布的 Pages 构建。绝不要从 main 或其他分支触发 Pages。验证实时的 llms.txt、skills.json、目录和插件路由以及旧版重定向桥接；不接受不同 SHA 的成功运行结果。

8. 在 npm 确认 X.Y.Z 为已发布 dist-tag 后，从实际配置中发现所有已配置的本地 AAS MCP 主机，并在宣布发布完成前将每个主机更新至完全相同的包版本。更新现有的 AAS 主机条目是发布流程的一部分；而创建此前不存在的主机配置仍需显式授权。
- 使用已发布包的 aas mcp configure 两步流：首先预览更改，然后使用其批准摘要重复执行相同的命令。提供绝对主机配置、缓存和备份路径；在替换现有配置时要求备份。
- 固定 [email protected] 和 --version X.Y.Z；绝不要使用 latest、复用旧的缓存运行时，或在没有显式授权的情况下创建此前不存在的主机配置。
- 验证托管的主机配置指向内容寻址的 X.Y.Z 运行时，运行时包元数据报告为 X.Y.Z，且真实的 MCP initialize 与 tools/list 握手报告的目录包版本为 X.Y.Z。
- 必要时重启主机或开启新的客户端会话，以确保新的 MCP 进程被实际加载。如果配置访问、批准或运行时验证被阻塞，请报告确切的阻塞点，即使包本身已公开，维护者任务仍标记为未完成。

9. 在自动化稳定后再次获取 origin/main，快进维护者检出分支，并重复发布状态、插件、版本、公开界面和 MCP 一致性检查。最终的生成步骤必须是幂等的，目录树必须保持干净，且 git rev-list --left-right --count main...origin/main 的结果必须为 0 0。

绝不要对已发布的 release 标签进行 rebase，强制使用过时的发布状态，复用失败的已发布版本，或仅凭 GitHub Release 就声称 npm 已发布。

停止条件

仅在满足以下条件时结束：

所有范围内的 PR、Issue 和警报均已解决，或仅剩一个确切的阻塞点；

不再意外残留任何开启的开源或 canonical-sync PR；

对于每个稳定版或预发布版本，本地 main、origin/main、发布提交、规范生成的状态、每个 Codex/Claude 插件镜像、符合条件的 Agent Plugins 捆绑清单、捆绑包、市场、兼容性报告、标签、GitHub Release、npm dist-tag、必要工作流以及实时公开界面完全一致；

源码仓库和旧版仓库没有意外的基础设施 PR，其保护分支和 Actions 设置依然生效，且实时清单正确识别源码仓库；

除用户显式指定范围的文件外，用户工作区未发生变化；

当请求发布时，发布证明已完成，包括幂等且无漂移的重新生成，以及发布版本与运行时之间的一致性。

已发布的 npm 包以及所有已配置的本地 AAS MCP 主机。任何不一致都将导致发布不完整。

失败规则

若受保护分支拒绝推送，请切换至 PR 路径；绝不要尝试重新直接推送到 main 分支。

缺失 PR 检查清单仅作为信息提示；绝不要为了刷新模板元数据而修改、关闭或重新开启 PR。

保留无关的脏文件（dirty files），且绝不要将其添加到维护者的工作区中。

不要使用通用的 Git 辅助命令来绕过 merge:batch、规范同步（canonical-sync）或脚本化发布命令。

不要为了让批处理通过而降低测试或策略门槛。只有在获得维护者明确授权后才能废除门槛，且必须同步更新分支保护、工作流文件、合并自动化、文档及维护者技能，确保不留下任何冗余要求。

示例

对于一个已审核且其精确 head 为 0123456789abcdef0123456789abcdef01234567 的源 PR，在合并前请执行受保护路径：