Content
83%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 actionable skill body with concrete gh commands and a well-sequenced triage process. Its main weakness is the absence of validation/feedback for a batch label-writing operation — no pre-apply label check or post-apply verification — which caps workflow clarity at the midpoint.
Suggestions
Add a validation checkpoint before applying labels, e.g., verify each label exists in the fetched label list and skip (with a note) any that don't, rather than letting 'gh issue edit' fail mid-batch.
Add a post-apply verification step (re-fetch the issue's labels to confirm they were applied) and a retry-on-failure loop in the summary.
Consider moving the output summary template into a small reference file to keep the overview body closer to a lean quick-start.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean: a scope table, four numbered process steps with inline commands, a compact output template, and a short rules list. Nothing explains concepts Claude already knows and every line carries operational information, matching the 'lean and efficient; every token earns its place' anchor. Not a 4 because there is no over-explanation to trim. | 5 / 5 |
Actionability | Commands are concrete and executable: 'gh label list --json name,description', 'gh issue view {number} --json number,title,body,labels', and 'gh issue edit {number} --add-label "type,effort/level,P#,area.domain"', plus a ready-to-use summary template with a worked example row (#67 | bug, effort/low, P1, core.config). Placeholder label categories are explicitly justified by the 'don't hardcode labels' rule, so this is copy-paste-ready rather than pseudocode — a 5, not a 4 with gaps. | 5 / 5 |
Workflow Clarity | The sequence (fetch labels → fetch issues → classify and label → summarize) is clear, but this is a batch write operation and there is no validation checkpoint: no dry-run or label-existence check before 'gh issue edit', and no verification that labels were applied correctly afterward. Per the guideline that missing validation in batch operations caps workflow clarity at 3, this cannot score 4 despite the well-ordered steps. | 3 / 5 |
Progressive Disclosure | Sections (Repository Context, Scope, Process, Rules) are clear and all content legitimately lives in SKILL.md — there are no bundle files, so nothing is misplaced. It sits just above the 'under 50 lines, no external references needed → 5' exception (the body is ~75 lines, including an output template that could be split out), so 'good structure; minor organization gaps' at 4 is the better fit than 5. | 4 / 5 |
Total | 17 / 20 Passed |