git-fix-issuelisted

# Issue Implementer Turn a tracked issue (or the issue behind a PR/MR) into a working code change on the current branch, with a plan the user approves first and an optional PR/MR at the end. ## Workflow overview 1. **Resolve** the source (issue / PR / MR) and read its full content. 2. **Understand** the codebase area involved. 3. **Plan** the fix or enhancement and get user approval. 4. **Implement** on the current branch. 5. **Verify** (build/tests/lint if available). 6. **Offer** to open a PR/MR — only create one if the user says yes. Do not skip step 3's approval. Plans are cheap; wrong implementations are expensive. --- ## Step 1 — Resolve the source The user may give you an issue number, a PR/MR number, a full URL, or a phrase like "the issue this PR closes." First figure out which platform and which host. **Detect the platform.** Check what remote the current repo uses: ```bash git remote get-url origin 2>/dev/null ``` - Contains `github.com` (or a GitHub Enterprise host) → GitHub, use `gh`. - Contains `gitlab` → GitLab, use `glab`. - If a URL was given, trust the URL's host over the remote. **Check CLI availability, fall back to API.** Prefer the CLI because auth is already handled: ```bash command -v gh # GitHub command -v glab # GitLab ``` If the needed CLI is missing or not authenticated (`gh auth status` / `glab auth status` fails), fall back to the REST API with a token from the environment (`GITHUB_TOKEN`, `GH_TOKEN`, or `GITLAB_TOKEN`). See `ref