Make skills work in Claude Code cloud sessions: port gh porcelain to REST

Skills load and appear healthy in Claude Code cloud sessions, then fail partway
through, because gh porcelain commands are blocked there.

The constraint

Cloud sessions route GitHub traffic through an agent proxy that injects
credentials per user. That is the right design for a shared environment —
everyone acts as themselves rather than through one shared PAT — but it fences
off GraphQL:

• gh api user, gh api repos/{owner}/{repo}/... — work
• gh api graphql — 403, except a pinned set of PR-review operations
• gh pr list, gh pr view, gh issue list, ... — 403, because gh
  porcelain uses GraphQL under the hood

The proxy's own error names the fix: "Use REST via gh api repos/{owner}/{repo}/... instead."

Setting a real GH_TOKEN in the environment would bypass this, but it is not an
option for a shared environment: the value is readable by everyone using it, and
every user would then act as a single GitHub identity.

Note gh auth status reports "invalid token" in cloud sessions. That is a false
negative — it validates the placeholder rather than making a normal API call.
gh is authenticated; only GraphQL is blocked.

Audit

No plugin contains gh api graphql — zero files in the repo match graphql.
The exposure is entirely porcelain:

Plugin	gh references
deep-review	12
improve-stories	10
self-review	9
start-work	6
craft-pr	5

Concentrated in gh issue create (8), gh issue view (5), gh issue edit (4),
gh issue list (3), gh issue comment (3), plus gh pr view, gh pr list,
gh pr edit, gh pr create, gh pr checkout, gh repo view. Some matches are
prose in READMEs and test files rather than live invocations, so the real count
is lower — worth confirming per plugin before porting.

Work

1. Port porcelain to REST where an equivalent exists. Most of the above maps
cleanly:

gh pr list      -> gh api repos/{owner}/{repo}/pulls --jq '.[] | ...'
gh issue view N -> gh api repos/{owner}/{repo}/issues/N
gh issue comment-> gh api repos/{owner}/{repo}/issues/N/comments -f body=...

These work under the proxy AND locally, so skills become portable rather than
environment-specific. That is worth doing on its own merits.

2. For operations with no REST equivalent, write instructions rather than
shell. Issue relationships (addBlockedBy / removeBlockedBy) are GraphQL-only
in GitHub's API, and that workflow is documented in standards/CLAUDE.md. A bash
script cannot call the GitHub MCP tools — those are available to the agent, not
to a subprocess — so the step should be phrased as instructions the agent
executes with whatever tooling is present:

To link issues, use the GitHub MCP tools if available. Otherwise use
gh api graphql with the addBlockedBy mutation, where issueId is the
blocked issue and blockingIssueId is the dependency.

In cloud the agent reaches for mcp__github__*; locally it uses gh. Same
skill, no configuration.

3. Fail loudly where neither path works. Cloud sessions set
CLAUDE_CODE_REMOTE=true:

if [ "$CLAUDE_CODE_REMOTE" = "true" ]; then
  echo "This step needs GraphQL, which the cloud proxy blocks."
  echo "Use the GitHub MCP tools, or run it locally."
  exit 0
fi

A clear message beats a 403 that reads like a broken skill — which is how this
presented the first two times it was hit.

Why it matters

A skill that loads, reports healthy, and then silently loses capability is worse
than one that fails to load. The failure looks like a bug in the skill rather
than an environment constraint, and it costs a debugging session each time.

Verification

For each ported skill, run it in a cloud session and confirm the gh-dependent
steps complete — not merely that the skill appears in the skills list. Loading
and executing are different, and only the second is the thing that matters here.

Start by auditing the gh references in the deep-review, improve-stories, self-review, start-work, and craft-pr plugins, separating live commands from README and test text. Read standards/CLAUDE.md for the issue-linking workflow, then verify each ported skill in a cloud session and confirm its GitHub-dependent steps complete; unsupported GraphQL paths should report the documented limitation.