dcurlewis/.claude/skills/backup

Backup

Backup all changes to git and push to remote. This command handles both functional changes and content additions with appropriate commit messages.

This command assumes the user's working copy either points to a private remote or has no remote configured. It must not treat the public template repository as the intended destination for live user data.

Process

1. Check git status

   • Run git status --short to see all changes

2. Categorize changes into two buckets:

   Functional Changes (infrastructure/tooling):

   • .claude/skills/ - New or modified slash commands
   • Scripts/ - Automation and sync scripts
   • CLAUDE.md - System instructions
   • Guidelines/ - Process documentation
   • .gitignore - Git configuration
   • *.py, *.sh files in root - Utility scripts
   • Any other code/config files

   Content Additions (day-to-day content):

   • Curated-Context/ - All subdirectories
   • Memory/ - Memory files and updates
   • Any other content files

3. Commit functional changes first (if any)

   • Stage only functional change files: git add [files]
   • Generate detailed commit message describing what was added/changed:
     • List new commands by name
     • Describe script changes
     • Note guideline updates
     • Mention any other infrastructure changes
   • Commit with descriptive message

4. Commit content additions (if any)

   • Stage all remaining files: git add -A
   • Generate lightweight commit message with categories:
     • Count files by category (meetings, docs, memory, etc.)
     • Use format: "Backup: [categories]"
     • Keep it concise (1-3 lines)
   • Commit with summary message

5. Push to remote

   • Check if a remote is configured (git remote get-url origin)
   • If no remote exists: skip the push and inform the user ("No git remote configured. Changes committed locally. See INITIAL_SETUP.md for backup options.")
   • If the configured remote appears to be the public template repository or another public repo intended for sharing code rather than live data, warn the user and do not push automatically
   • If a remote exists: run git push
   • If push fails (e.g. authentication, permissions): report the error clearly but do not treat the commit as failed

6. Report summary

   • Show what was committed (number of commits, files changed)
   • Confirm push was successful
   • Display commit SHAs for reference

Important Notes

• NO confirmation prompts - just execute the backup
• If there are no changes, inform the user and exit
• If only one category of changes exists, only create one commit
• Commit messages should use British English spelling
• If the remote destination looks unsuitable for private working data, prefer a local-only backup and tell the user why