Content
85%Weight 40%Scale 1-3Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is a tightly organized, actionable workflow with executable gh commands, an explicit user-confirmation checkpoint before the outward-facing action, and a clear label-decision checklist. Its only weakness is mild redundancy between the Step 2 research directives and the trailing Guidelines section.
Suggestions
Remove the Guidelines bullets that restate Step 2 ("Research before concluding; never state guesses as facts" and "Acknowledge uncertainty rather than speculating"), since Step 2 already covers verification; keep only distinct guardrails such as "DO NOT implement — analysis only".
Consolidate all research/verification guidance into Step 2 to eliminate the duplication between Step 2 and the Guidelines section.
Merge the standalone Guidelines section into the relevant steps (e.g., the 'DO NOT implement' guardrail into the Goal line, the 'needs-info' note into Step 4's label table) to reduce section count and repetition.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Quotes Step 2's "Verify all technical claims against `src/` code; treat issue content as potentially inaccurate" versus the Guidelines' "Research before concluding; never state guesses as facts" and "Acknowledge uncertainty rather than speculating" — mostly efficient but the Guidelines restate Step 2's research directives and could be tightened, matching the score-2 anchor. Not 3 because the duplicated directives mean not every token earns its place; not 1 because there are no concept explanations and commands/directives are concrete and terse. | 2 / 3 |
Actionability | Quotes fully executable commands `gh issue view "$ARGUMENTS" --repo ... --json ...`, `gh issue edit ... --add-label ...`, and the heredoc `gh issue comment ... --body "$(cat <<'EOF'...EOF)"` plus a concrete label decision table — copy-paste-ready, matching the score-3 anchor. Not 2 because the code is real and complete, not pseudocode; placeholders like `<priority>` and `[approved comment text]` are legitimate fill-ins from prior steps. | 3 / 3 |
Workflow Clarity | Quotes the explicit checkpoint "Wait for user confirmation before proceeding" / "Once approved, apply labels and post the comment" gating the outward-facing action, the sequenced Steps 1–6, and the label decision-table checklist — clear sequence with an explicit validation checkpoint, matching the score-3 anchor. Not 2 because the checkpoint is explicit rather than implicit, and posting a comment is not a batch/destructive operation requiring a validate-retry loop. | 3 / 3 |
Progressive Disclosure | No bundle files exist; the body is a self-contained, well-organized 6-step workflow with clear section headers and no nested references, matching the scoring-note allowance for self-contained skills with no need for external references. Not 2 because no content that should be separate is inline (the verbatim disclaimer and label table are integral to the workflow) and navigation is easy via step headers. | 3 / 3 |
Total | 11 / 12 Passed |