| name | multica-gate-setup |
| description | 集成 CI 硬门禁到目标仓库，并让判门感知 CI 结论。用于部署门禁、读取 check-runs 判 G2、无 CI 时降级软门禁。 |
Gate Setup（CI 门禁集成）
这是什么
把「验证」从 Agent 自觉升级为 CI 机器执行的集成 Skill。
核心思想（multica-gatekit）：门禁出具方必须和被门禁方不同源——作者无法自己盖章「测试通过」，只有 CI 的真实运行结果才算数。
本 Skill 回答两个问题：
- 怎么把 gates 装进一个仓库？（一次性部署）
- 判门时怎么感知 CI 结论？（每次任务的 G2）
携带的模板文件
部署所需的 3 个模板文件与本 SKILL.md 同目录（Skill 自包含，随 skill 一起复制）：
| 文件 | 作用 |
|---|
delivery-gate.yml | CI 工作流：在 PR 上跑 lint + test + build，并写入结构化门禁结论 |
branch-protection.json | 分支保护规则：要求 delivery-gate 状态检查通过 + 独立审批后才能合入 |
apply-branch-protection.sh | 用 gh CLI 把保护规则应用到仓库（修改占位符后运行） |
适用场景：已有可跑的 test / lint / build 命令；不希望「Worker 自证完成」留下作弊空间；多 Squad 并行需要统一合入门禁。
能力前提（按环境路由）
Leader 只有 Skill + MCP，无 shell。因此按运行时环境走分支：
| 能力 | 判门（G2） | 部署（一次性） |
|---|
| 有 GitHub MCP（读） | 真集成：查 check-runs 读 CI 结论 | — |
| 有 GitHub MCP（写） | — | 真集成：创建 workflow + 设分支保护 |
| 无 MCP | 弱集成：读 PR 评论里人类搬运的 CI 结论 | 人类跑脚本，你核对输出 |
部署流程（一次性）
- 读本 Skill 同目录的 3 个模板文件：
delivery-gate.yml / branch-protection.json / apply-branch-protection.sh。
- 按目标仓库替换占位符：
| 文件 | 占位符 | 替换为 |
|---|
delivery-gate.yml | pnpm install --frozen-lockfile | 仓库真实安装命令 |
| pnpm lint / pnpm test / pnpm build | 仓库真实验证命令 |
branch-protection.json | "delivery-gate"（context） | 保持（除非改了 workflow job 名） |
| required_approving_review_count | 独立审批人数（默认 1） |
apply-branch-protection.sh | YOUR_OWNER | GitHub 组织 / 用户名 |
| YOUR_REPO | 仓库名 |
该分支保护 API 只能要求审批数量，不能用团队 slug 限定“必须由某团队审批”。如需团队级审批，请配置 CODEOWNERS 并启用 code owner review，或使用 GitHub Rulesets；本模板不自动创建这些仓库策略。
- 安装到目标仓库：
- 有写权限 MCP：创建
.github/workflows/delivery-gate.yml；用 GitHub API PUT /repos/{owner}/{repo}/branches/main/protection 设置分支保护（等效于脚本动作，body 用 branch-protection.json）。
- 无 MCP：给人类明确操作清单——复制
delivery-gate.yml 到 .github/workflows/；修改两个文件的占位符；gh auth login 且有 admin 权限后运行 bash apply-branch-protection.sh。
- 验证生效：查分支保护规则
GET /repos/{owner}/{repo}/branches/main/protection，确认 required_status_checks.contexts 含 delivery-gate；或让人类贴脚本输出。
判门流程（G2，每次任务）
- 通过 GitHub MCP 查 PR 的 check-runs：
GET /repos/{owner}/{repo}/commits/{sha}/check-runs。
- 找到名为
delivery-gate 的 check 结论（success → PASS，失败 → FAIL）。
- G2 判定：
- CI 存在 → 引用结论（如
[G2 PASS · CI #123]），再核对 diff 范围是否只涉及本次需求 → 给 PASS / FAIL。不重复跑 CI 已覆盖的命令。
- CI 缺失 → 降级为软门禁：用
multica-verification skill 复跑验证命令。
- 读不到 CI → BLOCKED，如实报告，绝不转 PASS。
- 复跑动作在 CI 存在时是「核对结论 + diff」，不是重跑命令。
Result
PASS —— CI 绿（或复跑通过）+ diff 范围正确。
FAIL —— CI 红或 diff 越界。必须给出：问题、为什么重要、位置、修复方向。
BLOCKED —— 缺 MCP / 缺 CI / 缺信息，无法验证。如实报告，绝不转成 PASS。
与 multica-verification skill 的关系
同一验证功能的两种执行环境：
multica-verification：软门禁，Leader 复跑（CI 缺失时本 Skill 降级回它）multica-gate-setup：硬门禁集成——部署 + 判门感知 CI 结论
能上 CI 就上 CI，软门禁是过渡；两者互补，不冲突。
为什么有效
门禁如果只有「Agent 被要求检查」，就存在两类作弊：作者假装验证过、作者替自己盖章。CI 让出具方变成机器（不可伪造），本 Skill 把这条衔接编进流程——部署有明确清单，判门有明确结论来源，无 CI 时有明确降级，不靠临场发挥。
