| name | bridge-leak-check |
| description | 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". |
| metadata | {"scope":"core"} |
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 same data/renames.yaml)bridge-sync — uses this skill in Step 11 (post-merge verification)rules/promote-safety.md — diff-time content scan (different layer, complementary)
