Git Sync Daemon

Manage multiple git repositories with a daemon model (periodic add/commit/pull/push). Use this skill when you need to set up, run, or troubleshoot automated...

Security Scan

The skill mostly does what it claims (auto-sync git repos) but has several implementation and configuration inconsistencies that could lead to privilege or operational surprises; review before installing, especially the systemd behavior and dependency assumptions.

Purpose & Capability

Name/description match the delivered scripts: they implement a daemon that periodically add/commit/pull/push repos. However the package does not declare required external binaries (git, systemctl/launchctl/plutil, shasum/sha1, timeout/gtimeout) even though the scripts rely on them. That omission is disproportionate to the stated purpose and may cause silent failures.

Instruction Scope

SKILL.md and the scripts are explicit about reading a per-user repo config and operating on the listed repo paths. The daemon will run git in each repo, automatically add/commit local changes and push/pull — which is within the stated purpose but is a high-impact action (it will create commits and push to remotes using whatever credentials the service user has). The SKILL.md also instructs creating system services (launchd/systemd) and modifying user system directories; nothing in the instructions reads or transmits unrelated secrets, but the runtime relies on the user's existing SSH/git credentials.

Install Mechanism

There is no external install/download; this is instruction-only with included scripts. No network fetch or archive extraction is performed by the skill itself.

Credentials

The skill declares no required environment variables or credentials, yet it depends on the service user's git credentials/SSH keys/credential helpers to push/pull. That is reasonable for a git daemon, but the package doesn't document the dependency on those credentials explicitly. Additional env/binary fallbacks (GIT_SYNC_* variables, timeout, shasum) exist, so misconfiguration could cause the service to run unexpectedly under different identity contexts.

Persistence & Privilege

Installing systemd requires root (the script enforces this). The unit file created sets User=$(id -un) computed during install; because install-systemd is invoked with root (sudo), that expands to 'root' and the service will run as root by default — which contradicts the SKILL.md advice to install the service as the same user that owns repo credentials. Running the daemon as root increases blast radius if misconfigured. The skill is not always:true, and autonomous invocation is allowed (default) but not itself flagged.

What to consider before installing

This skill appears to implement a useful git auto-sync daemon, but review before installing: - Dependencies: ensure git is available and that timeout/gtimeout, shasum (or equivalent), and platform tools (systemctl on Linux, launchctl/plutil on macOS) are present. The package does not declare these. - Credentials: the daemon will use the service user's SSH keys / credential helper to push/pull. Confirm the user you run the service as has only the intended repo access. The daemon will auto-add/commit local changes and push them to remotes. - systemd install behavior: install-systemd requires root and, as written, will create a unit that runs as the installing user; if you run install via sudo, that User will be 'root' and the daemon will run as root. If you intend the service to run as a non-root account, either run the install as that account using a non-root installation approach or edit the generated unit to set the correct User explicitly before enabling it. - Test first: run cmd_run_once and validate behavior and logs before enabling persistent service. Inspect repos.conf and only register repositories you trust. Consider log rotation and limit access to the log/state directory. If you are not comfortable editing the systemd unit or ensuring the correct service user/credentials, do not enable the persistent service; run the script in manual/once mode instead.

Purpose

Provide a reusable, daemon-based git auto-sync workflow:

• one repo list file
• one daemon process
• per-repo lock and independent failure isolation
• service management on macOS and Linux

Files

• Engine: scripts/git_sync_daemon.sh
• Control CLI: scripts/git_sync_ctl.sh

Default Runtime Paths

• State dir: ~/.config/git-sync-daemon
• Repo list: ~/.config/git-sync-daemon/repos.conf
• Log file: ~/.config/git-sync-daemon/git-sync-daemon.log

Repo Entry Format

One line per repo:

/absolute/path/to/repo|remote=origin|branch=main|enabled=1

Supported keys:

• remote (default origin)
• branch (default current branch)
• enabled (1/0, true/false, default enabled)

Quick Start (macOS)

bash scripts/git_sync_ctl.sh init
bash scripts/git_sync_ctl.sh add-repo /Users/samwei12/Develop/config
bash scripts/git_sync_ctl.sh run-once
bash scripts/git_sync_ctl.sh install-launchd
bash scripts/git_sync_ctl.sh status

Quick Start (Linux)

bash scripts/git_sync_ctl.sh init
bash scripts/git_sync_ctl.sh add-repo /path/to/repo
bash scripts/git_sync_ctl.sh run-once
sudo bash scripts/git_sync_ctl.sh install-systemd
bash scripts/git_sync_ctl.sh status

Operations

• Add repo: bash scripts/git_sync_ctl.sh add-repo <path> [branch] [remote]
• Remove repo: bash scripts/git_sync_ctl.sh remove-repo <path>
• List repos: bash scripts/git_sync_ctl.sh list-repos
• One cycle now: bash scripts/git_sync_ctl.sh run-once
• Status/log tail: bash scripts/git_sync_ctl.sh status

Service lifecycle:

• macOS install: bash scripts/git_sync_ctl.sh install-launchd
• macOS uninstall: bash scripts/git_sync_ctl.sh uninstall-launchd
• Linux install: sudo bash scripts/git_sync_ctl.sh install-systemd
• Linux uninstall: sudo bash scripts/git_sync_ctl.sh uninstall-systemd

Production hardening checklist

Before enabling daemon mode in production:

1. SSH/auth baseline

• Ensure service user can run non-interactive git over SSH to each remote.
• Preload host keys (ssh-keyscan / StrictHostKeyChecking=accept-new) to avoid first-run failures.
• Prefer explicit key routing in ~/.ssh/config (host/user/port/IdentityFile/IdentitiesOnly).

2. Service identity consistency

• Install service with the same user that owns repo credentials and git config.
• Verify git config --global user.name/user.email for that service user.

3. Repo registration policy

• Register only clean, intended repos.
• Keep one canonical branch per repo entry; avoid detached HEAD targets.
• Use enabled=0 for temporary pauses instead of deleting lines.

4. Observability

• Keep logs in dedicated file and rotate externally if needed.
• Validate run-once before enabling persistent service.

Safety Notes

• The daemon does not force-push.
• Rebase conflicts are logged and isolated to the affected repo.
• If git-lfs is required by hooks but missing, that repo is skipped with explicit error log.
• On macOS launchd, PATH is expanded in both service env and daemon script to include Homebrew binaries.
• Recommended migration practice: first successful run should use baseline repos only; then gradually add more repos.