Content
92%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 tightly written operational skill: exact commands, an explicit gate-then-implement-then-ship workflow with validation and a human-approval checkpoint before any public action, and clean single-file structure. The only weakness is mild redundancy — the fork-remote `gh` warning and a few safety-rule sentences are stated twice.
Suggestions
State the fork-remote/default-repo `gh` warning once (section 2's gate, where the live fetch happens) instead of repeating it in both section 1 and section 2.
Trim restated safety rules — e.g. "No confirmation, no push — ever" duplicates the sentence before it, and "Keep edits minimal and reviewable" overlaps the "Stay narrow... No refactors, no drive-by cleanups" bullet.
Consider collapsing the 'Match the codebase' and 'Stay narrow' bullets in section 3 into one bullet, since both instruct minimal, style-consistent edits.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and operational with no padding about concepts Claude already knows, but it repeats itself in a few places: the fork-remote/`gh` default-repo warning appears in both section 1 ("never bare `gh issue view`, which a fork remote can redirect to the wrong repo's issue") and section 2 ("never rely on `gh`'s default-repo resolution, which a fork remote can redirect to the wrong repo's issue"), and "No confirmation, no push — ever" restates the preceding sentence. These are minor instances of over-explanation that could be trimmed, matching the score-4 anchor rather than the every-token-earns-its-place anchor at 5. | 4 / 5 |
Actionability | Every step is copy-paste ready: the exact `gh api "repos/egamma/vscodesweeper-state/contents/records/..."` fetch command, `gh issue view <issue-number> --repo microsoft/vscode --json state,labels,updatedAt`, `gh search prs ... --json url,title`, the branch convention `<your-github-login>/fix-<issue-number>`, an explicit `git add`-by-path rule, and a full `gh pr create --repo microsoft/vscode --base main --draft ...` command with an ordered PR-body spec. Not below 5 because the only placeholders (<issue-number>, <body>, test command) are inherently per-issue dynamic, not pseudocode. | 5 / 5 |
Workflow Clarity | The sequence is numbered 0–4 with explicit validation checkpoints at every risky boundary: clean-tree and auth preconditions, five live-state gates, a staleness check that asks the maintainer to confirm, a test that must fail before and pass after the fix ("run it both ways and say so"), a mandatory diff-approval pause before any push, and a re-run of gates 2–4 immediately before shipping because "a push is public". This matches the anchor for clear sequence, explicit validation, and error-recovery feedback loops, including for the destructive/public operations the rubric flags. | 5 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are all absent), and none are needed: the body is a single ~75-line linear procedure where every section (preconditions, fetch, gates, implement, safety, ship) is needed on each run, so nothing clearly belongs in a separate file. Sections are clearly headed and easy to navigate, and there are no nested references at all. Not below 5 because the only candidates for extraction (the no-record fallback, the PR-body spec) are short and sit naturally in their workflow steps. | 5 / 5 |
Total | 19 / 20 Passed |