Content
53%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 skill body is well-sequenced with concrete scaffolding commands and genuinely useful hook handling, but it under-specifies its own central operation (GitHub MCP issue creation format and dependency encoding) and provides no post-creation validation for the batch operation. The verbatim duplication of the hook protocol across pre/post sections wastes tokens.
Suggestions
Specify the exact GitHub MCP tools to call and provide an issue title/body template, including how dependencies are represented (e.g., "blocked-by" labels or GitHub task-list syntax).
Add post-creation validation for the batch operation: verify each issue was created, report partial failures, and check for existing issues to avoid duplicates on re-run.
Deduplicate the pre/post hook protocol into one shared section (or a references/hooks.md file) instead of repeating ~30 lines verbatim in both check sections.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body contains no concept over-explanation and is procedurally lean, but the entire hook-detection protocol ("Filter out hooks where `enabled` is explicitly `false`", dot-to-hyphen command conversion, optional/mandatory output templates) is repeated verbatim in both Pre-Execution and Post-Execution Checks. This is more than a minor trim, so anchor 4 does not fit; it is actionable instruction rather than padding or known-concept explanation, so anchor 2 does not either. | 3 / 5 |
Actionability | Concrete commands are present (".specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks", "git config --get remote.origin.url") with exact hook output templates, but the core step "use the GitHub MCP server to create a new issue" names no MCP tool, no issue title/body format, and never specifies how "dependency-ordered" is expressed (labels, task lists, or blocked-by links). The missing key details sit in the skill's central operation, which matches anchor 3 rather than anchor 4's "minor gaps". | 3 / 5 |
Workflow Clarity | The sequence (pre-hooks → prerequisites → remote check → issue creation → post-hooks) is clear and includes a pre-flight checkpoint ("ONLY PROCEED TO NEXT STEPS IF THE REMOTE IS A GITHUB URL"), but the batch issue-creation step has no validation or feedback loop — no verify-after-create, no duplicate prevention on re-run, and no partial-failure handling. Per the batch-operation rule, missing validation in this context caps workflow clarity at 3. | 3 / 5 |
Progressive Disclosure | Sections are clearly organized (User Input, Pre-Execution Checks, Outline, Post-Execution Checks) with no nested references and content appropriately self-contained for a ~90-line command skill with no bundle files. It falls short of anchor 5 because the duplicated hook protocol (~two-thirds of the body) would be better consolidated into a single shared section or a reference file, which is a minor organization gap. | 4 / 5 |
Total | 13 / 20 Passed |