/pseudo-merge

name: pseudo-merge
description: 'Takes a proofread or apsa-style report file (or any markdown file using **Original:** / **Recommended:** syntax) and rewrites the original source file with git merge conflict markers so the user can accept or reject each suggested edit using VS Code or Positron''s built-in merge conflict UI. Branch names are "original" and "claude-edits". Use when asked to apply edits, insert conflict markers, or set up merge resolution for a copy-edit report. Supports an optional @sec-label argument to restrict markers to one section.'
metadata:
  author: Christopher T. Kenny
  version: 1.0

Pseudo-Merge

You take a copy-edit report (produced by the `proofread` or `apsa-style` skills, or any markdown file using the same `**Original:**` / `**Recommended:**` syntax) and rewrite the original source file with **git merge conflict markers**. This lets the user accept or reject each suggested edit individually using VS Code or Positron's merge conflict UI.

The fake branch names are always:

• `<<<<<<< original` — the current text
• `>>>>>>> claude-edits` — the suggested replacement

**This skill modifies the original source file in place.** Inform the user of the path before writing, and remind them that `git diff` or file history can recover the pre-merge state.

---

Input Arguments

| Position | Required | Description | |----------|----------|-------------| | 1 | **Yes** | Path to the report file (e.g., `paper/paper-copy-edits.md` or `paper/paper-style-edits.md`) | | 2 | No | Path to the original source file to modify. If omitted, derived automatically (see below). | | `@sec-label` | No | Quarto section reference (e.g., `@sec-intro`). Detected by the leading `@`. If supplied, only conflict markers within that section are inserted. May appear in any argument position. |

**Example invocations:**

/pseudo-merge paper/paper-copy-edits.md
/pseudo-merge paper/paper-copy-edits.md @sec-intro
/pseudo-merge paper/paper-style-edits.md paper/paper.qmd @sec-data
/pseudo-merge reviews/my-edits.md src/manuscript.qmd

Section Filter (`@sec-label`)

Scan **all arguments** for one that begins with `@`. That is the section filter. Strip the leading `@` to get the Quarto label (e.g., `@sec-intro` → `sec-intro`).

In Quarto, section labels are attached to headings with `{#label}` syntax:

# Introduction {#sec-intro}
## Data and Methods {#sec-data}

Find the heading line in the **source file** whose `{#…}` attribute matches the label. The section spans from that heading line to (but not including) the next heading of **equal or higher level**. Track the line range of that span.

When matching `(Original, Recommended)` pairs against the source file, **only accept matches whose position falls within that line range**. Skip pairs that match outside the section without warning — they are intentionally out of scope.

If no heading with that label is found in the source file, stop and tell the user. List all `{#sec-*}` labels found in the file.

Deriving the source file path (when arg 2 is omitted)

1. Strip the suffix `-copy-edits`, `-style-edits`, or `-edits` from the report filename stem. 2. Append `.qmd`. 3. Look for that file in the same directory as the report.

Examples:

• `paper/paper-copy-edits.md` → `paper/paper.qmd`
• `paper/paper-style-edits.md` → `paper/paper.qmd`
• `drafts/ch2-edits.md` → `drafts/ch2.qmd`

If the derived path does not exist and no second argument was given, stop and ask the user for the source file path.

---

Report Format Expected

The skill reads any markdown file that contains issue blocks of this shape (produced by `proofread` and `apsa-style`):

**Original:** Full original sentence here.
**Recommended:** Full corrected sentence here.

These may appear inside a section heading block like:

### [CRITICAL · Grammar] Subject-verb disagreement
**Original:** The results shows that incumbents win more often in low-turnout elections.
**Recommended:** The results show that incumbents win more often in low-turnout elections.
**Reason:** ...

Extract every `(Original, Recommended)` pair in order from top to bottom.

---

Merge Conflict Syntax

Replace each matched original sentence in the source file with:

<<<<<<< original
The results shows that incumbents win more often in low-turnout elections.
=======
The results show that incumbents win more often in low-turnout elections.
>>>>>>> claude-edits

Rules:

• No blank line between `<<<<<<< original` and the original text.
• No blank line between `=======` and the recommended text.
• No blank line between the recommended text and `>>>>>>> claude-edits`.
• Preserve the surrounding whitespace and indentation of the original text exactly.
• If the original sentence ends with a newline, keep that newline inside the conflict block (before `=======`), not after `>>>>>>> claude-edits`.

---

Step-by-Step Workflow

1. **Read the report file** using the `Read` tool. Extract all `(Original, Recommended)` pairs in document order.

2. **Resolve the source file path** — use arg 2 if given, otherwise derive it from the report filename. Confirm the file exists.

3. **Inform the user** — before making any changes, tell them:

• The source file that will be modified: `<path>`
• The number of edits that will be applied: N
• That `git diff` or file history can restore the original

4. **Read the source file** using the `Read` tool.

5. **Match and replace** — for each `(Original, Recommended)` pair, working top to bottom:

a. **Exact match** — search for the original sentence verbatim in the source text. If found, replace with the conflict block.

b. **Fuzzy match** — if exact match fails (likely due to line wrapping or minor whitespace differences), extract the longest distinctive substring (usually 8+ consecutive words) from the original sentence and search for it. Once located, expand the match to the full surrounding sentence before rep