Content
86%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.
The body is highly actionable and token-efficient, delivering repo-specific knowledge (path-filter behavior, cancel-in-progress semantics, drift-guard requirements) alongside exact commands, with local verification and a rerun-failed feedback loop. Its main weaknesses are minor: a redundant Description section that restates the frontmatter and an implicit rather than explicit workflow ordering across the rules.
Suggestions
Remove the "## Description" section, which restates the frontmatter description verbatim in function, and trim rhetorical filler like "Do not waste the tokens or the compute" to push conciseness to a 5.
Make the workflow order explicit — e.g., frame the rules as a sequence (1. check in-progress runs, 2. run the local gradle chain, 3. push, 4. monitor and rerun-failed) so the checkpoints read as an ordered pipeline rather than parallel rules.
Clarify the failure-recovery loop: state that when "gh run view" shows a real (non-flake) failure, the fix should be batched into a single push rather than incremental ones, tying rule 1 and the Monitoring section together.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with non-obvious repo facts (which workflow has which filter, the exact local command chain) with no explanation of concepts Claude already knows, but the "## Description" section ("Guidelines for agents to minimize GitHub Actions compute waste...") duplicates the frontmatter and "Do not waste the tokens or the compute" is trimmable rhetoric — minor instances, matching anchor 4 rather than the fully lean anchor 5. | 4 / 5 |
Actionability | Fully executable, copy-paste-ready commands cover the common cases: "gh run list --branch $(git branch --show-current) --limit 5", "./gradlew spotlessApply spotlessCheck detekt detektTypeResolved assembleDebug test allTests", and "gh run rerun <run_id> --failed", with explicit conditions for each. | 5 / 5 |
Workflow Clarity | An implied sequence exists (check running CI → validate locally → push → monitor) with real checkpoints (local tests gate the push; "gh run view" then rerun-failed forms a feedback loop), but the rules are presented as parallel numbered rules rather than an explicit ordered workflow — clear sequence with minor gaps, matching anchor 4. | 4 / 5 |
Progressive Disclosure | This is a simple skill under 50 lines with no need for external references (no bundle files exist), and the content is well-organized into Rules and Monitoring sections — per the rubric's simple-skill exception this scores 5. | 5 / 5 |
Total | 18 / 20 Passed |