pr-fix

# PR Review Fix Skill

Automated workflow to resolve all issues surfaced in a pr-review report — parse summary → detect PR status → create fix branch or checkout original branch → **triage & validate** → fix by priority → quality gate → commit → publish → verify.

**Announce at start:** "I'm using pr-fix skill to fix all review issues."

## Usage

```
/pr-fix [pr_number]
```

`pr_number` is optional. The skill requires a pr-review report to be present in the current session.

---

## Mode Detection

At the very start of execution, check `$ARGUMENTS` for the `--automation` flag:

```bash
# $ARGUMENTS example: "123 --automation" or "123"
AUTOMATION_MODE=false
if echo "$ARGUMENTS" | grep -q -- '--automation'; then
  AUTOMATION_MODE=true
fi
```

In **automation mode**:

- Skip all yes/no confirmation prompts — follow the default best path

---

## Steps

### Step 0 — Locate the Review Report

The pr-review skill must have been executed in the current session. The review report (containing a "汇总" table) must be present in the conversation.

If no review report is found in the current session, abort immediately with:

> No pr-review report found in this session. Please run `/pr-review <pr_number>` first.

Extract the PR number from the report header:

```
## Code Review：<PR 标题> (#<PR_NUMBER>)
```

If `pr_number` is provided as an argument, use it to override the extracted number.

---

### Step 1 — Parse the Summary Table

Locate the **汇总** section in the review report:

```markdown
| #   | 严重级别    | 文件        | 问题 |
| --- | ----------- | ----------- | ---- |
| 1   | 🔴 CRITICAL | `file.ts:N` | ...  |
```

Build an ordered issue list, grouped by severity:

| Priority | Severity | Emoji |
| -------- | -------- | ----- |
| 1        | CRITICAL | 🔴    |
| 2        | HIGH     | 🟠    |
| 3        | MEDIUM   | 🟡    |
| 4        | LOW      | 🔵    |

If the 汇总 table is empty, abort with:

> No issues found in the review summary. Nothing to fix.

**LOW issues:** Skip — do not fix.

After filtering out LOW issues, if no CRITICAL / HIGH / MEDIUM issues remain, abort with:

> All issues are LOW severity — nothing actionable to fix. (pr-fix only addresses CRITICAL, HIGH, and MEDIUM issues)

This guard prevents running the full workflow (checkout, quality gate, commit) with no changes to make.

---

### Step 2 — Pre-flight Checks

```bash
gh pr view <PR_NUMBER> \
  --json headRefName,baseRefName,state,isCrossRepository,maintainerCanModify,headRepositoryOwner \
  --jq '{head: .headRefName, base: .baseRefName, state: .state, isFork: .isCrossRepository, canModify: .maintainerCanModify, forkOwner: .headRepositoryOwner.login}'
```

Save `<head_branch>`, `<base_branch>`, `<state>`, `<IS_FORK>`, `<CAN_MODIFY>`, and `<FORK_OWNER>` for later steps.

**Determine path based on results:**

| state    | IS_FORK | CAN_MODIFY | Path                                           |
| -------- | ------- | ---------- | ---------------------------------------------- |
| `MERGED` | any     | any        | Abort — nothing to fix                         |
| `OPEN`   | `false` | any        | Same-repo — push to original branch            |
| `OPEN`   | `true`  | `true`     | Fork — push to fork branch via gh checkout     |
| `OPEN`   | `true`  | `false`    | Fork fallback — create fix branch on main repo |

If state is `MERGED`: abort with:

> PR #<PR_NUMBER> has already been merged. Nothing to fix.

If `IS_FORK=true` AND `CAN_MODIFY=false`: set `FORK_FALLBACK=true` and continue.
In this path (Step 3 onwards), fixes are applied on a new branch in the main repo instead of the fork.
Save `FIX_BRANCH=bot/fix-pr-<PR_NUMBER>` for use in Step 3 and Step 8.

---

### Step 3 — Create Worktree and Prepare Branch

Create an isolated worktree for this PR fix. The main repo stays on its current branch.

```bash
REPO_ROOT=$(git rev-parse --show-toplevel)
PR_NUMBER=<PR_NUMBER>
WORKTREE_DIR="/tmp/aionui-pr-${PR_NUMBER}"

# Clean up any stale worktree from a previous crash
git worktree remove "$WORKTREE_DIR" --force 2>/dev/null || true
```

**Same-repo PR (`IS_FORK=false`):**

```bash
git fetch origin <head_branch>
git worktree add "$WORKTREE_DIR" origin/<head_branch> --detach
cd "$WORKTREE_DIR"
```

**Fork PR with maintainer access (`IS_FORK=true`, `CAN_MODIFY=true`):**

```bash
git worktree add "$WORKTREE_DIR" --detach
cd "$WORKTREE_DIR"
gh pr checkout <PR_NUMBER>
```

`gh pr checkout` inside the worktree sets up the fork remote and branch tracking correctly.

**Fork PR without maintainer access (`FORK_FALLBACK=true`):**

```bash
git fetch origin <base_branch>
git worktree add "$WORKTREE_DIR" origin/<base_branch> --detach
cd "$WORKTREE_DIR"
# Merge PR's commits into the detached HEAD
gh pr checkout <PR_NUMBER> --detach
git checkout -  # back to the base commit
git merge --no-ff --no-edit FETCH_HEAD
```

**All paths — symlink node_modules and rebuild native modules:**

```bash
ln -s "$REPO_ROOT/node_modules" "$WORKTREE_DIR/node_modules"
cd "$WORKTREE_DIR"
npx electron-rebuild -f -w better-sqlite3 2>/dev/null || true
```

The `electron-rebuild` step recompiles native modules (e.g., `better-sqlite3`) against the Electron version used by this project, ensuring ABI compatibility.

Save `REPO_ROOT` and `WORKTREE_DIR` for later steps. All file reads, edits, lint, and test commands from this point forward run inside `WORKTREE_DIR`.

---

### Step 4 — Triage & Validate

Before fixing anything, independently verify each issue from the review report. This prevents blind application of potentially incorrect or suboptimal fixes.

All file operations in this step use worktree paths (`$WORKTREE_DIR/<relative_path>`).

**For each CRITICAL / HIGH / MEDIUM issue (skip LOW), perform three-layer triage:**

#### Layer 1 — Is the issue real?

Read the target file and the surrounding context. Independently assess whether the reported problem actually exists:

- Does the problematic code pattern still exist at the reported location? (Review may be based on an older ver