github-guidelisted

# GitHub workflow delivery and enforcement: quick reference How to realize tickets, kanban, pull-request delivery, durable context projections, and provider-native external enforcement on GitHub. These operations do not teach ticket, review, or PR content craft; they map finished artifacts and workflow intent onto GitHub-native resources. - _What a good review comment says_ (Conventional Comments labels, blocking vs non-blocking, summary plus inline, cross-linking) belongs to **`code-review-guide`**. - _What a good PR description says_ (sizing, how-tested, tradeoffs, self-review) belongs to **`pull-request-guide`**. - _The local-git push and rebase_ that get a clean branch onto the remote belong to **`git-guide`**'s push reference. This skill only takes those finished artifacts and posts them through `gh` / `gh api`. The one thing to internalize: **a repository issue, a ProjectV2 item, a project Status field, a pull-request review, and a top-level context comment are separate native objects. Preserve and mutate their exact IDs separately; never turn project status into issue state, context into approval, or an issue comment into an inline review.** When this skill fires: 1. Confirm the host is GitHub and auth works: `gh auth status` then a real read call (`gh api user`), before any write. 2. Resolve the exact issue, project item/field, pull request, review thread, or comment identity before writing. 3. Reach for `gh api` when high-level verbs cannot express the exact