The file-sync-config Skill — Pre-Flight Checklist for Two-Way Sync

Two-way file sync across multiple machines looks straightforward until it runs into a nested git repository, a Python virtual environment built for the wrong architecture, or a local SQLite database that has no business being on another host. The file-sync-config skill provides a mandatory pre-flight checklist for any two-way sync setup before the first byte moves.

The skill applies to Syncthing folder setup, rclone bisync, Dropbox and iCloud shared folders, periodic rsync jobs, and any custom sync layer. It explicitly does not apply to one-way backup or CI artifact transfer, where the risk model differs.

The founding incident

The skill exists because of a concrete failure. An initial .stignore for Syncthing had 28 patterns and did not cover .venv, __pycache__, target/, *.db, and did not exclude nested git repositories. The result over one week: one materialised sync conflict in a production CLAUDE.md file, 60+ conflict files accumulated in the vault, 14 git repositories with different checked-out branches synced as plain working trees, and cross-platform binary risk from Python virtual environments built for macOS being copied to a Linux host. After expanding the pattern list from 28 to 66 entries, the synced file count dropped from 40,361 to 2,206 — a 95% reduction.

The pre-flight inventory

Before turning sync on, the skill requires running find against five classes of problematic files on the source host: build artifacts and dependency directories (node_modules, .venv, target, .next, and others), nested git repositories, local database files (*.db, *.sqlite), compiled binaries (*.so, *.dylib, *.dll), and IDE and OS junk. Every class the inventory surfaces must be in the ignore patterns before the first sync run.

The decision tree for git repos

For every .git/ directory inside the sync root, the skill asks one question: does the second node have live edits, agents, or a production runtime in this repository? If yes, the entire repository path is excluded from sync, and the second node gets updates through a git pull cron instead. If no, the working tree can be synced, but the .git/ directory itself is still excluded so each node keeps its own commit history.

The default is to treat the answer as yes. Almost any second node eventually becomes active — a new agent appears, a deploy script lands, someone makes a manual edit. Over-protection costs less than recovery.

The compliance checklist

The skill includes a nine-point compliance checklist for infrastructure tasks: pre-flight inventory completed; all surfaced classes in ignore patterns; every nested git directory either excluded or documented as a read-only mirror; cross-platform binaries excluded when the sync spans different operating systems; database files excluded; lockdown settings applied; a configuration backup stored; a runbook documented; and a smoke test run in both directions.

The skill also provides a reusable .stignore template for Syncthing, a pattern syntax cheat-sheet covering Syncthing, rclone, and rsync syntax differences, and a workflow for updating git-excluded repositories on the second node using a cron pull script or a CI/CD self-hosted runner.

Read more about the Datarim pipeline in what Datarim is, or see how the finishing-a-development-branch skill handles the end of a development cycle.