Content
61%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 well-structured, largely actionable skill with a clear process and concrete examples, dragged down by redundancy (the preserve/update rules repeated across four sections) and the absence of a post-apply validation step. Trimming duplication and adding a verification checkpoint plus the apply command would lift it substantially.
Suggestions
State the preserve-template/user-labels and update-skill-labels rules once (e.g., in 'Label Selection Rules') and remove the repetitions in 'Task', 'Label Classification', and 'Notes'.
Add a validation step after applying label changes — e.g., re-fetch the issue's labels to confirm the final state matches the calculated 'Keep/Add/Remove' sets — and provide the executable command for step 7 ('Apply label changes'), such as `gh issue edit $1 --repo $0 --label ...` or the events API call.
Move the three 'Example Scenarios' to a separate reference file (e.g., references/examples.md) or condense them, keeping only one inline to anchor the behavior.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The preserve-template/user and update-skill-labels rules are restated in at least four places ("Task", "Label Classification", "Label Selection Rules" 1-3, and "Notes"), creating noticeable redundancy. However, the content is operational rather than explanatory of known concepts, so it is 'mostly efficient but could be tightened' (anchor 3) rather than the heavily padded anchor 2. | 3 / 5 |
Actionability | The `gh api repos/$0/issues/$1/events` command is copy-paste ready, `gh label list` is named, and the report format and scenarios are concrete. Minor gap: step 7 'Apply label changes to the issue' gives no executable command (e.g., `gh issue edit --label` or the API mutation call), fitting anchor 4 rather than fully copy-paste-ready anchor 5. | 4 / 5 |
Workflow Clarity | The 8-step process is clearly sequenced, but this is a mutating batch operation on an external system (removing/adding labels) and there is no validation or verification step after applying changes (e.g., re-fetching labels to confirm the final state). Per the judging guideline, missing validation in batch/destructive workflows caps workflow clarity at 3; the sequence itself is too well-ordered to merit 2. | 3 / 5 |
Progressive Disclosure | No bundle files exist, and the body has clean, well-labeled sections with consistent structure. At ~135 lines (above the 50-line simple-skill exception) the three lengthy example scenarios (~50 lines) sit inline where a separate reference file would fit, so it lands at anchor 4 ('good structure; minor organization gaps') rather than 5. | 4 / 5 |
Total | 14 / 20 Passed |