/fix

argument-hint: "[PR URL] [other PR URL...] [content]"
description: Act on the findings a review left on a PR — takes or declines each by severity, edits code at pwd to match the project, 1 commit, replies once pushed.

> **CRITICAL:** `Read` `"${CLAUDE_PLUGIN_ROOT}"/core/guardrails.md` FIRST, and `core/cli.md` with it — > they carry the shared rules and the `<op>` runtime. `<op>` ≡ `sh "${CLAUDE_PLUGIN_ROOT}"/bin/open-pr.sh`, > exactly as THIS line spells it — no env var exists in the shell. Every bare `dir/file.md` a Step > `Read`s lives under that same plugin directory. On top of those: > - This command EDITS REAL CODE at pwd, then commits/pushes — higher risk than the > read-only `/open-pr:review`. Step 1 MUST run BEFORE ANY other action. FORBIDDEN: "helpfully" > fixing the remote/branch just to pass it. > - FORBIDDEN: `git commit --amend`, `git push --force`/`--force-with-lease`, `git add -A`/`git add .`, > `git branch -D`, `git reset --hard`, resolving a PR thread, editing/committing when the PR's branch > is protected or the remote/branch doesn't match the PR, deciding alone on a 🔵/📝 finding, RAW-git > branch checkouts or worktree add/remove (Step 1b's `<op> checkout` is the ONLY sanctioned one), > close/merge/reopen, `<op> post`/`publish` (this command only replies; posting is `review.md`'s > job). `cd` is allowed ONLY between the invocation directory, the 1a directory (once its git > remote proves the match — never by name), and the Step 1b worktree. These bullets are the SOLE > enforcement layer — no `allowed-tools` backs them (deliberate).

Step 0 — Target

`<op> target <url>`; exit 4 or no URL → the block below. `Read` `core/pr-target.md`, taking its no-store branch (§2): this command never persists `git_remote_type`, it uses the parsed vendor as-is.

❌ Error: No PR URL provided.
Usage: /open-pr:fix <PR URL> [content]
Example (GitHub): /open-pr:fix https://github.com/org/repo/pull/123
Example (GitLab): /open-pr:fix https://gitlab.com/org/repo/-/merge_requests/123
Example with instructions: /open-pr:fix https://github.com/org/repo/pull/123 only fix the security part

Free-form text outside the URL narrows this run's scope (Step 3 item 3).

`--status-file` in `ARGUMENTS` ⇒ `Read` `cases/watch-session.md` before Context.

**≥2 valid PR URLs** → `<op> target` EACH, then `Read` `cases/multi-pr-fix.md` — it classifies how they relate, confirms the list with the dev and sets the run order. FORBIDDEN: acting on the first URL alone, or folding 2 PRs into 1 run.

No URL → take the PR THIS session already establishes (its review ran here, the user named it, pwd is its worktree), say which in 1 short sentence, continue. NOT exactly 1 ⇒ the `Usage:` block. FORBIDDEN: guessing past it.

Context

`<op> context --sections info,head,comments,reviews,account,threads` — labels "PR info", "Head SHA", "Old comments", "Reviews", "Account", "Review threads". Plus 2 plain `git` commands, label "Git remote + current branch": `git remote -v` && `git branch --show-current` — pwd may be no repo (exit 128) or the wrong one; not fatal, Step 1 re-checks at the 1a directory.

"Reviews" empty ⇒ Step 3 item 2 does not apply; LINE-level handling continues normally.

`core/pr-target.md` §4-5 give `<repo>` and the empty-"PR info" stop.

Step 1 — Verify a safe context (STOP IMMEDIATELY on failure)

**1a.** `<op> locate-repo` → `<repo_dir>` (exit 5 → ask with a CHOICE in plain language, STOP if unresolved). `<op> data-dir` → `<data>`; `<memory-dir>` = `<data>/<repo>`, wherever this runs from. Then `cd` into `<repo_dir>` — this command EDITS that repo's files ⇒ works from inside.

**1b. Check BOTH at the 1a directory.** Either failing → print that error, STOP COMPLETELY. FORBIDDEN: touching any file, proceeding to Step 2.

1. the current branch matches `headRefName` EXACTLY **and its tip prefix-matches "Head SHA"** ⇒ fix in place — a matching name on a stale tip edits a tree the findings do not describe and the push cannot fast-forward. Else `<repo_dir>` = a review worktree whose `git rev-parse HEAD` prefix-matches "Head SHA" ⇒ fix there (DETACHED is normal). Anything else — wrong branch, stale tip, stale worktree — ⇒ ONE CHOICE per `core/guardrails.md`. A checkout THIS session already established that prefix-matches "Head SHA" ⇒ `Use the session's checkout at <path> (Recommended)` heads the options; else the recommendation is `Fix in a fresh worktree (Recommended)` — `<op> checkout` (the worktree lands under `<data>`), gates it to "Head SHA"; the user's own branch/tree stays untouched; `cd` into the printed worktree, continue there — vs stop-and-checkout yourself, printing:

   ❌ Current branch (`<current branch>`) doesn't match the PR's branch (`<headRefName>`). Check
      out the correct branch `<headRefName>` and call this again.

2. `headRefName` is NOT one of `main`, `master`, `production`, `prod`, `staging`, `stg`, `release`, `rls`, `dev`, `development`, `develop` (case-insensitive, EXACT match, not substring). Read off the PR ⇒ holds detached too, and a PR may itself target a protected branch:

   ❌ The PR's branch (`<headRefName>`) is a protected branch — this command does NOT commit to
      one. Move the change onto a dedicated feature branch and open the PR from that.

Step 2 — Settings

`<op> settings --repo <repo> --star` (`core/repo-settings.md` names what each field means). Resolve `chat_language` per that file.

• the FILE carries a `.fix` node → use its values, do NOT ask again
• `memory_found: false` → `Read` `cases/memory-not-found.md` FIRST — it may import or STOP
• absent, or no file at all → `Read` `setup/fix-bootstrap.md`, follow it

Step 3 — Identify findings to handle

2 KINDS, differing in data source and in how "still open" is decided; `Read` `core/finding-markers.md` — it defines how both are recognized.

1. **LINE-level** (from "Old comments") → drop a finding when EITHER holds: