Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add voxpelli/claude-beads/plugin install vp-beadsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/voxpelli/claude-beads/sibling-sync)<a href="https://agentmods.dev/skills/voxpelli/claude-beads/sibling-sync"><img src="https://agentmods.dev/badge/skills/voxpelli/claude-beads/sibling-sync.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00349 | $0.13468 |
| Opus 5 | $0.00175 | $0.06734 |
| Sonnet 5 | $0.00070 | $0.02694 |
| Haiku 4.5 | $0.00035 | $0.01347 |
Grade A, and why
sibling-sync scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 916 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Sibling Sync
Bilateral reconciliation of SYNERGY-*.md and UPSTREAM-*.md files between
this project and its sibling vp-* projects. Read-only by default — surfaces
drift, reciprocal gaps, stale-aligned rows, and status drift across sides
without mutating anything. The opt-in --auto-reciprocate flag writes
reciprocal entries to the sibling's SYNERGY file via per-entry confirmation.
Companion to /vendor-sync (which handles upstream → project drift); this
skill handles peer-to-peer drift between siblings registered in
.claude/synergy-registry.json.
Design Rationale
The bd v1.0.0 Integration Charter
(gastownhall/beads@5d524cf7:docs/INTEGRATION_CHARTER.md) explicitly punts
cross-tracker orchestration out of bd's scope: bd will never grow a feature
that routes a cross-project item from project A's tracker to project B's
tracker. /sibling-sync is exactly the workflow-automation layer the Charter
defers to external tools — file-based reconciliation between sibling vp-*
projects, mediated by registries and confirmation prompts rather than
synchronous tracker calls.
This mirrors the rationale already cited by /synergy-tracker for keeping
cross-project state in SYNERGY-*.md plus Basic Memory rather than in bd.
Cross-skill boundaries
/sibling-sync is a comparison and reconciliation layer that sits alongside
the per-side logging skills. It owns nothing in Basic Memory and nothing on
this project's side of the SYNERGY/UPSTREAM files.
- Does NOT write SYNERGY entries on this project's side.
/synergy-trackerworkflow 1 (Log a synergy entry) owns logging on this side. - Does NOT pull upstream subtrees.
/vendor-syncowns subtree pulls and the upstream → project drift workflow. - Does NOT write Basic Memory notes.
/synergy-trackerworkflow 5 (Promote to Basic Memory) owns## Cross-Project Synergywrites to sibling entity notes;/upstream-trackerworkflow 6 (Promote to Basic Memory) owns## Upstream Frictionwrites. Basic Memory write tools are intentionally absent from this skill'sallowed-tools. - Does NOT write
## Trend Reviewsentries to SYNERGY files. Those belong to/synergy-trackerworkflow 4 (Trend review (quarterly)). Even under--auto-reciprocate, /sibling-sync only mirrors content entries into reciprocal sections — never trend-review summaries. - Stale-row detection is INLINE here for the threshold values used during
comparison runs. The canonical staleness-threshold definition lives in
/synergy-trackerworkflow 4 (Trend review (quarterly)) — workflow 2 (Sync sibling SYNERGY) below cites it. Per RETRO-10 YAGNI guard: extract this to a shared helper only when a third skill needs the same logic. - Surfacing reciprocal-friction findings is in scope; acting on them is
not. Workflow 3 (Sync sibling UPSTREAM) Mode B (see below) reads the sibling's
UPSTREAM-<this-project>.mdto surface friction the sibling tracks about this project. Filing the resulting work as bugs/features/opportunities on this side is/upstream-trackerworkflow 1 (Log a new entry)'s job. Annotating the sibling's entry as resolved is/upstream-trackerworkflow 3 (Resolve an entry)'s job, performed on the sibling's side. /sibling-sync reports only. - Orchestrator role for follow-up actions (v0.14.0). Workflows 2 (Sync
sibling SYNERGY) and 3 (Sync sibling UPSTREAM) end with a per-sibling
action menu (see "Action-menu protocol" below) that delegates writes to
the owning skill (
/vp-beads:synergy-tracker,/vp-beads:upstream-tracker) via theSkilltool, or runsbd createdirectly for beads issues. /sibling-sync still owns nothing in Basic Memory and nothing in this project's SYNERGY/UPSTREAM files — ownership boundaries are unchanged.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 916 lines · 349 tokens per session scan A e4f2bb8f943b
sibling-sync is a skill published in the GitHub repository voxpelli/claude-beads (2 stars, last pushed 24d ago), licensed MIT. It adds 349 tokens to every session and 13,468 once invoked, about $0.0017 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
schema-evolve
This skill should be used when the user asks about 'schema drift', 'schema evolution', 'evolve schema', 'schema sync', 'sync schemas', 'update schema fields', 'schema field frequency', 'missing schema fields', 'unused schema fields', 'schema proposal', 'schema cardinality', 'check schema', 'schema audit', 'schema…
knowledge-maintain
This skill should be used when the user asks to fix, repair, or tidy one or more SPECIFIC named notes — 'fix these notes', 'fix the issues in [note]', 'add the missing relations to [note]', 'tidy up [note]', 'fix orphan [note]', 'apply the gardener findings for [note]'. Applies structural fixes (missing sections…
raindrop-triage
This skill should be used when the user asks to 'triage unsorted bookmarks', 'clean up raindrop inbox', 'sort unsorted', 'organize bookmarks', 'raindrop triage', 'process bookmark backlog', 'promote triaged bookmarks', 'classify triaged', 'raindrop cleanup', 'deduplicate bookmarks', 'find duplicate bookmarks', 'tag…
knowledge-garden
This skill should be used when the user asks to audit, health-check, or structurally validate one or more SPECIFIC named notes or a bounded topic cluster — 'audit these notes', 'check this note for orphans or broken links', 'fourth-wall check on [note]', 'validate the structure of [note]', 'spot-check [note]'. Runs a…
knowledge-prime
This skill should be used when the user asks to 'prime context', 'load project knowledge', 'what do we know about this project', 'knowledge brief', 'project context', 'what packages are documented', 'show coverage for this project', 'dependency coverage report', 'which of our deps have notes', 'knowledge primer'…
nudge
This skill (explicit /nudge only) manages Claude Code feature-adoption nudges sourced from the Basic Memory note main/reference/claude-code-noteworthy-features. Bare /nudge = Mode A (sync): re-read the note, filter out features already marked adopted or declined, and regenerate the tip cache…