Content
64%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A solid, practical skill that provides concrete gh CLI commands organized into logical sections. Its main weakness is the duplication of commands between the standalone examples and the debugging workflow, which wastes tokens. Adding a feedback loop (re-run CI, verify fix) to the debugging workflow and removing the redundant standalone command listings would meaningfully improve it.
Suggestions
Remove the standalone PR/run command examples that are duplicated verbatim in the 'Debugging a CI Failure' workflow, or consolidate them into the workflow section only.
Add a verification step to the debugging workflow (e.g., after pushing a fix: 'Re-run the workflow: `gh run rerun <run-id> --repo owner/repo` and re-check with `gh pr checks`').
Show how to capture the run ID from `gh run list` output (e.g., using `--json databaseId --jq`) so the workflow is fully executable without manual lookup.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but has notable redundancy: the individual PR/run commands are listed once as standalone examples and then repeated nearly verbatim in the 'Debugging a CI Failure' workflow section. The introductory 'When to Use' section also restates what the description already conveys. Trimming the duplicated commands would tighten it significantly. | 3 / 5 |
Actionability | All guidance is concrete with copy-paste-ready bash commands and real flags. Minor gaps: placeholder `<run-id>` is used without showing how to capture it from a previous step's output, and there are no examples for `gh issue` or `gh pr create` despite issues being mentioned in 'When to Use'. | 4 / 5 |
Workflow Clarity | The 'Debugging a CI Failure' section provides a clear numbered sequence, but it lacks any validation or feedback loop—there is no step for verifying a fix, re-triggering the run, or confirming the CI passes after changes. For a debugging workflow this omission is notable, though the operation is non-destructive so the cap at 3 is appropriate rather than mandatory. | 3 / 5 |
Progressive Disclosure | The skill is under 50 lines of substantive content, covers a single tool, and has no need for external reference files. Sections are well-organized with clear headers (Pull Requests, Debugging, API, JSON Output), making navigation easy. | 5 / 5 |
Total | 15 / 20 Passed |