publish-to-ghas skill: document that a gh CLI OAuth token (repo scope) works without a PAT (PAT-restricted orgs)

Read skills/publish-to-ghas/SKILL.md, starting with the Prerequisites, Step 1, Security model, and troubleshooting sections. Document both PAT and existing gh CLI OAuth-token paths, including the provided PowerShell example and PAT-restricted organization guidance, then verify the instructions remain consistent with the security model.

Summary

The publish-to-ghas skill (skills/publish-to-ghas/SKILL.md) presents a GitHub PAT with security_events as the credential. In organizations that prohibit PAT creation (common in enterprise GHE), this reads as "you are blocked" — when in fact an existing gh CLI OAuth token with repo scope publishes successfully. The skill already states this fact, but only as a parenthetical in the Security model; the Prerequisites and Step 1 sections do not reflect it, so an operator following the happy path concludes they need a PAT they cannot create.

Where the gap is

• Security model (correct, but easy to miss):

  A classic or fine-grained GitHub personal access token carrying security_events write (repo also grants it for private repositories) is sent as a bearer token.

• Prerequisites (PAT-only):

  A GitHub personal access token with security_events write, stored in an environment variable.

• Step 1 — Set the token only shows a Read-Host / read -rs paste, implying the operator already holds a PAT. No gh-token source is shown.

Evidence it works without a PAT

On a private repo hosted on a <slug>.ghe.com instance where the org forbids authoring PATs, publishing with the token from the already-authenticated gh CLI (scopes gist, read:org, repo, workflow — note: no security_events) succeeded end to end:

• publish-to-ghas -> HTTP 202 Accepted
• analysis processing_status polled to complete, zero errors
• 117 alerts surfaced in code scanning with full security_severity_level (8 critical / 68 high / 41 medium)

The repo scope alone was sufficient for a private repo; security_events was never present. (Separately, gh auth refresh -h <slug>.ghe.com -s security_events reported success but the authoritative X-OAuth-Scopes header showed the scope was silently dropped — the GHE OAuth app was not permitted to grant it. So for that class of org, the gh OAuth repo token is the only viable path.)

Proposed doc changes (skill-only, no code)

1. Prerequisites — replace the PAT-only line with the fuller credential menu:

   A token with code-scanning upload rights, in an env var. A classic/fine-grained PAT with security_events works; for a private repo, classic repo scope alone is sufficient, so an existing gh CLI OAuth token (gh auth token -h <host>) with repo works with no PAT — important for orgs that prohibit PAT creation.

2. Step 1 — Set the token — add a gh-token source example alongside the manual paste:

   # If already signed in with the gh CLI (repo scope), no PAT needed:
   $env:GHAS_TOKEN = gh auth token -h <slug>.ghe.com   # or github.com
   

3. Edge cases / Troubleshooting — add: "Org forbids PATs? Use the gh CLI OAuth token (repo scope). Do not chase security_events via gh auth refresh — some GHE OAuth apps silently drop it; check X-OAuth-Scopes on GET /user."

This keeps the security guidance intact (least privilege, bearer-only, never echoed) while removing the false "PAT required" wall for PAT-restricted orgs.