Content
81%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, highly actionable workflow document with explicit sequencing, validation feedback loops, and a real one-level-deep checklist reference. The main improvement opportunities are trimming duplicated trigger/assignee text, making the few abstract steps concrete, and moving the detailed rate-limit policy into a reference file.
Suggestions
Deduplicate redundant text: drop or shorten the 9-bullet trigger list in 'When to use' (it repeats the frontmatter description) and merge the near-identical assignee bullets in step 3 for primary vs sub-issues.
Make abstract steps concrete: replace phrases like 'Prefer root-cause fixes over surface patches' and 'Summarize what changed and why' with specific criteria or a short worked example.
Move the step-4 rate-limit/token-budget policy (~8 bullets of API cost details) into a referenced file (e.g., references/github-api-budget.md) and keep one summary line in SKILL.md.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with project-specific operational knowledge (rate-limit point budgets, cache-reuse rules, exact .tmp/ file naming) that Claude cannot infer, but there are minor trims available: step 3 repeats near-identical assignee sentences for primary and sub-issues, the 9-bullet trigger list in "When to use" duplicates the frontmatter description, and steps 5-6 ("Create actionable todos ordered by dependencies", "Inspect relevant files, tests, and adjacent usage") restate default Claude behavior. This fits anchor 4 (efficient with minor instances that could be trimmed) rather than 3, since the padding is localized and most tokens earn their place. | 4 / 5 |
Actionability | Much of the guidance is concretely executable: the exact PR-body draft path pattern (".tmp/pr-body-issue-123-scope-summary.md"), closing keywords ("closes owner/repo#123" vs "refs owner/repo#123"), the banner format string, and numeric call budgets (~20 MCP reads, ~5 mutations, pause at 30+). It is not a 5 because a few steps remain abstract ("Prefer root-cause fixes over surface patches", "Summarize what changed and why") without concrete examples of the common cases; it is above 3 because the majority of instructions are specific and directly executable. | 4 / 5 |
Workflow Clarity | Ten numbered steps in dependency order with explicit validation checkpoints and feedback loops: step 8 mandates "If checks fail, fix relevant issues and re-run before proceeding", and step 10 requires post-publish verification ("read the PR body back and verify that exactly the issues chosen for closing use a closing keyword"). A checklist asset accompanies the complex process, matching anchor 5 exactly — the destructive/batch cap of 3 does not apply since validation and verification are present. | 5 / 5 |
Progressive Disclosure | Sections are well organized and the single bundle reference, [assets/issue-solving-checklist.md], is a real file, clearly signaled in an Assets section, and exactly one level deep. It is not a 5 because some inline content arguably belongs in a reference file (the 8-bullet rate-limit/token-budgeting policy in step 4) and the ~130-line body is a monolithic instruction sequence rather than an overview pointing to detailed materials; it is above 3 because the structure is good and the reference that exists is clearly signaled. | 4 / 5 |
Total | 17 / 20 Passed |