[BUG] `/ultrareview <PR#>` fails when origin remote uses an SSH host alias for multi-account setups

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

/ultrareview <PR#> rejects repositories whose origin URL uses a custom SSH host alias (a common pattern for
managing multiple GitHub accounts on one machine), even when the repo is unambiguously a GitHub repo and gh CLI
resolves it correctly.

What Should Happen?

/ultrareview recognizes the repo as GitHub myorg/myrepo and reviews PR #123.

Error Messages/Logs

❯ /ultrareview  123
  ⎿  /ultrareview <PR#> needs a GitHub remote so it knows which repository the PR is in. If this project is not on
     GitHub yet, run "gh repo create --source=. --push" to create one; if a GitHub repo already exists, run "git remote
     add origin REPO_URL". Or run /ultrareview with no argument to review your current branch instead.

Steps to Reproduce

Configure git for the multi-account-via-SSH-alias pattern:

```bash
# ~/.ssh/config has a Host alias entry:
# Host github-work
# HostName github.com
# User git
# IdentityFile ~/.ssh/id_ed25519_work

# Global insteadOf rewrites GitHub URLs to the alias so the right key is used:
git config --global url.git@github-work:myorg/.insteadof https://github.com/myorg/

# Clone via the canonical URL — git rewrites it at clone time and persists the
# rewritten URL in .git/config:
git clone https://github.com/myorg/myrepo.git
cd myrepo

git remote -v
# origin git@github-work:myorg/myrepo.git (fetch)
# origin git@github-work:myorg/myrepo.git (push)

git config --get remote.origin.url
# git@github-work:myorg/myrepo.git

In Claude Code, run:

/ultrareview 123

Expected

/ultrareview recognizes the repo as GitHub myorg/myrepo and reviews PR #123.

Actual

/ultrareview <PR#> needs a GitHub remote so it knows which repository the PR is in.
If this project is not on GitHub yet, run "gh repo create --source=. --push" to create one;
if a GitHub repo already exists, run "git remote add origin REPO_URL".
Or run /ultrareview with no argument to review your current branch instead.

Passing the full URL form fails with a similarly misleading message:

/ultrareview https://github.com/myorg/myrepo/pull/123
> "https://github.com/myorg/myrepo/pull/123" is not a branch in this repo.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.123

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

/ultrareview appears to detect GitHub by string-matching github.com against the remote URL. With the multi-account
SSH-alias pattern, the URL stored in .git/config is the alias form (git@github-work:myorg/myrepo.git) — either because
the insteadOf rule rewrote it at clone time, or because the user set it directly. The hostname github-work doesn't
contain github.com, so the check fails.

This affects any developer using the documented multi-account pattern from GitHub's docs (separate SSH key per
account, host alias + insteadOf to keep canonical clone URLs working).

Suggested fixes (any of these would resolve it)

1. Fall back to gh CLI. gh repo view --json nameWithOwner already returns the correct repo in this configuration — gh

resolves the host via ~/.ssh/config (or its own auth state) and finds myorg/myrepo. If remote-URL parsing fails, try
gh before giving up.

1. Resolve SSH host aliases. Parse ~/.ssh/config and map Host github-work → HostName github.com before the GitHub

check. This is what gh does internally.

1. Improve the error message. The current message tells the user to add a remote, but the remote exists — it just

isn't recognized. Mentioning SSH aliases / insteadOf as a known cause, and suggesting gh repo set-default as a
workaround, would save debugging time.