Adapting it to your machine

Adapting it to your machine

The skills and engines in this box were written inside a running system with different paths, different machine names and different accounts. Copying them is step one; adapting them is the actual work. Keep the method, replace the bindings.

The one thing to understand first

The engines are samples, not a working install.

All 246 files parse under Python 3.12. That is the only guarantee — parsing is not running. None of them will do anything useful until you point them at your own vault, your own accounts and your own keys. Every file carries a banner saying so.

Placeholders you will hit

Placeholder	Replace with
%VAULT%	your Obsidian vault root
%VAULT_ROOT%	the folder the vault sits in
%IMPORTS%	where you keep the engines' data
%USERPROFILE%	your home directory (Windows)
%WORKDIR%	your working folder
$HOME	your home directory (macOS/Linux)

Build every path from the home directory. Hard-coded drive letters are the fastest way to make the kit unportable — and the failure is silent: a script that writes to a drive that does not exist here can exit cleanly and produce nothing.

Two conventions that will confuse you before they help

• Machine names differ between docs and code. The skills say HUB-1, LAPTOP-1, ANCHOR-1; the Python says HUB1, LAPTOP1, ANCHOR1. Not sloppiness — a hostname in Python is also an identifier, and ANCHOR-1 = ... does not parse.
• Paths to secrets/*.env are left in on purpose. They tell you where your own credentials go. No credential values are in this repository, and none should ever be.

Adapting a skill, concretely

Go through each SKILL.md you install and fix three classes of thing:

1. Paths — %VAULT_ROOT%\..., C:\Users\..., $OBSIDIAN_VAULT → your vault.
2. Missing engines — a skill may call something that is not in the box (18 cited engines are named as unpublished in HANDOVER.md §2а). Three honest options: build a simple local replacement (grep or a stdlib script), degrade the skill to manual mode, or park it and tell the user what is missing. Never leave a broken reference silently.
3. People, channels and machines from the original system → yours, or deleted.

Reading path through the engines

engines/PASSPORTS.md has one entry per engine: inputs, outputs, dependencies, and which skills call it. For 61 of the 246 it also carries the hand-written half — what breaks, how to tell, how to fix — written for someone who did not build it. The other 185 say so plainly rather than filling the space with something that sounds like guidance and isn't; read the source before relying on those.

If you want a short path in, the most-cited engines are a reasonable order:

Engine	Does
imports/vault_backup.py	back up the vault before anything modifies it
imports/brain_embed_update.py	rebuild the embedding index over the vault
imports/brain_ask.py	semantic retrieval — the engine behind /ask
imports/archive_original.py	keep the raw original of anything imported
imports/namesearch/find_name.py	find a person across spellings and keyboard layouts
scripts/approval.py	ask the human a question and wait for a yes

vault_backup.py first is not an accident: back up before the first thing that writes.

A sane order of operations

1. Vault and templates — somewhere for output to land.
2. CLAUDE.md — the rules that load every session.
3. Five skills, adapted and actually tried (see First week).
4. Engines, only the ones those five skills need.
5. Everything else, when a real need shows up rather than because it is in the box.

Installing all 101 skills and 246 engines on day one produces a system nobody has verified. Adopt what you can check.