gh-managerlisted

# gh-manager Manage GitHub repository settings declaratively: a single `repos.yaml` declares the desired state of repos (description, visibility, labels, branch protection); a **plan** diffs it against live state; **apply** reconciles the two. Never mutate anything without showing the diff and getting explicit consent. Ported from [gh-manager](https://github.com/ddlaws0n/gh-manager) by David Lawson ([@ddlaws0n](https://github.com/ddlaws0n)), MIT. ## Ground rules - **`plan` is always read-only.** Never call anything mutating before the consent gate below, not even "just to check". - **The consent gate is non-negotiable.** Before apply, show the rendered plan and ask via `ask_user` (suggested: the safe option). One consent covers exactly the shown plan; a changed plan needs fresh consent. - **Access goes through `gh`** (`gh auth status` first). Never handle tokens yourself; `GITHUB_TOKEN`/`gh auth login` is the user's business. If `gh` is missing or unauthenticated, say so and stop — propose the `wizard` skill if the user wants guided setup. - **Undeclared ≠ delete.** Live settings the declaration doesn't mention (extra labels, other branches' protection) are never touched. Report them as drift context, nothing more. ## The flow: init → plan → apply ### 1. init If no `repos.yaml` exists, create one by reading the user's current state (read-only `gh api repos/<owner>/<repo>`, `.../labels`, `.../branches/main/protection`) and rendering it as the starting de