OpenClaw Git Backup

---

name: openclaw-git-backup

description: Create, update, validate, or troubleshoot automated git backup workflows for OpenClaw repositories. Use when a user wants a scheduled commit-and-push backup job, wants commit messages to summarize added or modified or deleted files, needs git credential setup for HTTPS pushes, or needs to debug why an OpenClaw cron backup is not running or not pushing.

---

# OpenClaw Git Backup

Use this skill to build a reusable nightly git backup workflow for an OpenClaw repo.

What this workflow does:

Inputs to Confirm

Before changing anything, confirm these values:

If the user already implied these values, proceed without turning it into an interview.

Defaults

Reasonable defaults for a fresh setup:

Bundled Script

This skill includes `scripts/nightly_git_backup.sh`.

Prefer using the bundled script as the implementation source, then copy it into the runtime location the user wants the cron job to call.

Typical install step:

install -D -m 755 <skill-dir>/scripts/nightly_git_backup.sh <runtime-script>
bash -n <runtime-script>

Configuration Model

The bundled script supports these env vars:

The first positional argument is the repo path. If omitted, the script uses `BACKUP_REPO` or the current directory.

Recommended Flow

1. Inspect current state

Check:

2. Install or update the runtime script

Copy the bundled script into the runtime path the cron job will execute.

3. Configure push auth only if needed

If HTTPS push is already working, leave auth alone.

If the user explicitly provides a GitHub HTTPS token, prefer repo-local credential storage instead of embedding credentials in the remote URL:

git -C <repo-root> config credential.helper 'store --file=<repo-root>/.git/credentials'
git -C <repo-root> config credential.useHttpPath true
printf 'protocol=https\nhost=github.com\npath=OWNER/REPO.git\nusername=x-access-token\npassword=TOKEN\n' | git -C <repo-root> credential approve
chmod 600 <repo-root>/.git/credentials
git -C <repo-root> ls-remote --heads <remote> <branch>

Rules:

4. Create or update the cron job

Read `references/cron-job-template.md`.

Set the job so it executes:

bash -lc '<runtime-script> <repo-root>'

Typical cron settings:

5. Force-run once immediately

Do not stop at “job created”. Always test the full path.

After force-run, check:

Validation Checklist

Script

Git

Cron

Expected Outcome

Commit Message Contract

The bundled script writes:

Subject

backup: snapshot YYYY-MM-DD HH:MM:SS +0000 | +A ~M -D

Body

Added(n)
- ...

Modified(n)
- ...

Deleted(n)
- ...

Renamed(n)
- old -> new

Keep the body factual and file-oriented.

Common Pitfalls

Scheduler self-noise

Some repos contain scheduler state that changes every run. Exclude it explicitly with `BACKUP_EXCLUDES`.

Example:

BACKUP_EXCLUDES='cron,cron/**'

Runtime state outside the repo

Git only backs up files inside the target repo. If a workflow also depends on directories outside the repo, they are not covered unless the user explicitly adds a second sync or mirrors them into the repo.

See `references/backup-scope.md`.

Wrong success criteria

“Cron job exists” is not enough.

The real success condition is:

1. force-run works

2. commit format is correct

3. push succeeds

4. remote catches up

Output Style

When reporting back, keep it concrete: