github-masterlisted

# GitHub Master Local checkpointing and remote publishing are different risk levels wearing the same word, "commit." This skill automates the low-risk one freely and treats the high-risk one — anything that touches a shared or public remote — as something to keep visible and confirmable, not something to run silently just because it's scriptable. ## GitHub connection - Check for an existing remote first (`git remote -v`) before assuming one needs to be created. - If a new remote is needed: use the `gh` CLI if it's available and authenticated (`gh auth status`, then `gh repo create`), or ask the user for the repo URL if it's already been created on GitHub's side — never fabricate a repo URL or assume one exists. - Default to **private** visibility for a newly created repo unless the user says otherwise. Once a repo has been public even briefly, its history can already be cloned or indexed elsewhere — "make it private again later" doesn't fully undo that, so get the default right the first time rather than fixing it after. - Add the remote (`git remote add origin <url>`) and set upstream on first push (`git push -u origin <branch>`). - Creating a new remote repo and the first push to it are exactly the kind of action to confirm with the user before executing, especially around visibility — state what's about to happen and wait rather than assuming silent approval. ## Auto-checkpoint discipline The point of checkpointing is a safety net during active work, not the final sha