construct-bridge-detect

Run bridge detection during a curation cycle or by asking for cross-domain patterns. The Skill scans connections.json for structural bridges, checks shared content_categories across domains, and reads card content for linked domains before proposing candidates.

Level 1 finds structural bridges where cards connect across domains in connections.json. Level 2 detects category overlap where the same content_categories appear in multiple domains. Level 3 reads card content for domains with cross_domain_links to assess genuine parallels.

Candidates are written to log/bridge-candidates.json in the workspace as a derived, regenerable artifact. The file is written on every run, even with an empty candidates array, and confirmed bridges are stored canonically in connections.json.

No. The Skill only proposes candidates and asks for confirmation before adding edges to connections.json. Confirmed bridges are logged as detect_bridge events, and an optional connection-type card can document the parallel.

Structural and category-based signals can produce superficial keyword coincidences, so each candidate requires content-level assessment for genuine parallel, strength, and novelty. Only cross-domain candidates are kept, and already-confirmed bridges are excluded.