githublisted

Use the `gh` CLI for everything. The user's token is exported as an env var and `gh` reads it automatically — `gh auth status` will say "not logged in" because gh keeps no config file in the sandbox, but every authenticated subcommand works regardless. **The commands are identical in both modes**; only the permission envelope differs, so check which one you're in before diagnosing a `403`: ```sh if [ -n "$GITHUB_TOKEN" ]; then echo "mode: pat (user-created token)"; \ elif [ -n "$GH_TOKEN" ]; then echo "mode: oauth"; \ else echo "no GitHub connection — connect at https://auth.acedata.cloud/user/connections"; fi ``` Both are **secret — full account access within their scope. Never echo or print them.** `gh --help` and `gh <subcommand> --help` are always current. When unsure, read the help first instead of guessing flags. ## Granted scopes — what you can and cannot do **In PAT mode (`$GITHUB_TOKEN`)** the scopes are whatever the user picked when they created the token, and a fine-grained token may be limited to a few repositories. You cannot introspect them reliably — treat every `403` / `404` as a possible permission limit and say so rather than retrying. **In OAuth mode (`$GH_TOKEN`)** the connection requests exactly five scopes: `read:user`, `user:email`, `repo`, `read:org`, `gist`. Everything in the Recipes below fits inside them. These do NOT fit, and will fail no matter how you phrase the call: | Want to… | Needs scope | Verdict | |---|---|---| | Follow / unfollow a