Fix a GitHub Issue Through Merge

Treat /gh-fix OWNER/REPO#ISSUENUMBER as authorization to implement, publish, continuously repair, and merge the fix for that issue. The invocation may append identity:/glorp:<ID> to identify the Glorp instance that dispatched it. Work autonomously until the PR merges, the issue withholds merge authorization, or a genuine external blocker requires the user. Never alter the user's existing checkout; perform all changes in a separate clone.

Validate the request

1. Require exactly one positive integer GitHub issue number; accept an optional leading #. Use GitHub-style #NNN references everywhere this workflow names that issue (branches, commits, PR bodies, comments, and follow-ups). Never substitute an ambient external tracker identifier such as ABCD-123 for the issue number, even if it appears in the issue, commits, or other context. Also accept one optional trailing identity:/glorp:<ID> argument and retain that identity for comment handling. Accept the optional trailing advice and do not merge, after the identity when present, as a do-not-merge directive for this run. Accept the further optional trailing advice and no changelog, after the identity and any do-not-merge advice when present, as a no-changelog directive for this run: skip step 4 of "Implement the fix" and add no changelog entry, regardless of what the issue or repository conventions otherwise call for.
2. Identify the GitHub repository. Prefer OWNER/REPO given directly in the command itself (/gh-fix OWNER/REPO#N, as glorp always dispatches it) — this is the authoritative form and needs no further detection. If the command was invoked as bare /gh-fix N instead, look for a Repository: OWNER/REPO line elsewhere in the invocation, or the user otherwise stating OWNER/REPO explicitly, and use that. Never run git remote -v, gh repo view, or any other repository-detection command when a repository was given by any of the above. Only when no repository was given anywhere in the invocation, fall back to the current checkout's GitHub remote to infer OWNER/REPO, and only ask the user if that also fails to identify a repository.
3. Require git, gh, and an authenticated gh session with repository and workflow access. If the issue exists but this or any other environment requirement cannot be satisfied, stop without opening a pull request or otherwise mutating the repository — but post a single comment on the issue explaining why no fix was implemented, following the rule below.
4. Read the issue title, body, labels, comments, state, and linked context. When an identity was supplied, also read all issue comments and linked pull-request conversation in chronological order as a threaded conversation: the issue body establishes the initial request and later comments can amend, clarify, or override that context. Comments containing the exact @/glorp:<ID> mention for the supplied identity are direct instructions to this agent and must not be ignored; mentions naming a different identity are not instructions to this run. If the issue does not exist, stop; there is nothing to comment on. If it is not actionable, or is already closed, stop without opening a pull request or otherwise mutating the repository — but post a single comment on the issue explaining why no fix was implemented, following the rule below.
5. Determine whether the issue withholds merge authorization, and record that decision before any code is written. Treat either of these as a do-not-merge directive: a label that reads as a merge hold (donotmerge, do-not-merge, do not merge, no-merge, hold, needs-review), matched case-insensitively and ignoring spaces, hyphens, and underscores; or wording anywhere in the issue body or its comments — including a @/glorp:<ID> instruction addressed to this run — asking that the fix not be merged, be left open, or stop before merging. Read the thread chronologically: a later comment can impose or lift the hold, so the most recent statement wins. When the directive is present, note the exact label or quote the wording it came from and carry it through the whole run: everything up to and including marking the pull request ready still happens, and "Hold the pull request when merging is withheld" replaces the merge.
6. Read repository instructions, including applicable AGENTS.md, contribution guidance, branch/PR rules, CI configuration, and changelog conventions.

Always comment and track follow-up work before giving up. Whenever this skill stops for any reason before a pull request has been created for the issue — an invalid or non-actionable issue, a missing environment requirement, an unresolvable ambiguity, a repeated tooling failure, or any other blocker encountered anywhere earlier in this workflow — post exactly one comment on the issue explaining what was attempted and why no fix was implemented before ending the run, unless the user explicitly requested follow-up work instead. A tracking issue that ends the run under "Split a multi-part issue into sub-issues" is not a blocker and is exempt from this rule: it comments once when it is first split and stays silent on every later run that finds nothing new to say. Do this even if a draft pull request was never opened. Once a pull request exists, later blockers are reported on the pull request per "Drive CI to completion" instead of as a new issue comment. Before stopping in either case, create or link any actionable follow-up issues and route them as required by "Create follow-up issues." This keeps both the reason and the next concrete work visible on GitHub instead of only in the final report to the caller.

Resume existing work (re-entrant mode)

/gh-fix N must be safe to run again after being interrupted (Ctrl+C, a crashed session, a new session started later) or handed off by the caller from a prior run. Before creating anything new: