multica-gate-setup git:20260910.8db057cA

Immutable. This exact content is served forever at /api/v1/blob/6fa6823b41bfbe0a.

---
name: multica-gate-setup
description: Integrate CI hard gates into the target repository and make gatekeeping read the CI verdict. Used for deploying gates, reading check-runs for G2, and falling back to soft gates when there's no CI.
---

# Gate Setup (CI gate integration)

## What this is

An integration Skill that upgrades "verification" from agent self-discipline to machine-executed CI.
Core idea (`multica-gatekit`): **the gate issuer must be a different party from the gated** — authors can't stamp "tests passed" on themselves; only CI's actual run results count.

This Skill answers two questions:

1. **How do you install gates into a repository?** (one-time deployment)
2. **How does gatekeeping read the CI verdict?** (G2 on every task)

## Template files it carries

The 3 template files needed for deployment live in the same directory as this SKILL.md (the Skill is self-contained; copy them together with the skill):

| File | Purpose |
| --- | --- |
| `delivery-gate.yml` | CI workflow: runs lint + test + build on PRs and writes a structured gate conclusion |
| `branch-protection.json` | Branch protection rules: require the `delivery-gate` status check to pass + independent approval before merging |
| `apply-branch-protection.sh` | Applies the protection rules to the repo with the `gh` CLI (edit the placeholders, then run) |

Fit: you already have runnable test / lint / build commands; you don't want "Worker self-certifies done" to leave room for cheating; multiple squads in parallel need a unified merge gate.

## Capability prerequisites (route by environment)

The Leader only has the Skill + MCP, no shell. So branch by the runtime environment:

| Capability | Gatekeeping (G2) | Deployment (one-time) |
| --- | --- | --- |
| Has GitHub MCP (read) | **Real integration**: query check-runs to read the CI verdict | — |
| Has GitHub MCP (write) | — | **Real integration**: create the workflow + set branch protection |
| No MCP | **Weak integration**: read the CI verdict humans paste into the PR comment | Human runs the script; you verify the output |

## Deployment flow (one-time)

1. Read the 3 template files in this Skill's directory: `delivery-gate.yml` / `branch-protection.json` / `apply-branch-protection.sh`.
2. Replace the placeholders for the target repository:

| File | Placeholder | Replace with |
| --- | --- | --- |
| `delivery-gate.yml` | `pnpm install --frozen-lockfile` | The repo's real install command |
| | `pnpm lint` / `pnpm test` / `pnpm build` | The repo's real verification commands |
| `branch-protection.json` | `"delivery-gate"` (context) | Keep (unless you renamed the workflow job) |
| | `required_approving_review_count` | Independent approval count (default 1) |
| `apply-branch-protection.sh` | `YOUR_OWNER` | GitHub org / username |
| | `YOUR_REPO` | Repository name |

> This branch-protection API can require an approval count, but it cannot use a team slug to require approval from a specific team. For team-level approval, configure `CODEOWNERS` with required code-owner reviews or use GitHub Rulesets; this template does not create those repository policies automatically.

3. Install into the target repository:
   - **With write-capable MCP**: create `.github/workflows/delivery-gate.yml`; set branch protection with the GitHub API `PUT /repos/{owner}/{repo}/branches/main/protection` (equivalent to the script's action; body from `branch-protection.json`).
   - **Without MCP**: give the human an explicit checklist — copy `delivery-gate.yml` into `.github/workflows/`; edit the placeholders in both files; after `gh auth login` with admin rights, run `bash apply-branch-protection.sh`.
4. Verify it took effect: query the branch protection rules `GET /repos/{owner}/{repo}/branches/main/protection` and confirm `required_status_checks.contexts` contains `delivery-gate`; or have the human paste the script output.

## Gatekeeping flow (G2, every task)

1. Query the PR's check-runs via GitHub MCP: `GET /repos/{owner}/{repo}/commits/{sha}/check-runs`.
2. Find the check named `delivery-gate` (success → PASS, failure → FAIL).
3. G2 verdict:
   - **CI exists** → cite the verdict (e.g. `[G2 PASS · CI #123]`), then check whether the diff only touches this requirement → give PASS / FAIL. **Don't rerun** the commands CI already covered.
   - **CI missing** → fall back to the soft gate: rerun the verification commands with the `multica-verification` skill.
   - **CI unreachable** → BLOCKED, report honestly, never turn it into PASS.
4. When CI exists, the rerun action is "verify the verdict + diff", not rerunning commands.

## Result

**PASS** — CI green (or rerun passed) + diff scope correct.

**FAIL** — CI red or the diff is out of scope. Must provide: the problem, why it matters, where, and the fix direction.

**BLOCKED** — missing MCP / CI / information, cannot verify. Report honestly; never turn it into PASS.

## Relationship to the multica-verification skill

Two execution environments of the same verification function:

- `multica-verification`: soft gate, Leader reruns (this Skill falls back to it when CI is missing)
- `multica-gate-setup`: hard-gate integration — deploy + gatekeeping reads the CI verdict

**If it can run in CI, run it in CI**; the soft gate is transitional. They complement each other; they don't conflict.

## Why this works

If the gate is only "the agent was asked to check," two kinds of cheating remain: authors pretending they verified, and authors stamping themselves PASS. CI makes the issuer a machine (unforgeable), and this Skill encodes that handoff into the flow — a clear deployment checklist, a clear verdict source for gatekeeping, and a clear fallback when there's no CI. No improvisation required.