agentleFS
Sign inStart free
bks-labbks-lab/open-bridge/skills/bridge-leak-check/SKILL.md

bridge-leak-check

Skill13 starsChanged 14 days agoMITView on GitHub

Content-leak scanner for Bridge repos: classifies hits as self-reference, sister-repo, personal PII, or hardcoded internal vocabulary (OSS-strict). Verifies a sync destination is actually clean. Trigger: "/bridge-leak-check", "leak scan", "leak check", "OSS readiness", "cleanliness check", "is this OSS clean".

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the referenced file ONLY when triggered.

    line 21
  2. Distinctive:

    Every hit lands in exactly one bucket:

    line 48

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

ScanWhenScopeStrength
rules/promote-safety.mdAt promote timeDiff onlyCatches leaks introduced by the current commit
bridge-leak-checkAnytimeWhole repo stateCatches 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

ArgumentEffectDefault
(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-ossAlso flag internal-vocabulary hardcoding (uses vocabulary_renames from bridge-audit/data/renames.yaml)false
--report-onlyOnly show categorized report; don't suggest fixesfalse
--target-dir <path>Scan a different working tree (e.g. /tmp/cloned-upstream).

Categories

Every hit lands in exactly one bucket:

CategoryMarkerExampleAction
Legitimate — self-reference✅ ✓bks-lab/open-bridge inside the open-bridge repo, schema $id URLs that point at this repo's published schemasSkip — this is correct
Legitimate — sister-repo✅ ✓{org}/bridge-deck cross-link in same OSS familySkip — this is correct
Leak — personal PII🔴<your-username>, /Users/<your-username>/, personal hostnamesAlways 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" exampleGeneralize — 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)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free