agentsclimarketplace

Github auto backup

Skill OlivierHijlk1/github-auto-backup

A Claude Code skill that manages Git/GitHub for every project: interviews you for new repos, then autonomously commits, pushes, pulls and branches with conventional commits. Supports local-only mode.

Install
npx -y skills add OlivierHijlk1/github-auto-backup

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use whenever creating a new coding project or working in any git-backed project. Handles all Git/GitHub management so the user always has an off-machine backup. Interviews the user before creating a new repo, then autonomously commits, pushes, pulls, branches and syncs with conventional commit messages, pausing only for risky or irreversible actions. Triggers on "new project", "start a project", "init repo", or any task that creates or edits files in a project worth keeping.

SKILL.md

4.7 KB, as published. Nobody here has run it

GitHub Auto Backup

Manage Git and GitHub for every project so the user ALWAYS has an up-to-date copy on GitHub. Work autonomously for routine version control; pause only for the risky actions listed below. Treat an unpushed change as an unfinished task.

Preflight — always first

  • git --version must exist. If git is missing, give the install command and STOP — local versioning is not possible without it.
  • Check GitHub availability with gh --version and gh auth status. Do NOT hard-stop if gh is missing or not logged in — instead note it and let the interview below decide (the user may want GitHub, may want help setting it up, or may prefer to stay local-only).

Starting a new project — ask first, confirm once

Do NOT create anything yet. First ask whether the user wants an off-machine backup at all:

  1. GitHub backup? — "Do you want this project backed up to GitHub, or keep it local-only for now?"
    • If they want GitHub but gh is missing or not authenticated, offer to help connect: guide them through installing gh and running gh auth login. If they would rather not right now, fall back to local-only.
    • Local-only path: skip the GitHub questions. Just confirm the default branch and a stack-based .gitignore, then git init, add .gitignore (+ optional license/README), and make the initial commit. Tell them you can connect GitHub anytime later (see "Connecting GitHub later").

If they DO want GitHub, ask these, proposing sensible defaults so they can just say "ok":

  1. Visibility — public or private? (default: private)
  2. Repo name — propose one based on the folder name.
  3. Account / organization — which owner? (default: personal account)
  4. .gitignore / license / README — propose a .gitignore based on the detected stack; ask which license (if any) and whether to generate a README.
  5. Default branch — (default: main)

Then summarize the choices in a short list and confirm ONCE. Only after the user says yes:

  1. git init -b <branch> and add the chosen .gitignore (always exclude .env, *.key, secrets, node_modules/, build output), license and README.
  2. Make the initial commit.
  3. Create the GitHub repo with the chosen visibility: 
    gh repo create <owner>/<name> --<private|public> --source=. --remote=origin --push
  4. Report the repo URL.

Connecting GitHub later

If a local-only project should later get a remote (the user asks, or you remind them), make sure gh is authenticated, then run the same gh repo create command above with --source=. to publish the existing history and push.

During the project — work autonomously

Do these WITHOUT asking each time, using conventional commit messages (feat:, fix:, chore:, docs:, refactor:, test:, …):

  • git pull --rebase before starting work so the local copy never diverges.
  • git add -A and commit after each unit of work.
  • Push to the remote — automatic for private repos (for public repos see gated actions below).
  • Create and switch branches as needed for focused work.
  • Keep local and remote in sync.

Local-only projects (no remote): still commit after each unit of work so history is preserved, and skip the push/pull steps. Now and then remind the user there is no off-machine backup yet and offer to connect GitHub.

Report briefly what you did (commit hash + files changed).

Ask permission first — risky / irreversible

STOP and ask for explicit confirmation before:

  • Pushing to a public repo.
  • Opening or merging a pull request.
  • Force pushing (--force / --force-with-lease).
  • Deleting branches (local or remote).
  • Changing repository settings (visibility, default branch, collaborators, …).

Never do

  • Permanently delete a repository.
  • Change visibility from private to public without explicit confirmation.
  • Commit secrets or tokens. Make sure .env, keys and tokens are in .gitignore before the first push. If a secret is already staged, unstage it and warn the user.

Merge conflicts

Do not auto-resolve. Show the conflicting files and let the user decide how to resolve them, then continue and report.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.