fix(skill): handle squash-merged sync PRs in cherry-pick-sync

[amilz]

Summary

• Updated cherry-pick-sync skill to find the last sync baseline by checking prior cherry-pick PR bodies on the release branch
• Prior syncs are squash-merged, so git cherry can't detect them — the skill now reads the PR body to find the last main commit that was synced
• Added secondary git cherry -v check for commits that were individually cherry-picked (non-squash)

Test plan

• Verified the updated workflow during today's sync (PR chore: sync main into release/2.2.0 (2026-03-13) #386) — correctly identified only 4 new commits instead of 27+

[github-actions]

📊 TypeScript Coverage Report

Coverage: 39.6%

View detailed report

Coverage artifacts have been uploaded to this workflow run.
View Artifacts

[greptile-apps]

Greptile Summary

This PR updates the cherry-pick-sync skill to correctly handle the common case where prior sync PRs were squash-merged into the release branch, making them invisible to git cherry and git log range comparisons. The fix introduces a smarter baseline-detection strategy: search the release branch's git log for prior sync PRs by commit message pattern, read the matched PR's body to extract the last synced main commit SHA, and use that SHA as the lower bound for the new commit range instead of the release branch tip.

Key changes:

• Added a new primary path in Step 2 that greps git log on the release branch for matching squash-merge commit messages, then reads the PR body via gh pr view <number> to find the sync baseline SHA.
• Added a fallback to the original full-range approach when no prior sync PR is found.
• Added a secondary git cherry -v check to catch any commits that were individually cherry-picked (non-squash) and are already applied.

Issues found:

• Undocumented PR number extraction (lines 40–43): The skill tells the AI to use gh pr view <number> but never explains how to derive <number> from the git log --oneline output. GitHub's default squash-merge format appends (#NNN) to the commit message, but this is not guaranteed. A documented extraction step or a gh pr list fallback is needed to make the skill robust.
• No fallback when PR body is unparseable (line 43): If the matched PR's body doesn't follow the ### Commits included template (e.g., it predates the skill or was manually edited), the skill provides no documented recovery path. Without it, the AI agent may use an incorrect or imagined baseline SHA.
• Unbounded git cherry -v scan (line 62): The secondary check runs git cherry -v origin/<release-branch> origin/main over the full branch history, which can be slow on large repos. Scoping it to the same bounded range used in the primary path (<last-synced-sha>..origin/main) would be both faster and easier to parse.

Confidence Score: 3/5

• Safe to merge as a documentation improvement, but the skill has gaps that could cause incorrect baseline detection in edge cases.
• The core logic (use PR body to detect squash-merged sync baseline) is sound and was verified in practice (PR chore: sync main into release/2.2.0 (2026-03-13) #386). However, there are three notable gaps: the PR number extraction from git log output is implicit and breaks when GitHub's default squash-merge message format is not used; there is no documented fallback when the matched PR body is unparseable; and the git cherry -v secondary check is unbounded. These gaps could cause the AI agent to cherry-pick the wrong set of commits in edge cases, which would be user-visible and require a manual correction.
• .claude/skills/cherry-pick-sync/SKILL.md — the three gaps identified in Step 2 should be addressed before this skill is widely relied upon.

Important Files Changed

Filename

Overview

.claude/skills/cherry-pick-sync/SKILL.md

Updated Step 2 to detect squash-merged sync PRs via git log grep + PR body parsing instead of relying on git cherry; added git cherry -v as a secondary check. The logic is sound but contains three gaps: PR number extraction from commit message is undocumented, no fallback is specified when the PR body doesn't follow the template, and the git cherry -v secondary check runs over the full branch history without a range limit.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A([Start: Determine commits to cherry-pick]) --> B[git fetch origin main release-branch]
    B --> C["Search git log on release branch\ngit log --oneline origin/release-branch\n| grep cherry.pick|sync.*main | head -3"]
    C --> D{Match found?}
    D -- No --> E["Fallback: full range\ngit log --oneline --reverse\norigin/release-branch..origin/main"]
    D -- Yes --> F["Extract PR number from\ncommit message (#NNN)"]
    F --> G["gh pr view NNN\nRead PR body"]
    G --> H{PR body parseable\nfor last SHA?}
    H -- No --> E
    H -- Yes --> I["Extract last-synced-sha from\n### Commits included section"]
    I --> J["Bounded range\ngit log --oneline --reverse\nlast-synced-sha..origin/main"]
    E --> K[Candidate commit list]
    J --> K
    K --> L["Secondary check\ngit cherry -v origin/release-branch origin/main\nSkip lines starting with '-'"]
    L --> M["Auto-skip release-only commits\nversion bumps, CHANGELOG, chore: release v*"]
    M --> N[Show final commit list to user]
    N --> O{User confirms?}
    O -- Yes --> P([Proceed to Step 3: Preconditions])
    O -- No --> Q([Adjust list & re-confirm])

Loading

_{Last reviewed commit: dbe2ac2}