Synced from
references/brand-bridge.mdincontent-extractionskill on 2026-05-18. Edit upstream in the skill; this file is overwritten on next sync.
Brand Bridge — How the Skill Reads _brand/ at Runtime
The skill’s intelligence (extraction logic, scripts, schema) lives in onari-intelligence. The brand-side knowledge (pillars, voice rules, campaign state) lives in afriend-business. The two are bridged at runtime, not duplicated.
This file explains how the bridge works, why it exists, and what to do when sources shift.
Why this split
Daniel’s intent (from the planning conversation):
“Ich möchte schon so intelligence-artige Sachen für die by the Onari Intelligence lassen, aber natürlich brandseitige Abbildungen sind wichtig vom Business.”
Translation in operational terms:
- Onari Intelligence is the system layer — orchestration, transcription routing, ffmpeg pipeline, JSON schemas, generic short-form virality canon. Things that aren’t specific to A Friend.
- afriend-business is the brand workspace — the pillars, voice rules, campaign state, the visual system, the Indiegogo narrative. Things that ARE A Friend.
Putting both in one place would either pollute Onari with brand-specific logic (which doesn’t generalize to other future brands the user might bridge in), or pollute afriend-business with generic short-form intelligence (which doesn’t belong to A Friend).
The bridge keeps each side honest about what it owns.
What lives where
| Location | What’s there | Refresh cadence |
|---|---|---|
~/Projects/onari-intelligence/.claude/skills/afriend-content-extraction/ | Skill orchestrator, scripts, generic short-form virality canon, JSON schema | Slow — changes when the skill itself evolves |
~/Projects/afriend-business/content-extraction/_brand/ | Brand pillars, voice rules, campaign state | Fast — refreshes when HANDOFF.md or design system shifts |
~/Projects/afriend-business/content-extraction/sessions/ | Per-recording outputs (transcripts, cut plans, clips) | Per session |
Read order at runtime
When the skill is invoked, read in this order:
SKILL.md(you, the orchestrator) — modes, pipeline, hard rules.references/shortform-virality.md— generic short-form intelligence (hook archetypes, retention mechanics, scoring rubric).afriend-business/content-extraction/_brand/pillars.md— A Friend brand pillars + trigger/anti-trigger patterns.afriend-business/content-extraction/_brand/voice-preservation.md— Daniel-voice rules, banned vocab, code-switching, two-beat cadence.afriend-business/content-extraction/_brand/campaign-state.md— what’s live in the campaign right now.references/editor-export-formats.md— only when generating exports.
Steps 3–5 are always read together. They form the brand-side lens through which transcript segments are scored.
Path resolution
Hardcoded absolute paths in SKILL.md and the scripts. The skill is bound to one user’s machine layout (Daniel’s). If the bridge needs to support multiple machines (iMac vs MacBook), env vars override:
export AFE_BRAND_PACK_DIR="$HOME/Projects/afriend-business/content-extraction/_brand"
export AFE_SESSION_DIR_ROOT="$HOME/Projects/afriend-business/content-extraction/sessions"If AFE_BRAND_PACK_DIR is set, scripts and SKILL.md instructions resolve _brand/* against it instead of the default ~/Projects/afriend-business/content-extraction/_brand/.
(For the initial version, the defaults are sufficient — Daniel’s machines have the same ~/Projects/ layout via the dev-sync workflow.)
When source files change
refresh_brand_pack.py does not auto-overwrite the brand pack. It checks whether sources have changed since the last manifest snapshot and reports drift. The reason: the brand pack contains synthesized judgement (e.g., “this is the dominant pillar for §04”), not just a literal extract from the sources. Auto-overwriting would lose that judgement.
The intended flow:
- Source file changes (e.g., Daniel updates
HANDOFF.mdbecause the campaign timeline shifted). - Next time the skill is invoked,
refresh_brand_pack.pyreports drift oncampaign-state.md. - Skill surfaces this to Daniel: “Brand pack drift detected — campaign-state.md may be stale because HANDOFF.md changed.”
- Daniel decides: edit
_brand/campaign-state.mdmanually to reflect the shift, then runrefresh_brand_pack.py --snapshotto mark the new state baseline. OR he says “skip, run with snapshot” and the skill proceeds, noting in the cut plan that the brand pack was stale.
This keeps the brand pack auditable — every refresh is a deliberate decision, logged via the manifest.
When the skill itself changes
If the skill’s references/shortform-virality.md is updated (e.g., new hook archetype research lands), no brand-pack refresh is needed — the brand pack is unaffected. Likewise, brand-pack changes don’t require skill changes.
The two sides are decoupled by design.
Cross-machine sync
Daniel runs across iMac (workstation) and MacBook (mobile). Both repos are sync’d via Syncthing per the dev-sync workflow:
~/Projects/onari-intelligence/(the skill itself)~/Projects/afriend-business/(the brand sources + _brand/ pack + sessions)
Sessions in afriend-business/content-extraction/sessions/ will sync — meaning a recording started on the iMac can be transcribed on the MacBook (or vice versa). The skill is identical on both machines because it’s checked into the onari-intelligence repo.
If Syncthing conflicts on a session folder (rare but possible), Daniel’s call which side to keep — there’s no automatic merge for cut plans.
What this brand bridge is NOT
- Not a programmatic API. The skill reads
_brand/*.mdas plain markdown. There’s no schema or query layer. If a future iteration needs structured data, that’s a separate refactor. - Not the only way to read brand state. Daniel can edit the brand pack directly if he disagrees with what the skill is doing. The skill respects whatever’s in
_brand/at the time of invocation. - Not auto-managed. No daemon watches HANDOFF.md and rebuilds the brand pack. The refresh is explicit, surfaced as drift, decided by Daniel.
The bridge is intentionally simple — just two folders that know how to talk to each other through a manifest.