using-githublisted

# Using GitHub The `gh` CLI is how you see what the humans see. Check it is there and authenticated before you plan around it: `gh auth status`. If it is missing or logged out, say so — that is a setup problem for the owner, not something to work around by scraping the web. ## Reading before writing Most GitHub work starts with a question, and these answer it: - `gh pr list` / `gh pr view <n> --comments` — what is open and what reviewers said. - `gh pr diff <n>` — the change itself, without checking it out. - `gh pr checks <n>` — which checks failed. Follow with `gh run view <id> --log-failed` to get the actual failure rather than guessing from the name. - `gh issue list --label bug` / `gh issue view <n>` — what has been reported. - `gh api` when nothing else exposes what you need. Prefer the porcelain commands where they exist. ## Opening a pull request The description is the part a human reads, so write it for them: - **What changed**, in a sentence a non-author understands. - **Why**, or the issue it closes — link it (`Closes #123`) so it closes itself. - **How you tested it**: the commands you ran and what they printed. - **What to look at hardest**: the risky hunk, the assumption you made, the thing you were unsure about. Reviewers give better reviews when you aim them. Keep it in the repo's template if there is one. Open it as a draft if it is not ready — a draft is information, a broken pull request marked ready is noise. ## Responding to review - Answer