From 45c041f34dcbd2ed27a241428f469ed981e6397d Mon Sep 17 00:00:00 2001 From: carlos-alm <127798846+carlos-alm@users.noreply.github.com> Date: Mon, 16 Mar 2026 19:34:52 -0600 Subject: [PATCH 1/2] docs: add conflict resolution guidance to /review skill MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When resolving merge conflicts, the review skill must check PR commit history and reviewer comments before choosing which side to keep — never assume based on syntax alone. --- .claude/skills/review/SKILL.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/.claude/skills/review/SKILL.md b/.claude/skills/review/SKILL.md index eff495c4..f699d069 100644 --- a/.claude/skills/review/SKILL.md +++ b/.claude/skills/review/SKILL.md @@ -60,7 +60,11 @@ If `CONFLICTING`: ```bash git merge origin/ ``` -2. Resolve all conflicts by reading the conflicting files, understanding both sides, and making the correct resolution. +2. **Do not assume which side to keep.** Before resolving any conflict: + - Check the PR's commit history (`git log --oneline origin/..HEAD -- `) to understand *why* the conflicting line was changed on each side. + - Read Greptile and Claude review comments on the PR (`gh api repos/optave/codegraph/pulls//comments`, `gh api repos/optave/codegraph/issues//comments`) — a reviewer may have requested the change that caused the conflict. + - Compare the PR's diff against its merge base (`git diff $(git merge-base origin/ HEAD) HEAD -- `) to see which side introduced an intentional change vs. which side carried stale code. + - Only then choose the correct resolution. If the PR deliberately changed a line and main still has the old version, keep the PR's version. If main introduced a fix the PR doesn't have, keep main's version. 3. After resolving, stage the resolved files by name (not `git add .`), commit with: `fix: resolve merge conflicts with ` 4. Push the updated branch. From 1d9e96880528dbc867f2215c86a3090aec0aca45 Mon Sep 17 00:00:00 2001 From: carlos-alm <127798846+carlos-alm@users.noreply.github.com> Date: Mon, 16 Mar 2026 19:45:19 -0600 Subject: [PATCH 2/2] docs: require full context understanding before conflict resolution MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Expand the /review skill's conflict guidance to require reading the PR description, linked issues, and main-side commit history — not just the PR's own commits and reviewer comments. If you don't know why a line exists, you cannot resolve the conflict correctly. --- .claude/skills/review/SKILL.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/.claude/skills/review/SKILL.md b/.claude/skills/review/SKILL.md index f699d069..129c2d5d 100644 --- a/.claude/skills/review/SKILL.md +++ b/.claude/skills/review/SKILL.md @@ -60,11 +60,13 @@ If `CONFLICTING`: ```bash git merge origin/ ``` -2. **Do not assume which side to keep.** Before resolving any conflict: - - Check the PR's commit history (`git log --oneline origin/..HEAD -- `) to understand *why* the conflicting line was changed on each side. +2. **Do not assume which side to keep.** You must fully understand the context of both sides before resolving. If you don't know why a line was added — what feature it supports, what bug it fixes, what reviewer requested it — you cannot resolve the conflict correctly. Before touching any conflict: + - Read the PR description and any linked issues (`gh pr view `) to understand the PR's purpose and scope. + - Check the PR's commit history (`git log --oneline origin/..HEAD -- `) to understand *why* the conflicting line was changed on the PR side. Also check the base branch history (`git log --oneline HEAD..origin/ -- `) to understand *why* the base version exists. - Read Greptile and Claude review comments on the PR (`gh api repos/optave/codegraph/pulls//comments`, `gh api repos/optave/codegraph/issues//comments`) — a reviewer may have requested the change that caused the conflict. + - Check what landed on main that introduced the other side (`git log --oneline HEAD..origin/ -- `) and read those PR descriptions too if needed. - Compare the PR's diff against its merge base (`git diff $(git merge-base origin/ HEAD) HEAD -- `) to see which side introduced an intentional change vs. which side carried stale code. - - Only then choose the correct resolution. If the PR deliberately changed a line and main still has the old version, keep the PR's version. If main introduced a fix the PR doesn't have, keep main's version. + - Only then choose the correct resolution. If the PR deliberately changed a line and main still has the old version, keep the PR's version. If main introduced a fix or new feature the PR doesn't have, keep main's version. If both sides made intentional changes, merge them together manually. 3. After resolving, stage the resolved files by name (not `git add .`), commit with: `fix: resolve merge conflicts with ` 4. Push the updated branch.