Bridge promote

Skill bks-lab/open-bridge/skills/bridge-promote

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 bridge-promote

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

Promote CORE changes from your user branch to upstream (Scope-Routing per scope: core → OSS upstream, org → your org overlay, user → local). Analyzes commits, categorizes by CORE/USER/ORG path+frontmatter rules, runs mandatory content-safety checks per repo (leak scanner + blocklist, refuses on PII/customer hits), and creates fork-based PRs to upstream repos — no upstream push access needed. For file-level community contributions with adaptation, use the bridge-contribute skill (/contribute) instead. Trigger: "/bridge-promote", "promote", "cherry-pick", "push to upstream", "promote to upstream", "promote commits".

SKILL.md

4.1 KB, as published. Nobody here has run it

Bridge Promote — Scope Routing

Routes commits from user/* to the right upstream based on scope: frontmatter (or path inference). See CLAUDE.md § Tier Model.

Commit scope	Goes to	How
`scope: core` (or unset, on CORE-allowlist path)	OSS upstream (e.g. `bks-lab/open-bridge:main`) plus your org overlay if configured	Cherry-pick to local `development`, then PR to the OSS upstream
`scope: org`	Your org overlay only (e.g. `<your-org>/<your-bridge>:development`)	Cherry-pick + PR to your org's overlay repo
`scope: user` / `private`	stays local on `user/{name}`	No-op

If you don't have an org overlay configured, only scope: core commits get promoted; scope: org commits stay on your user branch.

Read the referenced file ONLY when triggered.

Arguments

Argument	Effect	Default
`(none)`	Full promote workflow with scope-routing	—
`--dry-run`	Analyze only, don't cherry-pick or push	false
`--repo <name>`	Force destination (matches a name in `upstreams[]`), skip auto-routing	auto

Prerequisites

Current branch must be user/*. Refuses on development or main.
bridge-config.yaml.upstreams[] defines available targets — the template ships the shared OSS upstream (bks-lab/open-bridge, contribute: true) by default; optionally a <your-org>/<your-bridge> overlay.
For PR submission: gh authenticated. No push access to the upstream required — open-bridge PRs go fork-based (gh repo fork once, push the branch to your fork, gh pr create --repo bks-lab/open-bridge). See the bridge-contribute skill (skills/bridge-contribute/references/workflow.md § Step 5).
Your own leak roster in scripts/leak-patterns-internal.txt (local-only) — your customer/person patterns for the safety gate.

Decision Tree

User wants to...
├── Promote commits (auto-routed by scope)   → references/workflow.md
├── Dry-run analysis only                    → references/workflow.md (stop after Step 4)
├── Force one specific upstream              → references/workflow.md § --repo override
├── Scan branch for contributions            → bridge-contribute skill (/contribute)
├── Adapt/generalize content                 → bridge-contribute skill § Adapt mode
└── Questions about CORE/USER/ORG split      → Answer from CLAUDE.md § Tier Model

Safety

Before any cherry-pick or push, a mandatory two-layer content-safety gate runs — per destination repo:

python3 scripts/no-scrub-leak.py {outgoing files} — scripts/no-scrub-leak.py is a shared repo-root utility shipped with the Bridge repo itself, not a file inside this skill's own directory. It checks universal classes (absolute user paths, key/token shapes) plus your own roster from scripts/leak-patterns-internal.txt (you maintain your customer/PII regexes there; the shipped scanner cannot know them).
The blocklist scan from rules/promote-safety.md — the OSS upstream uses the strictest blocklist (no org/customer/personal leaks); your org overlay may use a relaxed one (customer refs OK, personal blocked). See bridge-config.yaml.promote.content_blocklist.

REFUSE path: personal-PII or roster hits exclude the affected files/commits from the PR — no override flag. Remediation: adapt via /contribute --adapt and re-scan, or drop them. Clean items still ship.