Content
93%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A tight, highly executable skill file: concrete commands for every merge scenario, an attribution checklist, and a properly split one-level reference. The only real gap is error recovery in the workflow — post-merge verification (ruff/pytest) runs before `git push origin main` but the file never says what to do when verification fails.
Suggestions
Add an explicit feedback loop after Post-Merge Verification, e.g. 'If ruff or pytest fail, fix in a separate commit (preserving the merge) and re-run before pushing — never push unverified merges to main.'
Explain or reference what `harness-eval` is (step 6 invokes it with no context), or drop it in favor of the concrete ruff/pytest commands already listed.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean: every section (Core Principles, Workflow, Attribution Checklist, Common Pitfalls) carries operational content with no explanations of concepts Claude already knows. Phrases like "Never `git apply` + self-commit — this loses author attribution entirely" state only non-obvious, skill-specific rationale. It is tighter than anchor 4's 'minor instances of over-explanation' — there is nothing to trim. | 5 / 5 |
Actionability | Every step is copy-paste-ready bash: `gh pr list --repo OWNER/REPO --state open --json number,title,author,additions,deletions,mergeable`, `git fetch origin pull/NUMBER/head:pr-NUMBER`, `gh pr diff NUMBER | git apply --exclude='...'` with a full `--author` commit example, and a concrete verification block (ruff, pytest, push). Commands cover the common cases (clean, conflicting, selective, duplicate) completely; not anchor 4 because there are no gaps in executability. | 5 / 5 |
Workflow Clarity | The 6-step sequence (Triage → Merge Clean → Conflicting → Selective → Close → Post-Merge Verification) is explicit and validation exists (ruff/pytest before push, plus the Attribution Checklist 'Before pushing a merged PR'), so the missing-validation cap does not apply. It falls short of anchor 5 because the validate→fix→retry feedback loop is absent: step 6 runs lint and tests but gives no instruction for what to do when they fail before pushing to main — the 'minor validation gaps' of anchor 4. | 4 / 5 |
Progressive Disclosure | The body is a clear operational overview with detailed per-scenario examples correctly split into `references/merge-scenarios.md` (which exists and is one level deep, no nesting). The reference is well signaled: '**`references/merge-scenarios.md`** — Detailed examples for each merge scenario (clean, conflicting, selective, duplicate)'. Navigation is easy and nothing that belongs in the reference file is inlined; matches anchor 5, not anchor 4's 'minor organization gaps'. | 5 / 5 |
Total | 19 / 20 Passed |