gh-issues
Fetch GitHub issues, spawn sub-agents to implement fixes and open PRs, then monitor and address PR review comments. Usage: /gh-issues [owner/repo] [--label bug] [--limit 5] [--milestone v1.0] [--assignee @me] [--fork user/repo] [--watch] [--interval 5] [--reviews-only] [--cron] [--dry-run] [--model glm-5] [--notify-channel -1002381931352]
72
61%
Does it follow best practices?
Impact
100%
2.00xAverage score across 3 eval scenarios
Risky
Do not use without reviewing
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/gh-issues/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description effectively communicates specific capabilities around GitHub issue management and automated PR workflows, with a clear and distinctive niche. However, it reads more like CLI documentation than a skill description, lacking a 'Use when...' clause and natural language trigger terms that users would actually say. The heavy emphasis on flags and options, while informative, comes at the expense of discoverability through natural language queries.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to automatically fix GitHub issues, create pull requests from issues, or manage PR review feedback.'
Include natural language trigger terms users would say, such as 'fix bugs automatically', 'pull requests', 'code review comments', 'automate issue resolution', 'batch fix issues'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: fetch GitHub issues, spawn sub-agents to implement fixes, open PRs, monitor PR review comments, and address review comments. These are clear, actionable capabilities. | 3 / 3 |
Completeness | The 'what' is well covered (fetch issues, implement fixes, open PRs, monitor reviews), but there is no explicit 'Use when...' clause. The 'when' is only implied through the command syntax and flag descriptions rather than stated as explicit trigger guidance. | 2 / 3 |
Trigger Term Quality | Contains good keywords like 'GitHub issues', 'PRs', 'PR review comments', 'bug', 'milestone', 'assignee', and 'fork', but the description is heavily dominated by CLI flag documentation rather than natural language terms users would say. Missing natural phrases like 'fix bugs', 'pull requests', 'code review'. | 2 / 3 |
Distinctiveness Conflict Risk | This skill has a very clear niche: automated GitHub issue triage, fix implementation via sub-agents, and PR lifecycle management. The specific command '/gh-issues' and the detailed flags make it highly distinctive and unlikely to conflict with other skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
55%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is exceptionally thorough and actionable with excellent workflow clarity, validation checkpoints, and concrete executable commands throughout all phases. However, it is severely over-long for a single SKILL.md file — the monolithic structure with repeated token resolution blocks, massive inlined sub-agent prompts, and no progressive disclosure makes it extremely token-inefficient. The content would benefit enormously from being split into a main overview with referenced sub-files for the sub-agent templates, review handling, and cron/watch mode details.
Suggestions
Extract the two large sub-agent prompt templates (fix agent and review agent) into separate files (e.g., FIX_AGENT_PROMPT.md and REVIEW_AGENT_PROMPT.md) and reference them from the main skill.
Consolidate the token resolution logic into a single reusable section referenced by name rather than repeating it 4+ times across the document.
Split Phase 6 (PR Review Handler) into its own referenced file since it's essentially an independent workflow that can run standalone via --reviews-only.
Remove explanations of basic concepts Claude already knows (e.g., HTTPS vs SSH URL format parsing, what git status --porcelain does) to reduce token usage by ~30%.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~600+ lines. Massive amounts of inline detail that could be split into referenced files. The sub-agent prompt templates are enormous and repeated (token resolution appears 4+ times). Much content explains things Claude already knows (how to parse JSON, how git remotes work, HTTPS vs SSH URL formats). The claim-based tracking, cursor file logic, and embedded review parsing are all inlined when they could be separate references. | 1 / 3 |
Actionability | Highly actionable with concrete, executable curl commands, git commands, and specific API endpoints. Every step includes copy-paste ready code with proper headers, URL patterns, and error handling. The sub-agent prompts are fully specified with real commands rather than pseudocode. | 3 / 3 |
Workflow Clarity | Excellent multi-phase workflow with clear sequencing (6 phases), explicit validation checkpoints (token verification, remote access checks, existing PR detection, claim-based dedup, dirty tree warnings), and error recovery paths (retry logic in tests, timeout handling, watch mode loops). Feedback loops are well-defined throughout. | 3 / 3 |
Progressive Disclosure | Monolithic wall of text with no bundle files or external references. The entire skill is one massive document. Sub-agent prompt templates (which are substantial) are inlined rather than referenced. The review handler logic, claim tracking, and cursor management could all be separate files. No bundle files are provided to support this content. | 1 / 3 |
Total | 8 / 12 Passed |
Validation
63%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 7 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (866 lines); consider splitting into references/ and linking | Warning |
metadata_version | 'metadata.version' is missing | Warning |
metadata_field | 'metadata' should map string keys to string values | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 7 / 11 Passed | |
- Repository
- Hung-Reo/hungreo-openclaw
- Commit
a5bf5e0
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.