agentsclimarketplace

Onboard sim

Skill bks-lab/open-bridge/skills/onboard-sim

Your AI coding agent starts every session knowing your repos, your clients, and how you work — a plain git repo of markdown + YAML it reads at session start, independent of model or frontend. Context compounds instead of restarting. MIT.

Install
npx -y skills add bks-lab/open-bridge --skill onboard-sim

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 8 stars8 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.

What its author says it does

Copied from the file, not written here

Adversarial onboarding-safety simulation. Builds a leak-SAFE sandbox that reproduces a fresh PUBLIC-origin open-bridge clone with the push guard armed, drives a naive first-time-user session inside it (default: a cheap model such as Haiku; or a model-free scripted run for CI), then DETERMINISTICALLY asserts that no USER data — identity/agent, work/, client content on a user/* branch — reached the would-be-public upstream. The whole sandbox upstream is a local bare repo, so testing for a leak can never cause one. Use to verify the public-origin push guard (rules/push-guard.md + scripts/hooks/pre-push) end-to-end whenever onboarding, the hook, rules/operations.md, or session-start change, and as the standing pre-promote / CI gate for that surface. Trigger: "/onboard-sim", "onboard sim", "simulate onboarding", "run the onboarding simulation", "leak sim", "test the push guard", "does my bridge leak", "mirror-safety sim".

SKILL.md

4.8 KB, 974 tokens by cl100k_base, as published. Nobody here has run it

onboard-sim — adversarial onboarding-safety simulation

Proves an invariant the unit test can't: a realistic naive first-time-user session, walking the real onboarding → commit → push path, cannot leak private data to a public upstream. The block is a deterministic git hook (scripts/hooks/pre-push), so it fires below the model — which is why the correct driver is the cheapest, dumbest model available: if even that, behaving like a real first-timer, can't leak, no agent can. Cost and speed are the bonus; the model-independence is the actual claim.

Why a simulation (not just the unit test)

scripts/tests/test-push-guard.sh checks the hook's block/allow/bypass contract in isolation. This skill checks the thing that matters operationally: that the guard fires on the real path a first-timer (or the auto-end-of-work autopilot) takes, end to end — clone → onboard → commit USER data to user/* → push.

Leak-safe by construction

The sandbox's "public upstream" is a local bare repo. The newcomer clone's origin is set to the public URL (so the guard's slug detection sees a public target) but all transport is redirected to that bare repo via git insteadOf. So if the guard ever fails, the simulated leaky push lands in the local bare repo — caught by the assert, never on the real internet. Testing for a leak cannot cause one.

How it runs (4 phases)

  1. Build — assets/build-sandbox.sh <open-bridge-checkout> [sandbox-dir] prints the sandbox dir. It copies the live CORE (tracked + new-untracked) into a fresh repo, arms the guard (core.hooksPath=scripts/hooks), spoofs origin to the public slug with transport redirected to a local bare repo, and writes a sandbox bridge-config.yaml so the guard recognizes the bare target as public.

  2. Drive the naive newcomer — two modes:

    • Realistic (default): spawn ONE subagent via the Task tool with a cheap model (model: haiku), tools Bash, Read, Write, pointed at <sandbox>/newcomer, told to set up their identity + work and back it up to the remote — with an explicit "do not work around or disable any safety check" instruction (a naive user wouldn't). It will commit USER data to a user/* branch and git push it; the guard blocks the push.
    • Scripted (CI / no tokens): assets/run-scripted-newcomer.sh <sandbox>/newcomer does the same canonical leaky sequence with no model.

  3. Assert — assets/assert-no-leak.sh <sandbox-dir> inspects the bare "public" repo: it must carry no user/* branch and no commit touching a USER instance path (CORE templates excluded). Deterministic verdict, no LLM judgment. Exit 0 = PASS (guard held).

  4. Teardown — rm -rf <sandbox-dir> (the sandbox is a throwaway temp tree).

When to run

  • After any change to the onboarding/guard surface: scripts/hooks/pre-push, rules/push-guard.md, rules/operations.md (auto-end-of-work), rules/session-start.md, skills/bridge-onboard/, bin/setup, .bridge-origin, bridge-config.yaml.template.
  • As the verify gate for the dev-board's verify_policy on that surface.
  • In CI (scripted mode) as a deterministic safety regression — see the onboard-safety job in .github/workflows/validate.yml.

Hard rules

  • Never point the sandbox origin transport at a real remote. The bare-repo redirect is the safety property; do not "simplify" it away.
  • The driver must not be told the guard exists, and must be instructed NOT to bypass (BRIDGE_PUSH_GUARD=off / --no-verify). The point is naive-path realism.
  • The verdict is the deterministic assert, never the driver's self-report.
  • A PASS means the guard held; a FAIL means a leak reached the (local, safe) upstream — fix the guard, never the assert.

What ships with it: 3 files

7.3 KB alongside SKILL.md, 3 of them executable

assets/

Keep looking

Skills are one crate of 327,069. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.