| 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:
- How do you install gates into a repository? (one-time deployment)
- 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)
- Read the 3 template files in this Skill's directory:
delivery-gate.yml / branch-protection.json / apply-branch-protection.sh.
- 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.
- 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.
- 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)
- Query the PR's check-runs via GitHub MCP:
GET /repos/{owner}/{repo}/commits/{sha}/check-runs.
- Find the check named
delivery-gate (success → PASS, failure → FAIL).
- 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.
- 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.
