Content
67%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.
This is a strong, highly actionable skill: it names the exact MCP tool, JQL, custom field IDs, scoring formula, and output templates, and sequences its steps clearly. The main defects are redundancy (the 'Important' section and step 3 repeat and restate earlier content) and the internally contradictory blocker-detection logic in step 3, which is the one place where precise, single-rule guidance is needed. No validation of result completeness (pagination past 50 issues) is a secondary gap.
Suggestions
Rewrite step 3 as one unambiguous rule for detecting 'is blocked by' links (e.g. 'On the task's own issuelinks, a link of type "Blocks" with an inwardIssue means the current task is blocked by that issue') and delete the conflicting alternative phrasings.
Remove or collapse the 'Important' section's repetition of the step 3-4 criteria, keeping only the genuinely new notes (tie-breaking rule and the field-ID portability caveat).
Add a pagination/continuation check for the Jira search (maxResults: 50 with no instruction to page if the epic has more children), so the ROI ranking cannot silently miss tasks.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly efficient (mapping table, templated outputs, tight steps) but includes unnecessary repetition: the 'Important' section restates the step 3-4 filter and blocker-resolution criteria nearly verbatim, the preflight block is generic boilerplate, and step 3 explains the same blocker rule three different ways. This matches 'mostly efficient but some unnecessary explanation that could be tightened'. | 3 / 5 |
Actionability | Guidance is largely executable — exact MCP tool name with parameters, copy-paste JQL, specific custom field IDs, an effort mapping table, and ready output templates. It falls short of 5 because the step 3 blocker-detection logic is stated in three contradictory ways ('the task appears in outwardIssue' vs 'inwardIssue.key matches the current task' vs 'outwardIssue exists and type.outward = "blocks"'), leaving the one genuinely tricky operation ambiguous. | 4 / 5 |
Workflow Clarity | Eight clearly numbered steps in a coherent order (parse key, fetch, analyze blockers, filter, score, present, then context tables), and the preflight dependency check adds an upfront checkpoint. Minor gaps keep it below 5: no handling for results beyond maxResults 50 (silent truncation risk) and the ambiguous blocker logic in step 3. | 4 / 5 |
Progressive Disclosure | No bundle files exist, and the single SKILL.md is well sectioned (Preflight / Inputs / Steps / Important) with one clearly signaled, one-level-deep sibling reference (requirements.json). It sits above 50 lines with some inline boilerplate (the preflight block) and duplicated content that could be trimmed or split, so it matches 'good structure; most content appropriately placed; minor organization gaps' rather than the exemplary 5 anchor. | 4 / 5 |
Total | 15 / 20 Passed |