bks-lab
OrganizationYour 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.
Categories
Indexed Skills (36)
board-pilot
Generic, board-driven implementation pipeline: polls a GitHub Project on a schedule, ARMS an item the moment a human drags it into the configured trigger column, then advances it one stage per tick — each stage a Bridge primitive (skill / workflow / agent / cmd) — and STOPS at a human-gated draft PR. The engine is project-agnostic; everything project-specific (which stages, which handlers, the trigger column, the rework budget, the criteria each stage judges against) lives in per-project `board:`/`pipeline:` blocks in workflow/projects/<slug>.yaml. An engine-owned `Pipeline` field is the durable program counter, kept distinct from the human-owned `Status` column, so a person moving a card mid-flight can never corrupt the state machine. Fail-closed engine guards: PAUSED kill-file, atomic snapshot, lock liveness via kill -0, argv-safe handlers, draft PRs, byte-0 reject marker, board-option preflight, a durable rework cap, blind-rework park, engine-written evidence, and a human-Done halt (the token ceiling is IN
bridge-audit
Auditing skill for The Bridge repos — finds drift between docs and reality (license badge ↔ LICENSE file ↔ footer; README skill list ↔ skills/ dir; protocol counts; renamed-but-not-everywhere; broken cross-refs; missing scope frontmatter; routing-SoT conflicts; common typos; user-level skill shadowing between instances; cross-repo skill-tree sync coverage with --cross-repo). Returns a P0/P1/P2/P3 stratified report with concrete fix proposals — the same output shape that a human-led drift-audit would produce. Trigger: "/bridge-audit", "audit", "drift check", "bridge audit", "check consistency", "find drift", "is README still accurate", "are my skills shadowed", "whose skills are running".
bridge-contribute
Contribute features and improvements from your Bridge back to the open-bridge OSS upstream (or your org overlay) as a fork-based pull request. Scans your user branch for upstream-worthy files, classifies them by scope, adapts org-specific content, runs the MANDATORY two-layer content-safety gate (leak scanner + per-repo blocklist, refuses on PII/customer hits), and opens the cross-fork PR with DCO sign-off — no upstream push access needed. Trigger: "/contribute", "contribute", "upstream contribution", "contribute to upstream", "contribute upstream", "submit improvement", "share my skill", "send this to open-bridge", "PR to upstream", "PR to overlay", "give back", "submit a feature".
bridge-curator
Periodic background consolidation pass over the Bridge itself. Three phases: (1) Library pass — scans skills/, protocols/, rules/, docs/ for drift (sleeping skills 30d+, overlapping triggers, description-budget busters, duplicates, umbrella candidates); (2) Queue pass — scans work/_learning/proposals/ for stale pending (30d+), conflict clusters (same target), supersedes relations; (3) User-pattern pass — synthesizes 3-8 bullet observations about user preferences from postmortems + audit-trail + trigger-corrections of the last 30 days, writes append-only to work/_learning/user-patterns.md. All findings land as proposals (source.type=curator-suggestion) in work/_learning/proposals/ — **never direct edits to Bridge files**. Trigger: "/bridge-curator", "bridge curator", "curator", "curation", "weekly review", "library consolidation", "consolidate skills", "what patterns do I have", "user pattern synthesis", "consolidate", "skill consolidation", "umbrella skill".
bridge-dashboard
Generates the Bridge Control Center — a single-file HTML dashboard that bundles Fleet (infra/remotes/), Work Board, Calendar (next 24h), Channels, Git activity, optional Bridge-Deck /metrics, and upstream drift into one view. Stands alone; the pixel-art Bridge-Deck renderer it can complement is not yet public (coming soon). Trigger: "/bridge-dashboard", "bridge dashboard", "control center", "ops dashboard", "open dashboard", "show me everything at a glance".
bridge-explorer
Bridge visualizations — ecosystem (repos, workspaces, skills, infra), repo layout (CORE/USER split, 4 brain-metaphor variants v1–v4), and constellation (5-layer information network with hub-out routing). Single-file HTML, dark/light, opens in browser. Descriptions sourced from docs/repo-layout/regions.yaml. Trigger: "/bridge-explorer", "explorer", "show ecosystem", "repos overview", "repo layout", "core/user split", "where do files live", "repo structure", "network diagram", "constellation", "information flow", "how is everything linked".
bridge-greeting
Context-aware terminal greeting (MOTD) for Bridge instances — renders a per-instance logo, palette, today's filtered calendar, the instance's "Doing" board and uncommitted work, resolved from which org folder the terminal was opened in. Includes gen-logo.py (ANSI-Shadow logo generator from a word) and the branding convention that feeds every Bridge UI. Trigger: "/bridge-greeting", "terminal greeting", "motd", "startup logo", "instance logo", "terminal greeting", "fastfetch logo", "branding", "generate logo", "per-folder terminal", "folder logo".
bridge-leak-check
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".
bridge-learn
Review surface for Bridge Learning-Loop proposals — lists pending improvement suggestions from work/_learning/proposals/, groups by severity (P0 → P3), walks the user through each proposal with accept/reject/edit/defer decisions. Accept applies the diff_preview (or asks the user for the patch), moves the proposal file to proposals/accepted/, logs to audit-trail.md, and suggests a commit message. Reject asks for a one-line reason, moves to proposals/rejected/, logs. Optional trends section shows audit-history recurring findings and sleeping skills (Phase 3+4 data). Auto-surfaces in /briefing on Fridays when N+ pending (threshold in bridge-config.yaml.learning.proposals.auto_surface_threshold). Trigger: "/bridge-learn", "bridge learn", "review proposals", "learn review", "what did we learn", "pending proposals", "improvement queue", "review improvements", "check proposals", "review improvements", "what have we learned".
bridge-onboard
New user onboarding and reconfiguration — discovery-driven setup with permission-gated system scan, evidence-based feature suggestions, and a read-only catalogue of what else Bridge can do. Six-phase wizard (Identity / Discovery / Suggestions / Quick-Wins / Catalog / Validate) with re-entry modes for targeted later activation. Works without GitHub. Upstreams stay empty by default and wire later when the OSS upstream or your own upstream is live. Trigger: "/bridge-onboard", "onboard", "setup", "configure bridge", "new user", "ecosystem scan", "set up bridge", "reconfigure", "reconfigure bridge", "setup wizard".
bridge-overlay
Subscribe a Bridge to an ORG OVERLAY — a git repo an organisation publishes that ships its shared config (contexts, projects, mandants, accounts, org skills/agents/standing-orders, an ecosystem fragment) as a flat mirror tree. /overlay add <git-url> sparse-clones the overlay, validates its manifest, previews a per-file plan with risk flags, and materializes COPIES into your repo under a lockfile — never block-merging your config, never clobbering your edits (3-way merge), never touching CORE. sync/apply/status/diff/remove/list manage the subscription over time. The overlay is the LOWER layer; your user files always win. Trigger: "/overlay", "org overlay", "subscribe to overlay", "materialize org config", "pull org overlay", "unsubscribe overlay", "add org config by git url", "list overlays", "overlay status", "overlay diff".
bridge-promote
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".
bridge-sync
End-of-sprint batch-sync: pushes ALL pending scope:core + scope:org commits from the local user branch to BOTH upstreams (open-bridge + your org overlay) in one operation, with per-destination scrubbing and parallel PR creation. Complements /promote (per-commit) and /contribute (per-file) with a sprint-level workflow. Trigger: "/bridge-sync", "sync to upstreams", "push to both", "batch promote", "end-of-sprint sync", "sync all pending", "push everything to both repos".
briefing
Daily briefing — board, ecosystem activity, tracker sync, goals. Parallel 4-stream collection. Modes: --quick, --html. Trigger: "/briefing", "briefing", "good morning", "daily standup", "checkin", "morning briefing". (Bare "status" → bridge-status; bare "what is up" → dashboard.)
capability-broker
Turns a capability gap into a gated acquisition. When the user needs a tool or capability the Bridge can't do yet — and no existing skill, CLI, MCP, or account covers it — this skill runs a false-gap guard, then OFFERS (never auto-acts) to either research + provision the right tool, or scaffold a dedicated skill, and captures the outcome as a learning so the gap never recurs unaddressed. It is the forward / acquisition arm of the Bridge learning loop (the retrospective arms are task-close-postmortem, bridge-audit, bridge-curator); it composes with them and with rules/learning-autonomy.md, never reinventing them. Hands skill authoring to skill-creator and bounded research to deep-research. Trigger phrases: "the bridge can't do that", "you can't do X yet", "there's no skill for this", "we don't have a tool for", "set this up so it sticks", "build a skill for this", "is there a tool that", "capability gap", "self-extend", "teach yourself to", "add this capability".
dashboard
Project dashboard showing GitHub/ADO tasks, git activity, and deployment status. Auto-detects project context from CWD, ecosystem.yaml, and workflow/projects/*.yaml. Trigger: "/dashboard", "/dashboard --all", "/dashboard --html", "show dashboard", "show tasks", "what is up", "project status".
debrief
Meeting and transcript processing — classifies meeting type, applies name corrections, extracts insights across 7 categories, generates protocols, proposes tasks with project field mapping. Checkpoint-based workflow. Supports full 8-phase flow (with GitHub reconciliation + distribution email) and quick 5-phase flow; `--all` and `--date YYYY-MM-DD` batch flags absorb the former /process-meeting. Trigger: "/debrief", "/debrief {path}", "/debrief --quick", "/debrief --all", "/debrief --date YYYY-MM-DD", "process meeting", "transcript processing", "create minutes", "process-meeting", "meeting minutes", "process transcript".
doc-system
Document management — inbox scan, processing, and status monitoring. Scans configured import sources (e.g. PARA, Johnny Decimal, custom), categorizes documents, applies routing rules from workflow/contexts/doc-system.yaml plus persona destinations from identity/personas/{id}.yaml. Renames, tags, files, and audits in work/doc-system/log.md. Trigger: "/doc-system", "doc inbox", "doc process", "doc status", "process documents", "scan documents", "document queue".
github-projects-manager
Execute GitHub Projects V2 operations — issue creation with automatic project board placement, custom field updates (single-select, text, number, date), batch field transitions, board queries, and board-hygiene audits (coverage: open issues not on the board; reconciliation: board Status vs the issue's real state/close-reason). Reads field schemas from workflow/projects/*.yaml configs. Works with gh CLI + GraphQL mutations. Trigger: "create issue", "set field", "update billing scope", "batch update approval", "board query", "add to project", "set status", "classify issue", "audit board", "board hygiene", "reconcile board", "orphan issues", "issues not on the board", "is everything on the board", "declined but not closed".
html-canvas
Build rich, polished SINGLE-FILE HTML deliverables — explainers, reference pages, concept/architecture visualizations, use-case kits, multi-section documents — with a light/dark theme toggle, a DE/EN language toggle, tasteful animations, and DESIGN.md-driven tokens, all offline with zero dependencies. Use whenever the user wants content turned into a good-looking HTML page or kit, or says 'create an HTML page', 'visualize this as HTML', 'explainer', 'html kit', 'single-file html', 'html with light and dark', 'theme toggle', 'language toggle', 'analyze this repo as an explainer' — even if unnamed. Ships a copy-paste shell, a section-block catalog, an animation layer, optional JS behaviours, a DESIGN.md→CSS token generator, and a parallel-builder workflow. NOT for live Bridge ops dashboards (bridge-dashboard), repo/ecosystem maps (bridge-explorer), or slide decks / styled emails / PDFs / marketing landing pages (use the dedicated skills if your Bridge ships them).
knowledge-repo-init
Guided wizard for connecting or scaffolding an optional knowledge / documentation repo to a Bridge instance. Walks the user through layout choice, area picks, frontmatter conventions, optional dual-doku contracts, Bridge wiring (ecosystem.yaml + workflow/contexts/), and copies template skeletons from docs/examples/knowledge-repo/. Trigger: "/knowledge-repo-init", "knowledge repo", "knowledge-repo", "set up wiki", "set up docs", "scaffold wiki", "add knowledge repo", "connect knowledge repo", "docs repo", "documentation repo", "wiki setup".
meeting-transcription
Operates and manages a context-aware meeting-transcription pipeline (2-track or single-mix recording → whisper.cpp large-v3 + pyannote diarization on a worker host → voice-matched speaker names → naked transcript delivered to /debrief; the summary is made later by the in-session /debrief, never by the worker). The reference implementation of the transcription-worker contract (docs/transcription-worker.md). Use this skill WHENEVER the user wants to transcribe a meeting, set up or change a transcription context/folder, add or re-train a speaker voice, reprocess a recording, extend the pipeline, or troubleshoot it — even if they don't name the pipeline explicitly. Triggers: "transcribe a meeting", "transcription folder", "new transcription context", "add a speaker", "train a voice", "voice library", "speaker recognition", "speaker diarization", "who said what", "reprocess recording", "transcribe pipeline", "update the whisper model". Also use it to answer "how does my transcription system work" — it is the sourc
onboard-sim
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".
project-advisor
Governance and execution for GitHub and ADO projects — reads per-project configs from workflow/projects/*.yaml for field values, governance rules, and state mappings. Handles issue creation, field updates, board health validation. Trigger: "create issue", "board health", "project setup", "check governance", "update field", "convert drafts".
remote
Owns `infra/remotes/*.yaml` — fleet ops (inventory, WoL, SSH/RDP, reachability, shutdown/reboot) + service ops (health, logs, restart, deploy). "remote" = physical machine, not git remote. Triggers: "remote", "my PC", "my machines", "fleet", "wake", "WoL", "ssh to", "RDP", machine names (homeserver, workstation, laptop, router).
spec-kickoff
Guides you through a spec-first kickoff before building anything substantial — Andrej Karpathy's three layers (spec → verifier → environment), expressed through Claude Code's own primitives, not a new framework. Phase 1 interviews you down to a self-contained SPEC.md with EARS requirements (you own the goal, the agent does the thinking). Phase 2 builds a verification plan: maps every acceptance criterion to the strongest available check (deterministic > external signal > judge), picks a gate strength, and optionally adds a fresh-subagent or Codex adversarial review. Phase 3 wires it into the environment you already have (CLAUDE.md, skills, hooks, guardrails) instead of rebuilding it. Output is ONE SPEC.md that ends in an end-to-end verification step, then a handoff to the build. Use when STARTING a new build/feature/project and you want to begin it right — NOT for trivial changes you can describe in one sentence. Trigger phrases — EN: "spec-kickoff", "kickoff", "spec this", "spec first", "before we build", "h
task-close-postmortem
Postmortem capture + bridge-improvement scan at task close. Surfaces six optional questions (time invested, estimate vs actual, what went well, what burned time, where the bridge fell short, concrete improvement proposal), writes structured frontmatter back to STATUS.md, and generates proposal files under work/_learning/proposals/ for later review via /bridge-learn. Invoked automatically by protocols/standing-orders/task-sync.md Phase 3b at task close, and directly user-invokable for ad-hoc reflection. Trigger: "task done", "document everything", "wrap up", "wrap-up", "task complete", "post-mortem", "/postmortem the last hour", "reflect on the piece just finished", "review the last block", "what did we learn from X".
tracker-sync
Persistent snapshot + bidirectional reconcile between The Bridge tasks and GitHub Project boards. Pulls each board into work/trackers/<provider>/<slug>.json (the local mirror / dump), diffs it against work/tasks|streams/*/STATUS.md sync.github bindings into a delta table (in_sync · remote_ahead · local_ahead · state_mismatch · orphan_local · orphan_remote), and pushes local→remote changes through github-projects-manager — gated, never auto. GitHub is the system of record, The Bridge is the cockpit (remote-authoritative). Trigger: "/tracker-sync", "tracker sync", "sync my tasks", "reconcile tasks", "board reconcile", "snapshot github", "which task is in which state", "github project dump", "sync tasks down", "sync tasks up", "task drift", "sync status".
workspace
Bind code repos AND config overlays into a named WORKSPACE — a project container with a machine-global identity (shared with any conformant tool via ~/.workspaces/) and repo-local materialization (clones under .bridge/, lockfiles, a public-fork-safe exclude guard). `workspace create <name>` seeds the definition; `subscribe … --role code` clones a member repo; `subscribe … --role config` delegates a config overlay to the /overlay engine; `list` / `status` / `validate` inspect; `unsubscribe` removes. Standalone — zero dependency on any external launcher; the shared identity write is additive and warns-never-fails. Trigger: "/workspace", "workspace", "create a workspace", "add a repo to my workspace", "bind repos", "workspace status", "list workspaces", "subscribe repo to workspace", "unsubscribe from workspace", "workspace members", "project container".
example-org-coordinator
Single entry point for the example-org engagement — board sync against the example-board GitHub Project, status-report prep for the example-team mandant, documentation routing through the example-docs context, and tenant-aware cloud lookups via example-cloud. Reads field schemas from workflow/projects/example-board.yaml; routes per rules/org/example-routing.md. Trigger: "example-org", "example board", "example-org status", "example-team update", "sync example-org".
archive
Archive the current week — collect log entries, generate summary, reset log.md, check upstream. Supports --force mode. Trigger: "/archive", "archive", "archive week", "week archive", "week wrap-up".
bridge-status
Bridge health dashboard — shows branch, config, theme, ecosystem, agents, standing orders, work system, and repo status. Flags missing files, KW drift, and configuration problems. Includes documentation health and link checking. Trigger: "/bridge-status", "bridge status", "bridge health", "health check", "docs health", "link check", "documentation quality", "pre-release gate". (Bare "bridge" and bare "status" are intentionally NOT triggers — too broad, would collide with bridge-sync/bridge-dashboard/briefing.)
calendar
Calendar and recipient management — list, add, show, cancel, confirm scheduled entries. Manages mandant recipient groups (company, household, family, friends, colleagues) and workflow/calendars/entries.yaml with multi-recipient support, duration estimates, and repeat patterns. Trigger: "/calendar", "calendar", "scheduled messages", "calendar add", "calendar list", "mandants", "recipients", "recipient groups", "add recipient group".
channel
Channel management — messaging integrations overview, health checks, deployments, start/stop services. Reads infra/channels/*.yaml for channel definitions. For scheduled tasks / cron jobs: use the /schedule skill instead. Trigger: "/channel", "channel status", "channel health", "channel deploy", "start channel", "stop channel".
mandants
Mandant management — recipient groups for outbound messages. List, add, show mandants and add persons to groups. Types: company, household, family, friends, colleagues, individual. Trigger: "/mandants", "mandants", "recipients", "recipient groups", "add recipient group".
schedule
Scheduled task management — list, create, deploy, disable scheduled jobs. Manages infra/channels/_scheduled.yaml. Generates platform-native service definitions (launchd/systemd/cron) and deploys to remotes. Trigger: "/schedule", "schedule", "scheduled tasks", "cron job", "schedule deploy", "schedule list".
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.