Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Detect and repair drift between an OKF knowledge vault and the code it describes. Use after merging significant changes (schema, interfaces, workflows, agent config), when a staleness review is due, or when the user asks to sync, refresh, or update the knowledge vault.
.claude/skills/bybren-llc-vault-sync/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-16 | ✗→✓ | ▲ Improved | -13% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 12% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 2% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 15% | 0% |
| case-17 | ✗→✓ | ▲ Improved | -3% | 0% |
> 📋 TEMPLATE: This skill uses {{TICKET_PREFIX}} and {{MAIN_BRANCH}} as placeholders, and > assumes a vault created from knowledge-vault/templates/starter-bundle.
Keep an OKF knowledge vault honest as the code evolves. The vault is a map of the system; this skill detects drift between map and territory, regenerates only the affected concepts, and records the sync.
Invoke this skill when:
stale-concepts Base is the queue)| Path | Role | | --- | --- | | <vault>/_meta/vault-config.json | Machine-readable constitution — types, tags, frontmatter contract | | <vault>/_meta/CONVENTIONS.md | The human-readable rules | | <vault>/_meta/manifest.json | ID registry, reverse index, and baseline_sha drift watermark | | <vault>/_meta/templates/ | Per-type skeletons | | <vault>/log.md | Dated changelog | | knowledge-vault/scripts/validate-vault.mjs | The gate |
> Gemini CLI has no native vault tooling. Steps 1, 4 and 5 are shell commands you run > directly; steps 2 and 3 are authoring work.
Read the baseline and diff it to HEAD across the watch-list — the source paths your concepts claim to describe. Configure this list for your project; the example below is illustrative.
bashBASELINE=$(node -e "console.log(require('./<vault>/_meta/manifest.json').baseline_sha)") git diff --name-only "$BASELINE"..HEAD -- \ 'src/**' 'lib/**' 'config/**' '.github/workflows/**' 'docs/**'
A concept is stale if and only if a changed path matches its resource or an entry in its sources. Check the manifest first (it is the reverse index); grep concept frontmatter as backup.
This is file-level truth. Do not substitute a time-based heuristic — "older than N days" flags everything and teaches people to ignore the flag.
Re-enumerate your source globs and diff against the manifest.
the registry before anything links to it.
status: deprecated. Do not delete the file. Inboundlinks must be cleaned first, in a follow-up change; the backlinks pane or the validator's orphan report shows them.
For a handful of concepts, update inline. For larger sets, fan out generation agents batched by area. Every generation prompt must carry exactly four things:
_meta/templates/_meta/CONVENTIONS.md, inlineEvery touched concept gets timestamp: = today and verified_against: = the current short SHA.
Re-derive facts from the source files. Never patch prose without re-reading the code it describes. Editing a concept to match a changed interface without opening the file is how a vault becomes fiction.
bashnode knowledge-vault/scripts/validate-vault.mjs --vault <vault>
Must exit 0. Markdown lint must pass. Neither is optional.
Prepend a dated entry to log.md: what changed, why (ticket), and the source SHA. Then bump baseline_sha and generated in the manifest.
Ship on a {{TICKET_PREFIX}}-XXX-vault-sync-<topic> branch with a docs(vault): … commit to {{MAIN_BRANCH}}. The pull request should name the code changes that triggered the sync.
## Citationsas a suggestion — never invent a link
timestamp and verified_against
textBumping timestamps on a docs-only pass (that is laundering, not verification) Deleting a concept when its source dies (deprecate; clean inbound links first) Regenerating the whole vault on drift (regenerate only what the diff implicates) Patching prose without reading the code (the one habit that makes a vault untrustworthy) Skipping the validator because "it is just docs" (drift is invisible without the gate)
knowledge-vault/docs/GUIDE.md -- the method and why each rule existsknowledge-vault/docs/ADOPTION-PLAYBOOK.md -- running your first buildknowledge-vault/docs/BUILD-PROMPT.md -- the multi-agent build promptsafe-workflow — branch, commit, and PR conventionslinear-sop — recording the sync against a ticketpattern-discovery — find existing concepts before writing new ones| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 4,058 | 7,690 | +90% | 1 | 1 | 0% | 248 | 1,838 | +641% | 0 | 0 | — |
case-02 | fail→fail | 5,499 | 6,923 | +26% | 1 | 1 | 0% | 278 | 1,728 | +522% | 0 | 0 | — |
case-16 | fail→pass | 14,034 | 1,875 | -87% | 1 | 1 | 0% | 1,904 | 1,648 | -13% | 0 | 0 | — |
case-03 | fail→fail | 8,480 | 3,246 | -62% | 1 | 1 | 0% | 276 | 1,745 | +532% | 0 | 0 | — |
case-04 | fail→fail | 4,824 | 7,680 | +59% | 1 | 1 | 0% | 546 | 2,730 | +400% | 0 | 0 | — |
case-05 | fail→fail | 7,673 | 13,243 | +73% | 1 | 1 | 0% | 1,210 | 2,843 | +135% | 0 | 0 | — |
case-06 | fail→fail | 7,019 | 3,399 | -52% | 1 | 1 | 0% | 366 | 1,737 | +375% | 0 | 0 | — |
case-07 | fail→pass | 19,766 | 12,878 | -35% | 1 | 1 | 0% | 3,237 | 3,611 | +12% | 0 | 0 | — |
case-08 | pass→pass | 13,160 | 5,591 | -58% | 1 | 1 | 0% | 1,996 | 2,286 | +15% | 0 | 0 | — |
case-09 | pass→pass | 9,817 | 6,277 | -36% | 1 | 1 | 0% | 1,553 | 2,485 | +60% | 0 | 0 | — |
case-10 | pass→pass | 12,621 | 5,813 | -54% | 1 | 1 | 0% | 1,791 | 2,355 | +31% | 0 | 0 | — |
case-11 | fail→pass | 14,099 | 4,686 | -67% | 1 | 1 | 0% | 2,130 | 2,171 | +2% | 0 | 0 | — |
case-12 | fail→pass | 12,032 | 2,936 | -76% | 1 | 1 | 0% | 1,608 | 1,853 | +15% | 0 | 0 | — |
case-13 | pass→pass | 9,190 | 4,708 | -49% | 1 | 1 | 0% | 1,344 | 2,186 | +63% | 0 | 0 | — |
case-14 | pass→pass | 11,881 | 4,427 | -63% | 1 | 1 | 0% | 1,781 | 2,093 | +18% | 0 | 0 | — |
case-15 | pass→pass | 10,581 | 7,121 | -33% | 1 | 1 | 0% | 1,837 | 2,542 | +38% | 0 | 0 | — |
case-17 | fail→pass | 26,865 | 2,249 | -92% | 1 | 1 | 0% | 1,698 | 1,652 | -3% | 0 | 0 | — |
case-18 | fail→pass | 11,921 | 2,176 | -82% | 1 | 1 | 0% | 1,783 | 1,687 | -5% | 0 | 0 | — |
case-19 | pass→pass | 12,303 | 5,328 | -57% | 1 | 1 | 0% | 2,007 | 2,248 | +12% | 0 | 0 | — |
case-20 | fail→pass | 11,488 | 3,569 | -69% | 1 | 1 | 0% | 1,758 | 1,923 | +9% | 0 | 0 | — |
case-21 | pass→pass | 10,192 | 2,978 | -71% | 1 | 1 | 0% | 1,422 | 1,777 | +25% | 0 | 0 | — |
case-22 | pass→fail | 13,073 | 3,879 | -70% | 1 | 1 | 0% | 1,871 | 1,947 | +4% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 17 counted toward the lift figure. The other 5 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +27 percentage points is the difference between those two pass rates over the 17 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.