back
loading skill details...
Backup and restore Daniel agents with git.
--- name: "dr-agent-backup" description: "Backup and restore Daniel agents with git." --- # DR. Agent Backup Use when setting up, auditing, repairing, or restoring backup continuity for a Daniel-owned agent. Goal: agent memory and workspace state should survive VM loss or migration. Restore should be boring: clone/pull the repo, restore secrets separately, verify the agent starts, and reindex memory if needed. ## Core Policy 1. Back up agent-owned workspace files to a Daniel-owned Azure DevOps git repository. 2. Commit after meaningful memory or workspace changes. 3. Never commit secrets, tokens, local credential stores, runtime logs, caches, databases, or bulky generated state unless explicitly approved. 4. Treat git as continuity for human-readable source of truth, not a full machine image. 5. Secrets and auth must be restored through the proper secret manager, env file, or provider login flow. ## What To Track Default include list: - `AGENTS.md` - `SOUL.md` - `USER.md` - `TOOLS.md` - `MEMORY.md` - `HEARTBEAT.md` when present - `memory/**/*.md` - `memory/**/*.json` only when it is intentional durable state - `context_pipeline/**` - `automation/**` excluding runtime outputs and secrets - `skills/**` for workspace-local skills - `doc_reviews/**` when used as active review state - Project notes and templates Daniel expects to restore Default exclude list: - API keys, tokens, passwords, OAuth files, cookies, auth profiles - `.env`, `*.env`, `gateway.systemd.env`, and backups of env files - SQLite databases and WAL/SHM files unless explicitly approved - `node_modules/`, package caches, build outputs - raw session transcripts unless Daniel explicitly wants them tracked - inbound/outbound media files unless intentionally curated - temporary files, logs, downloads, generated archives ## Setup Workflow 1. Confirm the Azure DevOps organization, project, and repo name. 2. Confirm credential method: - SSH deploy key - Azure DevOps PAT stored outside git - existing authenticated git credential helper 3. Initialize or connect the workspace repo. 4. Add a `.gitignore` that blocks secrets and runtime state. 5. Run a dry-run status review before the first commit. 6. Make the initial commit with a clear message. 7. Push to Azure DevOps. 8. Record the repo URL and restore notes in local memory or an approved ops file. ## Commit Policy Commit after meaningful changes to: - long-term memory - daily memory logs that contain decisions or restore-relevant facts - agent instructions or identity files - automation manifests and scripts - local skills or proposal-derived workflow files - context pipeline files - important operational notes Do not commit after every tiny transient log line if it adds noise. Batch related memory edits when they happen in one task. Recommended commit message style: ```text memory: capture gateway restore and embedding fix agent: update baseline behavior notes backup: add Azure DevOps restore procedure skill: revise agent baseline proposal ``` ## Before Commit Checklist Run these checks before committing: 1. `git status --short` 2. Inspect changed files. 3. Check that no secret-bearing files are staged. 4. If adding `.gitignore`, confirm it covers known OpenClaw secrets and runtime state. 5. Commit only intentional files. If a secret appears staged, stop and unstage it. Do not rely on later cleanup. ## Restore Workflow 1. Install OpenClaw and baseline system packages. 2. Clone the Azure DevOps repo into the expected workspace path. 3. Restore secret files/env/auth using the approved secret path, not git. 4. Install/enable required plugins and skills. 5. Verify gateway service and lingering if this is a Linux user service. 6. Run memory status and reindex if needed: ```bash openclaw memory status --index openclaw memory index --force ``` 7. Verify channels and delivery targets. 8. Run a small end-to-end DM test. 9. Commit any restore-specific notes that are useful for next time. ## Agent Behavior Agents should run safe git checks and commits themselves when they have access. Ask Daniel before: - creating a new Azure DevOps repo - adding credentials or PATs - pushing to a new remote for the first time - changing access controls - committing files that may contain private/customer data beyond normal memory notes - deleting history or rewriting commits ## Audit Workflow For an existing agent, audit backup health by checking: - Is the workspace a git repo? - Is the remote Azure DevOps and reachable? - Is `.gitignore` strong enough? - Are there uncommitted memory/workspace changes? - When was the last successful push? - Are secrets absent from tracked files? - Is there a documented restore path? Report the result as: - status - risks - next action Keep it short unless Daniel asks for full detail. ## Boundaries This skill does not replace VM snapshots or system-level backups. It protects the agent's durable working memory and configuration source, not every runtime artifact. This skill does not store secrets in git.
don't have the plugin yet? install it then click "run inline in claude" again.
restructured original as 6-component format with explicit inputs, outputs, and decision branches; added network timeout and auth expiry edge cases; documented azure devops as external connection with credential methods; clarified secret restore flow and audit checklist as formal procedures.
use this skill when setting up, auditing, repairing, or restoring backup continuity for a daniel-owned agent. goal: agent memory and workspace state survive vm loss or migration. restore should be boring: clone/pull the repo, restore secrets separately, verify the agent starts, and reindex memory if needed. treat git as continuity for human-readable source of truth, not a full machine image.
azure devops setup:
workspace environment:
external connections:
edge cases to handle:
confirm azure devops credentials and access
git ls-remote <repo-url> before proceedinginitialize or connect workspace repo
git init && git remote add origin <repo-url>git remote -v.git/ directory present, origin remote configuredadd or update .gitignore
.gitignore file at repo rootrun dry-run status review
git status --short to list all changed and untracked filesmake initial commit
git add <intended-files> (or git add . if all reviewed files are safe)git commit -m "init: agent workspace backup" with clear messagepush to azure devops
git push -u origin main (or appropriate branch)record repo url and restore notes
git status --short to see what changedgit commit -m "<category>: <description>" with recommended style (e.g., "memory: capture gateway restore and embedding fix")git status --shortgit diff --cached --name-only and git diff --cached to review all staged contentgit reset HEAD <secret-file> to unstage itinstall openclaw and baseline packages
clone azure devops repo to workspace path
git clone <repo-url> <workspace-path>restore secrets and auth separately
install plugins and skills
verify gateway service
openclaw service status or check systemd service if linux user servicereindex agent memory
openclaw memory status --indexopenclaw memory index --force if reindex neededverify channels and delivery targets
run end-to-end dm test
document restore-specific notes
if workspace is already a git repo:
git remote set-url origin <correct-url>if azure devops pat is used for auth:
if ssh deploy key is used:
ssh-add <key-path>if network timeout occurs during clone or push:
if secret-bearing file is accidentally staged:
git reset HEAD <secret-file> to unstagegit rm --cached <secret-file> if already in historyif .gitignore is insufficient:
git status --short again to verify patterns workif restore finds uncommitted workspace changes:
git status to see what changed since last pushgit stashif memory reindex fails:
openclaw memory status to diagnoseif agent behavior asks to commit files containing private/customer data:
if agent is asked to create new azure devops repo, add credentials, or change access:
after setup:
.git/ directory present in workspace.gitignore file exists and blocks secrets, caches, databases, logsgit remote -v shows origin pointing to azure devops repogit log --oneline -3 and azure devops ui)after each commit:
git log --onelinegit diff --cached)after restore:
audit status report includes:
setup is complete when:
git remote -v shows origin pointing to azure devopsgit log --oneline shows at least one commitgit pull successfully without errorscommits are working when:
git log --oneline shows new commits after each meaningful changegit status shows clean working tree after pushrestore is complete when:
openclaw service status reports runningopenclaw memory status --index completes without errorsaudit is complete when:
git log -p -- ':!node_modules' | grep -i 'api.key\|token\|password' returns empty