gh-create-issue

Use when user wants to create a GitHub issue for the current repository. Must read and follow the repository's issue template format.

Quality

74%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/gh-create-issue/SKILL.md

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a strong instruction-only skill body: concrete executable commands at every step, a well-gated workflow with an eligibility check and a confirmation checkpoint, and a properly factored one-level reference. Its only real weakness is minor redundancy between Steps 4 and 5 and the absence of a post-creation verification step.

Dimension	Reasoning	Score
Conciseness	The body is command-first with almost no padding — even the multi-paragraph eligibility prose teaches non-obvious, task-specific facts (the collaborators endpoint returning 204 for read-only access) rather than concepts Claude already knows. It is not a 5 because the temp-file creation and body-building instructions are stated twice, in Step 4 and again in Step 5, and could be merged.	4 / 5
Actionability	The permission-check bash block, mktemp heredoc pattern, and all three gh issue create variants (base, --label, --type) are copy-paste executable, and cleanup is included; the placeholder text is justified because templates are deliberately repo-sourced rather than hardcoded, which the Notes section explicitly requires.	5 / 5
Workflow Clarity	The five-step sequence is clear with real checkpoints: an eligibility gate before collecting information, 'If unclear, ask the user' rather than defaulting, and a preview-and-confirm step before creating the issue. It stops short of 5 only because there is no verification after creation (e.g., checking the returned issue URL or handling gh errors).	4 / 5
Progressive Disclosure	The single bundle file references/engineering-task.md exists, is linked with a clear markdown reference in both Step 2 and the Notes, and sits exactly one level deep; the Engineering Task specifics (prefix, labels, type, body structure) are appropriately split out of SKILL.md, and section headers make the body easy to navigate.	5 / 5
	Total	18 / 20 Passed

Description

62%Weight 40%Scale 1-5

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 is clear and correctly structured — explicit 'Use when' trigger, distinct GitHub-issue niche, no fluff — but it is thin: only two concrete actions and a narrow set of trigger phrases, leaving it short of the good examples' level of coverage. It would benefit most from naming the template-driven workflow (selecting bug/feature/question templates) and more natural user phrasings.

Suggestions

Add 1-2 more concrete actions to raise specificity, e.g. 'Selects the matching issue template (bug report, feature request, question), fills its required fields, and creates the issue with the template's title prefix, labels, and type via gh.'

Broaden trigger terms with natural synonyms users actually say: 'file an issue', 'open an issue', 'report a bug', 'request a feature', 'create an issue on GitHub'.

State the 'what' more fully up front (template detection, field collection, preview-and-confirm, gh issue create) so the description reads as capabilities followed by the trigger, matching the strongest good examples.

Dimension	Reasoning	Score
Specificity	Names the domain ('create a GitHub issue for the current repository') plus one constraint ('read and follow the repository's issue template format'), but stops at two actions without covering template selection, labels, or issue types — matching the '1-2 concrete actions, not comprehensive' anchor rather than the 'several specific actions' level above.	3 / 5
Completeness	Explicit 'Use when user wants to create a GitHub issue for the current repository' answers when, and 'create a GitHub issue... follow the repository's issue template format' answers what — both present, but the what is a single thin clause, so it falls short of the 'clearly and explicitly answers both with concrete trigger phrases' anchor 5.	4 / 5
Trigger Term Quality	'create a GitHub issue' and 'issue template' are natural phrases users would say, but common variations like 'file an issue', 'open an issue', 'report a bug', or 'feature request' are absent, so keyword coverage has gaps rather than being merely missing a few (level 4).	3 / 5
Distinctiveness Conflict Risk	'GitHub issue' and 'issue template' carve a clear niche that is unlikely to fire for unrelated skills, with only minor overlap risk against adjacent gh-CLI or pull-request skills; not 5 because the description does not sharpen the boundary against those neighbors.	4 / 5
	Total	14 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: CherryHQ/cherry-studio
Path: .agents/skills/gh-create-issue/SKILL.md
Commit: 113ef7e

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.