How do I install the Create Issue skill?

Run npx skillmds@latest add getnao/create-issue in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Create Issue skill do?

Create GitHub Issue It is listed under Coding & Dev Tools on SkillMD.

Is Create Issue safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Create Issue?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Create Issue free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Create Issue?

getnao (@getnao) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Create Issue by getnao — Agent Skill

Name: Create Issue
Author: getnao

File contents

Create GitHub Issue

Standard process for creating well-structured GitHub issues. Use for bugs, feature requests, and tasks.

MCP connectors

Connector	Purpose
GitHub	Create and label issues

Bug report template

## Problem

[Clear description of what's broken. Include steps to reproduce.]

1. Step one
2. Step two
3. Observe: [what happens]

## Expected behavior

[What should happen instead]

**Environment**: [browser, OS, version, relevant config]

Feature request template

## Problem

[What user problem does this solve? Who is affected?]

## Expected behavior

[What the feature should do, from the user's perspective]

## Notes

[Optional: technical considerations, related issues, mockups]

Labels

Label	When to use
`bug`	Something is broken
`feature`	New functionality request
`enhancement`	Improvement to existing feature
`docs`	Documentation change needed
`good first issue`	Simple, well-scoped, good for new contributors
`priority:high`	Blocks users or causes data issues
`priority:low`	Nice to have, no urgency
`needs-triage`	Needs review before prioritization
`customer-reported`	Came from customer feedback

Process

Check for duplicates - search existing issues before creating
Use the right template - bug report or feature request
Add labels - at least one type label and one priority label
Link related issues - reference with #issue-number if related
Assign - only if the assignee is clear; otherwise leave unassigned

Title format

Bug: [component] Short description of what's broken
Feature: [component] Short description of desired behavior
Docs: docs: Short description of what needs updating

Examples:

[API] Query timeout on large datasets
[Dashboard] Add date range filter to usage chart
docs: Update authentication setup guide

Guardrails

No PII - scrub customer names, emails, and company names from all issue content
One issue per problem - no omnibus issues covering multiple bugs
No Impact section - keep body to Problem + Expected behavior only
No confidential data - no API keys, credentials, or internal URLs in issues
Don't close issues - only the CAO or the assignee closes issues

Self-improvement

After the CAO reviews created issues:

If the CAO edits an issue title, body, or labels before posting, note the pattern
If her edits reveal a preference for how problems are framed, bug reports are structured, or priorities are assigned, update the Templates or Labels sections
Update product/_insights.md with patterns: which issue formats get the fastest triage, which label conventions the team actually uses
If an issue template works particularly well, save it to product/_examples/ as a reference

---name: create-issuedescription: Create GitHub Issue---# Create GitHub IssueStandard process for creating well-structured GitHub issues. Use for bugs, feature requests, and tasks.## MCP connectors| Connector | Purpose ||-----------|---------|| GitHub | Create and label issues |## Bug report template```markdown## Problem[Clear description of what's broken. Include steps to reproduce.]1. Step one2. Step two3. Observe: [what happens]## Expected behavior[What should happen instead]**Environment**: [browser, OS, version, relevant config]```## Feature request template```markdown## Problem[What user problem does this solve? Who is affected?]## Expected behavior[What the feature should do, from the user's perspective]## Notes[Optional: technical considerations, related issues, mockups]```## Labels| Label | When to use ||-------|------------|| `bug` | Something is broken || `feature` | New functionality request || `enhancement` | Improvement to existing feature || `docs` | Documentation change needed || `good first issue` | Simple, well-scoped, good for new contributors || `priority:high` | Blocks users or causes data issues || `priority:low` | Nice to have, no urgency || `needs-triage` | Needs review before prioritization || `customer-reported` | Came from customer feedback |## Process1. **Check for duplicates** - search existing issues before creating2. **Use the right template** - bug report or feature request3. **Add labels** - at least one type label and one priority label4. **Link related issues** - reference with `#issue-number` if related5. **Assign** - only if the assignee is clear; otherwise leave unassigned## Title format- Bug: `[component] Short description of what's broken`- Feature: `[component] Short description of desired behavior`- Docs: `docs: Short description of what needs updating`Examples:- `[API] Query timeout on large datasets`- `[Dashboard] Add date range filter to usage chart`- `docs: Update authentication setup guide`## Guardrails- **No PII** - scrub customer names, emails, and company names from all issue content- **One issue per problem** - no omnibus issues covering multiple bugs- **No Impact section** - keep body to Problem + Expected behavior only- **No confidential data** - no API keys, credentials, or internal URLs in issues- **Don't close issues** - only the CAO or the assignee closes issues## Self-improvementAfter the CAO reviews created issues:1. If the CAO edits an issue title, body, or labels before posting, note the pattern2. If her edits reveal a preference for how problems are framed, bug reports are structured, or priorities are assigned, update the Templates or Labels sections3. Update `product/_insights.md` with patterns: which issue formats get the fastest triage, which label conventions the team actually uses4. If an issue template works particularly well, save it to `product/_examples/` as a reference

Frequently asked questions

Create Issue