Bridge leak check
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.
npx -y skills add bks-lab/open-bridge --skill bridge-leak-checkAssembled 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
Content-leak scanner with categorized classification. Different from a raw blocklist grep: each hit is sorted into legitimate-self-reference, legitimate-sister-repo, personal-PII (always leak), or internal-vocabulary hardcoded (OSS-strict only). Use after a sync to verify the destination is actually clean — catches pre-existing leaks the source-side scan won't see. Also runs OSS-strictness vocabulary checks (e.g. "scope: bks" hardcoded in OSS-shipped skill docs that should use "scope: org" placeholder). Trigger: "/bridge-leak-check", "leak scan", "leak check", "OSS readiness", "pre-existing leaks", "cleanliness check", "is this OSS clean".
SKILL.md
4.8 KB, as published. Nobody here has run it
Bridge Leak Check — Categorized Content Scan
bridge-leak-check runs over a current repo state (not a diff), greps
the configured blocklists, and categorizes every hit into one of four
buckets so you don't drown in false positives. It complements
rules/promote-safety.md (which scans a diff per-destination at promote
time) by running on the post-merge state.
Read the referenced file ONLY when triggered.
Why both scans exist
| Scan | When | Scope | Strength |
|---|---|---|---|
rules/promote-safety.md | At promote time | Diff only | Catches leaks introduced by the current commit |
bridge-leak-check | Anytime | Whole repo state | Catches pre-existing leaks (from prior promotes, seedings, manual commits) |
The session that birthed this skill discovered that a clean source-side
scan does not guarantee a clean destination — open-bridge had three
pre-existing leaks (<your-username>-bks.yaml examples, com.bks.my-service,
bks wordmark) that no single promote scan caught because they predated
the per-repo blocklist.
Arguments
| Argument | Effect | Default |
|---|---|---|
(none) | Scan current repo with the matching blocklist (auto-detected from .git/config origin) | — |
--repo <name> | Force which blocklist to apply (open-bridge / org-overlay / your-bridge / fallback) | auto |
--strict-oss | Also flag internal-vocabulary hardcoding (uses vocabulary_renames from bridge-audit/data/renames.yaml) | false |
--report-only | Only show categorized report; don't suggest fixes | false |
--target-dir <path> | Scan a different working tree (e.g. /tmp/cloned-upstream) | . |
Categories
Every hit lands in exactly one bucket:
| Category | Marker | Example | Action |
|---|---|---|---|
| Legitimate — self-reference | ✅ ✓ | bks-lab/open-bridge inside the open-bridge repo, schema $id URLs that point at this repo's published schemas | Skip — this is correct |
| Legitimate — sister-repo | ✅ ✓ | {org}/bridge-deck cross-link in same OSS family | Skip — this is correct |
| Leak — personal PII | 🔴 | <your-username>, <your-username>, ~/, personal hostnames | Always fix — replace with <your-username> placeholder |
| Leak — internal vocabulary (OSS-strict) | 🟡 | an org-shortname scope value (e.g. scope: acme) in shipped skill docs, a hardcoded org-bridge overlay slug as the only "internal overlay" example | Generalize — see vocabulary_renames in bridge-audit/data/renames.yaml |
Decision Tree
User wants to...
├── Verify a fresh clone is OSS-clean → references/classification.md § standard scan
├── Categorize hits in current repo → references/classification.md § standard scan
├── Run on a temp clone (post-merge verify) → --target-dir <path>
├── Add a new self-reference exception → edit references/classification.md § exceptions
└── Add an internal-vocabulary rename → edit bridge-audit/data/renames.yaml § vocabulary_renames
Output Shape
Bridge Leak Check — <repo>:<branch> (<timestamp>)
Blocklist: open-bridge (strict)
✅ Legitimate self-reference (5 hits, no action needed)
bks-lab/open-bridge schema $id URLs — 5 files
✅ Legitimate sister-repo (1 hit, no action needed)
docs/calendar.md:110 → github.com/{org}/bridge-deck
🔴 Personal PII leaks (0 hits)
None — clean ✓
🟡 Internal-vocabulary hardcoded (3 hits — strict-OSS mode)
skills/bridge-promote/SKILL.md:24 — "scope: org" should be "scope: org"
skills/bridge-onboard/SKILL.md:31 — "internal org-bridge" should be "<your-org>/<your-bridge>"
infra/channels/_schema.yaml:101 — "com.bks.*" should be "com.example.*"
Verdict: 3 OSS-strict findings (yellow). No personal PII. No customer codenames.
See also
bridge-audit— drift detection (sibling skill; uses the samedata/renames.yaml)bridge-sync— uses this skill in Step 11 (post-merge verification)rules/promote-safety.md— diff-time content scan (different layer, complementary)