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 replacing.

   c. Skip and warn — if neither match works, record the pair as unmatched. Do not insert a conflict block for it. Continue with the remaining pairs.

   Avoid matching inside fenced code blocks (``` or ~~~ delimiters) or inside Quarto shortcode spans ({{< >}}).

6. Write the modified source file using the Edit tool (preferred, to minimize diff) or the Write tool. Apply all successful replacements.

7. Report results to the user:

   • How many conflict markers were inserted (applied)
   • How many edits could not be matched (list them with their section label so the user can find them manually)
   • Reminder: open the file in Positron / VS Code to resolve conflicts using the inline merge UI

---

Edge Cases

Situation	Behaviour
Same original sentence appears more than once in the source	Insert a conflict marker at every occurrence. Each will be independently resolvable.
Original sentence spans a line break in the source	Fuzzy-match on the longest phrase that fits on a single line, then expand to the sentence boundary.
Report lists the same original sentence twice (two different recommendations)	Apply them in report order; the first match consumes the first occurrence of the sentence.
Source file has already been partially edited (some originals no longer present)	Skip silently, include in the unmatched summary.
Conflict block would appear inside a Quarto code chunk	Skip and warn — never insert markers inside code fences.

---

Example Output (in the source .qmd file)

Before:

The results shows that incumbents win more often in low-turnout elections.

After:

<<<<<<< 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

The user then sees inline diff UI in Positron / VS Code:

  Accept Current Change | Accept Incoming Change | Accept Both | Compare Changes

Accepting "Current Change" keeps the original; accepting "Incoming Change" applies the recommendation.