resolving-merge-conflicts

适用于需要解决正在进行的 git merge/rebase 冲突时。

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/engineering/resolving-merge-conflicts/SKILL.md

Quality

Content

78%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is an exemplary lean, well-sequenced workflow that respects the token budget and encodes strong judgment (preserve both intents, never invent behavior, never abort). Its main gap is actionability: it never names the concrete git commands that execute each step, and the validation loop could make the re-run-after-fix cycle explicit.

Suggestions

Embed the key commands inline, e.g. step 1: `git status` / `git log --merge --oneline`, step 5: `git add -A && git commit` or `git rebase --continue`, so each step is directly executable.

Make the step-4 validation loop explicit: run checks → if failures, fix → re-run until green → only then stage and complete, mirroring the 'validate, fix, re-validate' pattern.

Dimension	Reasoning	Score
Conciseness	The body is ~15 lean lines: a five-step workflow with no padding and no explanation of git concepts Claude already knows. Every instruction adds information (e.g., "不要发明新行为", "不要 --abort"), matching 'Lean and efficient; assumes Claude's competence'.	5 / 5
Actionability	Steps give concrete direction (read commit messages/PRs/tickets, preserve both intents, run typecheck/tests/format, fix merge-introduced issues) but no executable commands — there is no `git status`, `git diff`, `git checkout --conflict`, or `git rebase --continue` anywhere. This sits between 'Some concrete guidance but incomplete' (3) and 'Mostly executable guidance' (4): the procedure is specific, yet the actual commands to run are missing.	3 / 5
Workflow Clarity	A clear five-step sequence runs from inspecting state, through understanding and resolving each hunk, to running automated checks and fixing issues before completing the merge/rebase — a real validation checkpoint. Not 5 because re-running checks after fixes is only implicit, and there is no explicit check that no conflict markers or unmerged files remain before staging.	4 / 5
Progressive Disclosure	This is a simple, under-50-line single-purpose skill with no bundle files (references/, scripts/, assets/ do not exist) and no content that belongs in separate files; the numbered workflow is well-organized and self-contained, which the rubric's simple-skill guideline says can score 5.	5 / 5
	Total	17 / 20 Passed

Description

56%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description has a clear, natural trigger ('in-progress git merge/rebase conflicts') and a distinct niche, but it is essentially a bare 'Use when' clause: it names the domain without stating what the skill actually does. Adding a concise capability statement (e.g., how conflicts are resolved and verified) would raise both specificity and completeness.

Suggestions

Add a short capability statement before the trigger clause, e.g. 'Resolves git merge/rebase conflicts by tracing each change to its original intent, preserving both sides where compatible, and verifying with the project's automated checks.'

Include natural trigger variations such as 'merge conflict', 'conflict markers (<<<<<<< ======= >>>>>>>)', and 'unmerged paths' so users phrasing the problem differently still match.

State the outcome explicitly (e.g., 'completes the merge/rebase, never aborts') so the 'what' is not left entirely implicit.

Dimension	Reasoning	Score
Specificity	The description names the domain ("git merge/rebase 冲突" — git merge/rebase conflicts) but states no concrete capabilities or actions the skill performs. It matches the anchor 'Names the domain but actions are minimal or generic' rather than level 3, which requires 1-2 distinct named actions.	2 / 5
Completeness	The 'when' is explicit ("适用于…时" — applies when…), but the 'what' is only weakly implied inside the trigger clause; the skill's actual capabilities (analyzing conflict sources, preserving both intents, running checks) are never stated. Not 4 because the anchor there requires both a clear 'what' and 'when'; not 2 because an action (resolve conflicts) is conveyed alongside the explicit trigger.	3 / 5
Trigger Term Quality	Terms like "git", "merge", "rebase", and "冲突" (conflict) are exactly what users say when they hit conflicts, giving good keyword coverage. It falls short of 5 because common variations such as 'merge conflict' as a phrase, 'conflict markers', or 'unmerged paths' are absent.	4 / 5
Distinctiveness Conflict Risk	"正在进行的 git merge/rebase 冲突" (in-progress git merge/rebase conflicts) carves out a clear niche with distinct triggers and minimal conflict risk. It is not 5 because there is minor overlap risk with a general git-operations skill.	4 / 5
	Total	13 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: vinvcn/mattpocock-skills-zh-CN
Path: skills/engineering/resolving-merge-conflicts/SKILL.md
Commit: 3f92a83

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.