Gated dual clone
Dual-repo git workflow bootstrapper for projects where upstream branches are protected (MR/PR required) and builds are heavy. Creates a gateway repo (push source) and a satellite repo (fetch-only build tree), with three safety gates verified post-setup and a daily-workflow cheatsheet. 双仓库 MR/PR 流 git 工作流搭建器。适用于上游分支受保护 + 编译重 + 需物理隔离防 误推的项目。 TRIGGER: "dual clone workflow", "gateway repo", "verify repo", "compile sandbox", "protected branch workflow", "双仓库工作流", "编译仓库", "gateway 仓库", "set up dual clone". DO NOT TRIGGER: single-repo direct-push flow, pure worktree setup, monorepo package management, small projects where one clone is enough.From its SKILL.md
npx -y skills add TbusOS/sky-skills --skill gated-dual-cloneAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
11.3 KB, as published. Nobody here has run it
Gated Dual-Clone Workflow
One-liner · 一句话
EN — Clone the upstream twice: a gateway repo that pushes, and a
satellite repo that builds. The satellite's origin points at the local
gateway path — so a stray git push from the compile tree is physically
unable to reach the remote.
ZH — 把上游仓库 clone 两份:一个 gateway 仓库负责 push,一个
satellite 仓库只读编译。satellite 的 origin 指向本地 gateway 路径,
编译树里误跑一条 git push 在物理上也够不到远程。
Should I use this? · 该不该用
→ See references/decision-checklist.md
Four yes/no questions. Three or more "yes" → use this skill. Otherwise fall
back to a single repo or git worktree.
四道是非题:≥ 3 个 yes 用本 skill,否则单仓库或 git worktree 更合适。
Minimal bootstrap · 最小搭建
scripts/bootstrap.sh \
--remote [email protected]:team/project.git \
--upstream-branch release \
--push-branch feature/alice-auth \
--gateway-dir ~/projects/foo-work \
--satellite-dir ~/projects/foo-verify \
--user-email [email protected] \
--user-name alice
All 7 flags are required. --dry-run prints the command sequence without
executing. --force is only valid for empty target dirs (non-empty is always
rejected; clean up by hand first). See scripts/bootstrap.sh --help for
detail.
Post-setup · 搭建完成后(3 道闸)
bootstrap.sh verifies three safety layers before exiting 0:
- Gate A · Protocol wall —
cd satellite && git pushrejected ("DISABLED" in error). Satellite'soriginis a local path; no network route to upstream exists. - Gate B · Explicit disable — Satellite's push URL is literally set to
DISABLED, so even malformed config still errors fast instead of silently trying. - Gate C · Pre-push hook — Gateway's
pre-pushhook rejects any push to a protected-branch regex (default: the upstream branch passed in).
Gate failures halt bootstrap with a clear reason — nothing is left in a partial state that the user has to hand-clean.
三道闸都过才算 bootstrap 成功。任一失败会明确说明原因,不留一半成品。
Daily operations · 日常操作
→ See references/daily-workflow.md
The core loop: edit in gateway, sync satellite with scripts/sync-satellite.sh,
build in satellite, push from gateway, open MR/PR. Four commands, copy-paste
ready.
日常 4 步:在 gateway 里改 → sync-satellite.sh 同步到 satellite →
satellite 里编译 → gateway 里 git push → GitLab / GitHub 上发 MR/PR。
cheatsheet 里每步都是现成命令。
Safety model · 安全模型
Three layers, each independent. Any one holds; all three together is belt, braces, and shoulder strap.
- Protocol layer — satellite's
originis a file path; no TCP/SSH route to upstream exists from the compile tree. - Config layer — satellite's push URL = literal
DISABLED. Explicit failure mode. - Hook layer — gateway's
pre-pushhook rejects protected-branch refs.
Critical caveat · 关键注意: Client-side git hooks are advisory, not
enforcement. --no-verify bypasses them. Real protection = server-side
protected-branch rules in GitLab / GitHub / Gerrit. This skill's hook is a
second layer — catches finger-slips, not determined bypass. Enable
server-side branch protection alongside.
客户端 hook 只是提醒,不是强制边界。--no-verify 可以绕过。真正的保护
在托管平台的 protected-branch 规则上。本 skill 的 hook 是第二层,接手滑,
不防恶意。服务端保护一起开。
Variants · 变体
- 1 gateway + N satellites — run
bootstrap.shagain with--skip-gateway+ a new--satellite-dir. Useful forverify/debug/testtrees. - 3-clone with reproducibility gate (see below) — add a
clean-verifyclone on separate disk/machine, with a pre-push hook that refuses to push anything clean-verify hasn't stamped. Trade extra disk + extra build time for catching "works on SSD, fails on HDD / CI" bugs before they reach upstream. - Worktree fallback — if disk is tight (< 2× source size) and single
developer, single machine:
git worktreetrades isolation for disk. Seedecision-checklist.mdfor when worktree beats this skill. - Hosting differences — GitLab MR, GitHub PR, Gerrit push-to-
refs/for/*. The skill is host-neutral; protected-branch regex is a per-project flag.
Optional 3rd clone · reproducibility gate · 可选 第 3 仓 · reproducibility 关卡
For projects where a failed build on CI (different filesystem, different disk speed, different filesystem cache state) has a real cost — add a clean-verify clone on a separate disk (or separate machine) and gate every push on a from-scratch full-build in it.
When to use (all four should be true):
- Daily dev happens on SSD; CI / shipping happens on HDD or remote machine.
- The project has reproducibility bugs that only surface from a cold, clean tree (SSD cache / generated files / stale build artefacts hide them on the iteration clone).
- The push path is high-stakes (production branch, signed release, audit trail required).
- The team already has discipline to run a pre-push command.
Topology:
┌──────────┐ ┌──────────┐ ┌───────────────────┐
upstream ───► │ gateway │ ────► │satellite │ │ clean-verify │
(push only │ (dev + │ sync │ (build · │ │ (pre-push gate · │
from gateway) │ push) │ via │ disabled│ │ HDD / diff disk)│
│ SSD │ local │ push) │ │ │
└──▲───────┘ path └──────────┘ └───▲───────────────┘
│ │
│ pre-push hook reads .git/last-clean-verify
│ and refuses to push a commit whose sha ≠ stamped
│ │
└─── clean-verify-run.sh stamps on success ─┘
Bootstrap it:
scripts/bootstrap.sh \
--remote [email protected]:team/project.git \
--upstream-branch release \
--push-branch feature/alice-auth \
--gateway-dir ~/projects/foo-work \
--satellite-dir ~/projects/foo-verify \
--clean-verify-dir /mnt/hdd/foo-clean-verify \
--user-email [email protected] \
--user-name alice
Same as the 2-clone bootstrap, plus --clean-verify-dir=<path>. The
script adds:
- Step 5b —
git clonethe clean-verify from gateway (same local-path trick as satellite · origin on a local path, never the real remote). - Step 6b — set
pushurl = DISABLEDon bothoriginand the diagnosticupstreamremote. Check out<push-branch>. - Gate D — in Step 7 post-setup, verify clean-verify push is DISABLED.
- Pre-push hook gets a 2nd gate —
install-hooks.shis invoked with--enforce-clean-verify, which adds a "stamp match" check alongside the protected-branch check.
Daily flow (5 steps instead of 4):
- Edit in gateway, commit.
sync-satellite.sh→ satellite → build + test there (fast iteration).- When ready to push, run:
This syncs clean-verify from gateway, runsscripts/clean-verify-run.sh \ --gateway-dir=<gw> --clean-verify-dir=<cv> \ --push-branch=<br> --build-cmd='<full-build command>' --yesgit clean -fdx(drops every untracked/ignored file), runs your full build end-to-end, and on success writesgateway/.git/last-clean-verify. git push origin <push-branch>— the hook reads the stamp, refuses if commit doesn't match. Emergency bypass:git push --push-option=allow-unverified(use sparingly; the point of the gate is that it holds).- Raise MR/PR.
What this catches that 2-clone doesn't:
- SSD-only bugs: code depends on files that happen to be in OS filesystem cache on the dev SSD but not on a cold HDD.
- Stale-artefact bugs: satellite has build products from an earlier commit
that accidentally satisfy a missing
#include/ missing codegen that the current commit wouldn't produce fresh. - Dirty-tree bugs: satellite has hand-edits the author forgot about; they pass the build; clean-verify starts from git HEAD and fails.
- Build-command drift:
--build-cmdis sha256-hashed into the stamp; if team changes build command out from under you, next push asks for a re-verify.
Paired evaluator: gated-dual-clone-audit auto-detects 3-clone mode
when you pass --clean-verify-dir, and runs 4 extra gates (S9-S11 + C9 +
B4) to re-verify the topology on demand.
Files · 文件
scripts/bootstrap.sh— the main setup command, runs all 8 steps + 3 gates (4 gates in 3-clone mode) · accepts optional--clean-verify-dirscripts/sync-satellite.sh— fetch / reset-hard / merge-ff modes for syncing satellite from gatewayscripts/clean-verify-run.sh— sync + clean + full-build + stamp · the pre-push reproducibility gate for 3-clone modescripts/install-hooks.sh— writes thepre-pushhook on the gateway ·--enforce-clean-verifyadds the stamp-match gatereferences/decision-checklist.md— when to use / when not to usereferences/daily-workflow.md— 4-step cheatsheetreferences/patterns.md— N-satellite / worktree fallback / GitHub-GitLab-Gerrit shapesreferences/guardrails.md— why the three gates work / when they break / how to verifyreferences/server-side-enforcement.md— GitLab / GitHub / Gerrit / pre-receive / Actions templates (real enforcement beyond advisory client-side hook)references/troubleshooting.md— 10 common failures, symptom → diagnose → fix → preventreferences/comparison.md— dual-clone vs worktree vs single-repo, 11-dimension table
Reference · 参考
- Anthropic · harness design for long-running apps
- Full design spec:
docs/design-mr-gated-dual-repo.md - Live demo:
demos/gated-dual-clone/index.html