refactor(source-control)!: remove resolve-conflicts in favour of the pull-request conflict mode

Part of #7576 (PR 3 of 3). Starts after #13137 (PR 2) closes.

Problem

Owner interview Q541: "remove the skill ... update every dependent (the pr-unblock lane)". Once PR 2 has moved conflict resolution into /source-control:pull-request, the standalone skill and every pointer at it go.

Done when

plugins/source-control/skills/resolve-conflicts/ and the ten plugins/source-control/evals/resolve-conflicts-* cases are gone or moved to cases of the PR 2 mode.
The resolve-conflicts activity's skill: and args: in docs/conventions/pr-pipeline.yaml:35-36 and docs/conventions/pr-pipeline/examples/claude-code-plugins.yaml:74 name the PR 2 skill and mode, with --unattended in args (docs/conventions/pr-pipeline.yaml:93-94), and the activity keeps its name resolve-conflicts. .github/actions/collect-base-activity/collect-base-activity.test.mjs, .github/actions/resolve-config/feedback-dispatch.test.mjs and .github/actions/resolve-config/live-config.test.mjs assert the new skill and allowed-tools grant.
plugins/source-control/README.md, docs/skill-cheat-sheet.md:229, plugins/work-items/skills/ship/actions/run.md:81 and its eval, and docs/upstream/mattpocock-skills.md:55,58 (which still says "keep ours pending an eval") are updated to the removal.
rg -n 'source-control:resolve-conflicts' plugins docs .github --glob '!**/CHANGELOG.md' --glob '!.changes/**' finds nothing, and node --test '.github/scripts/pr-unblock/*.test.mjs' exits 0 in the PR's CI.
A changelog fragment for source-control (major: a skill is removed).

Keeping the activity name leaves the grant files that key on it unchanged. The lane-token broker's grant does not depend on skill: (.github/actions/resolve-config/resolve.mjs:927-950), so keeping the activity name needs no broker re-pin.

Filed by Issue Triage from the #7576 spec (agent choice, verified against main). This was generated by AI.

Proposed work class: work-class: structural
Basis: automated intake triage; the lanes App applied this class.

Size: Large
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: none

Understood: remove the standalone resolve-conflicts skill and its evals, repoint the resolve-conflicts pipeline activity at the pull-request conflicts mode (keeping the activity name), update the docs and tests that name the skill, and add a major changelog fragment for source-control.

The last implementation attempt produced a patch over the size cap, so the work needs splitting. One natural split:

Move the eval cases to the pull-request mode. The earlier comment says the cases are to be moved, not dropped.
Repoint the pipeline config and its tests.
Update the docs and the ship skill, then remove the skill and add the changelog fragment.

#13137 does not appear in the open issues, so it looks done. No open duplicates found.

_{Automated triage, applied by the lanes App.}

Not admitted to the issue lane yet: sub-issue #13199 is open.

From the #13149 review (thread on plugins/source-control/skills/pull-request/reference/conflicts-ci.md): the done-when item "the ten resolve-conflicts-* cases are gone or moved" should be read as moved, not dropped, for at least resolve-conflicts-ci-mode-resolves-in-place, -ci-mode-leaves-workflows-alone, -ci-mode-runs-no-gates (to invoke /source-control:pull-request conflicts --ci --unattended) and -refuses-bulk-ours-and-abort (to invoke ready). Until then those cases are the only coverage of the rules #13149 moved into the pull-request skill.

No description provided.

The work-resolve-issue lane stopped on this issue (scan-refused-patch): the scan job refused the run's patch for its size, and the run job's scan of it found no credential shape or binary hunk: the work is too large for one patch, so admission parks it for intake's split (owner Q93) at whatever Size it was triaged (admit.mjs patchCapStopped), and the split files its sub-issues, as for split-required.
It removed agent-ready and status: ready, so the hourly triage sweep sends it back through intake triage, and it waits on no decision from a person.

In the run's words:

The scan job refused the run's output, so nothing was published: too-large: the patch was over its 262144-byte cap. The run's log names its size.

Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41805610261

The triage sweep dispatched intake triage for this issue (dispatch 1; 2 runs that reach intake, or 6 dispatches, hand it to a maintainer).

Split at intake (owner Q93). This issue is Size Large, so its done-when is split into 3 sub-issues, each holding its task-list lines as written.

Part 1: task-list lines 1, 5: refactor\(source-control\)!: remove resolve-conflicts in favour of the pull-request conflict mode - part 1 of 3 #13197
Part 2: task-list line 2: refactor\(source-control\)!: remove resolve-conflicts in favour of the pull-request conflict mode - part 2 of 3 #13198
Part 3: task-list lines 3, 4, after part 1, 2: refactor\(source-control\)!: remove resolve-conflicts in favour of the pull-request conflict mode - part 3 of 3 #13199

_{Automated split by the lanes App. Admission waits on this issue while a sub-issue is open; work-unblock closes it as completed once every sub-issue is closed as completed by a merge or a listed human and its done-when is covered.}

Every sub-issue of this split is closed as completed by a listed human or a merge (#13197, #13198, #13199), so the lanes App closes it as completed.

Navigation Menu

Repository navigation

refactor(source-control)!: remove resolve-conflicts in favour of the pull-request conflict mode #13138

Problem

Done when

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

refactor(source-control)!: remove resolve-conflicts in favour of the pull-request conflict mode #13138

Description

Problem

Done when

Activity

github-actions commented on Nov 4, 2026

melodic-automation-lanes commented on Nov 4, 2026

kyle-sexton commented on Nov 4, 2026

github-actions commented on Nov 4, 2026

github-actions commented on Nov 4, 2026

melodic-automation-lanes commented on Nov 4, 2026

github-actions commented on Nov 4, 2026

melodic-automation-lanes commented on Nov 4, 2026

melodic-automation-lanes commented on Nov 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions