Snow LeeandClaude Fable 5
644caff70e
Field report follow-up: an agent with a stale skill copy couldn't find the gated URL after creating a file. Instructions rot; hook output is computed fresh from the binary every turn. Claude Code's turn-start pull hook now runs 'bdrive sync --hook claude-code', which: - pulls as before, and stamps the session note from the event JSON (replacing the sh/sed pipeline for the pull leg) - emits the project's gated-link formula as UserPromptSubmit additionalContext: whenever the agent mentions a synced file path in prose, it appends the hub link on an emoji — `<path>` [🔗](<url>) — path plain (it's the local path), hyperlink on the emoji only; code blocks stay plain; bdrive share stays explicit-opt-in-public Blind-tested: an agent given only the injected context decorated every path mention correctly, kept the code-block command plain, and checked files were synced before linking. - hooks install now CONVERGES marker-identified groups to the current shape (command/matcher/flags), so improvements reach existing projects on reinstall instead of being frozen by the idempotency marker; hermes same - plugin: UserPromptSubmit → beardrive-pull.sh (stdout passes through); version 0.3.0 - SKILL 'Share what you make' generalized to 'Link what you mention' (URL formula documented for non-Claude platforms); install.md pointer template updated Never fails the turn: every error path in --hook mode is a silent successful exit; offline still emits (links serve online teammates). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P5cxPQdSGJnjXCYY9GeWXt
6.4 KiB
description, argument-hint
| description | argument-hint |
|---|---|
| Set up BearDrive for this project — install the CLI, sign in, create/connect a project, optionally document the shared folder in CLAUDE.md, and register project-level sync hooks so every teammate's files stay fresh during Claude sessions | [project-name] [--shared <dir>] |
Set up BearDrive for the current project, end to end. Work through these steps in order, telling the user what you're doing at each one.
1. Ensure the bdrive binary exists
Run command -v bdrive. If missing, install it:
- macOS/Linuxbrew:
brew install runbear-io/tap/beardrive - otherwise:
go install github.com/runbear-io/beardrive/cmd/bdrive@latestIf neither works, stop and tell the user how to install manually.
2. Sign in if needed
Run bdrive login --status. If there is no valid session, sign in against
the team's hub: ask the user for their hub URL and run
bdrive login https://their-hub — it opens the browser to sign in (or
sign up) and completes by itself. (Bare bdrive login targets BearDrive
Cloud, which is not open yet — don't use it unless the user says their
team is on the cloud beta.) Tell the user a browser window is coming
before you run it.
3. Initialize the project
If $ARGUMENTS gives a project name and/or --shared <dir>, use them.
Otherwise ask the user two questions (or infer from their request):
- Create a new project or connect an existing one? (
bdrive share --listisn't needed here —bdrive init --name <name>creates-or-joins by name;bdrive init --project <p-id>connects by id.) - Sync the whole folder, or only a shared subfolder (e.g.
./wikior./shared)? Hard rule: never sync a repo root — inside a repo, knowledge always syncs as a scoped subfolder via--shared. Whole-folder is only for a dedicated knowledge folder (an empty dir, a standalone vault) that is the mount itself.
Then run it non-interactively, e.g.:
bdrive init --name <project-name> --yes # dedicated knowledge folder
bdrive init --name <project-name> --shared wiki # in a repo: only ./wiki syncs
Re-running bdrive init --yes later is always safe: it resumes syncing
(including after the folder was renamed or moved).
4. Teach agents about the shared folder (ask first — never do this silently)
Two files with different jobs (full rationale: the beardrive skill's "Teaching agents the folder" section). Offer each as its own consent:
a. The folder's own map — <shared>/AGENTS.md (synced, team-wide).
If the shared folder already has an AGENTS.md, read it and follow it —
it is the team's source of truth; do not rewrite it while onboarding.
If it has none and this user is creating the project, offer to draft one:
explore the folder (top-level dirs, naming patterns, what's actually
there) and write a short map — what each area is for, naming conventions,
where agents should put their output, what not to touch. Keep it under a
screen; it syncs to every member, so write it for the whole team, not
this machine.
b. A root pointer in this repo (per machine, never synced). For a
--shared mount inside a repo, append a short section to the repo root's
AGENTS.md and/or CLAUDE.md — both if both exist; AGENTS.md is what
Codex and Hermes read (Codex never discovers nested instruction files,
and no platform knows the folder matters until told). Shape it like
this (adapt the folder name; create the file if missing):
## Shared folder (BearDrive)
`wiki/` is the team's shared folder, synced via BearDrive — changes
propagate to everyone within seconds and every change is tracked (who,
when, which device). Read `wiki/AGENTS.md` before working there. Put
shareable artifacts — reports, notes, plans — in `wiki/` so the team
sees them, and whenever you mention a synced file's path, append its
gated link on an emoji: `` `wiki/<file>` `` [🔗](\<hub link>) —
`bdrive url wiki/<file>` prints the link (teammates sign in to view).
Never put secrets here (`bdrive share` mints fully public URLs).
Point at the synced AGENTS.md rather than duplicating its conventions —
the pointer is for awareness and routing; the conventions live in the
folder, stay current for everyone, and are versioned by the hub. For a
standalone knowledge mount (dedicated folder, no enclosing repo) skip the
pointer: AGENTS.md at the mount root is loaded natively by every
platform.
5. Register agent sync hooks
Run bdrive hooks install in the project. It detects the agent platforms
in use — Claude Code (.claude/), Codex (.codex/), Gemini CLI
(.gemini/), Hermes (~/.hermes/) — and idempotently merges beardrive's
sync hooks into each platform's own hook config, preserving any hooks
already there. Project-level files (.claude/settings.json,
.codex/hooks.json, .gemini/settings.json) ride the repo, so every
teammate gets them — plugin or not, whatever agent they use; Hermes hooks
are per-user (~/.hermes/config.yaml).
The registered hooks pull before every turn (the agent always reads the
team's latest files), push right after edits (artifacts land on the server
seconds after they're created — daemon or no daemon), and stamp every
change with the agent session that made it (bdrive sync --note "<agent> session <id>" — visible in bdrive log and the hub's history views).
A third hook (bdrive read-log) queues which files the agent read — via
the native read tool, grep-style searches (the files the matches came
from), or shell commands that name project files — so the hub's read
heatmap can show admins what the team's agents actually consume. Reads
are reported on the next sync, never from the hook itself. They are fast no-ops in folders without
.bdrive/.
Tell the user which platforms got hooks (bdrive hooks shows the status
table). If Codex is among them, mention they must run /hooks inside
Codex once to trust the project's .codex layer. To register a platform
that wasn't detected: bdrive hooks install --agent claude,codex,gemini,hermes.
6. Verify and summarize
Run bdrive status and confirm the daemon is running and pending is 0.
Then tell the user what was set up, and demonstrate the payoff: if they
have (or you just generated) an HTML/PDF/markdown artifact in the synced
folder, run bdrive url <file> and hand them the teammate link (sign-in
required — safe by default); mention bdrive share <file> exists for
fully public links when someone outside the hub needs it.