How do I install the Github Issues skill?

Run npx skillmds@latest add dannote/github-issues 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 Github Issues skill do?

Use gh CLI to view, triage, fix, link, create, or close GitHub Issues. It is listed under Coding & Dev Tools on SkillMD.

Is Github Issues safe to use?

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

Which AI agents work with Github Issues?

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 Github Issues free to use?

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

Who published Github Issues?

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

Github Issues by dannote — Agent Skill

Name: Github Issues
Rating: 4.2 (5 reviews)
Author: dannote

File contents

GitHub Issues Workflow

Markdown bodies: never inline multiline text

Never pass multiline Markdown through --body "...". Shell quoting can leak literal \n into GitHub.

Always write Markdown to a temp file and use --body-file:

cat > /tmp/body.md <<'EOF'
## Summary

- ...

## Tests

- `...`
EOF

gh pr create --body-file /tmp/body.md
# or
gh pr edit <number> --body-file /tmp/body.md
# or
gh issue create --body-file /tmp/body.md

Review handoff

For PR inspection, use the pr-review skill. This skill handles GitHub issue and PR mechanics such as reading templates, using --body-file for multiline Markdown, and checking existing comments before closing or posting.

View issue

gh issue view <number>

Create issue safely

For non-trivial bodies, always write the draft to a temp file first. Do not inline long Markdown with shell quoting.

cat > /tmp/issue.md <<'EOF'
### What happened?

...
EOF

gh issue create --repo OWNER/REPO --title "Short title" --body-file /tmp/issue.md

Before creating issues in someone else's repo, check templates/contributing docs and keep the report concise.

gh api repos/OWNER/REPO/contents/.github/ISSUE_TEMPLATE --jq '.[].name'
gh api repos/OWNER/REPO/contents/CONTRIBUTING.md --jq .content | base64 --decode

If gh issue create prompts for confirmation, review the preview carefully before accepting.

Link issues in commits, changelogs, releases

Commits: fix: description (#1) or fix: description (fixes #1) — auto-closes on merge to default branch
Changelog: ([#1](https://github.com/owner/repo/issues/1))
Release notes: fixes #1 — does NOT auto-close, must close manually

Public replies

Use the maintainer-reply skill before drafting or posting issue and PR replies. Read the conversation first; do not apply a generic thank-you or mention a fix version when it is unknown or irrelevant.

Close with comment

When closing with a reply, mention the fix version when known and thank the reporter when appropriate to the conversation:

gh issue close <number> --comment "Fixed in v1.2.3. Thanks for the report!"

Test fixes before closing

For npm packages, simulate fresh install:

npm pack --pack-destination /tmp/
cd /tmp && mkdir test && cd test
echo '{"name":"test"}' > package.json
bun add /tmp/package-name-1.0.0.tgz
./node_modules/.bin/command --help

---name: github-issuesdescription: Use gh CLI to view, triage, fix, link, create, or close GitHub Issues.--- # GitHub Issues Workflow ## Markdown bodies: never inline multiline text Never pass multiline Markdown through `--body "..."`. Shell quoting can leak literal `\n` into GitHub. Always write Markdown to a temp file and use `--body-file`: ```bash cat > /tmp/body.md <<'EOF' ## Summary - ... ## Tests - `...` EOF gh pr create --body-file /tmp/body.md # or gh pr edit <number> --body-file /tmp/body.md # or gh issue create --body-file /tmp/body.md ``` ## Review handoff For PR inspection, use the `pr-review` skill. This skill handles GitHub issue and PR mechanics such as reading templates, using `--body-file` for multiline Markdown, and checking existing comments before closing or posting. ## View issue ```bash gh issue view <number> ``` ## Create issue safely For non-trivial bodies, always write the draft to a temp file first. Do not inline long Markdown with shell quoting. ```bash cat > /tmp/issue.md <<'EOF' ### What happened? ... EOF gh issue create --repo OWNER/REPO --title "Short title" --body-file /tmp/issue.md ``` Before creating issues in someone else's repo, check templates/contributing docs and keep the report concise. ```bash gh api repos/OWNER/REPO/contents/.github/ISSUE_TEMPLATE --jq '.[].name' gh api repos/OWNER/REPO/contents/CONTRIBUTING.md --jq .content | base64 --decode ``` If `gh issue create` prompts for confirmation, review the preview carefully before accepting. ## Link issues in commits, changelogs, releases - Commits: `fix: description (#1)` or `fix: description (fixes #1)` — auto-closes on merge to default branch - Changelog: `([#1](https://github.com/owner/repo/issues/1))` - Release notes: `fixes #1` — does NOT auto-close, must close manually ## Public replies Use the `maintainer-reply` skill before drafting or posting issue and PR replies. Read the conversation first; do not apply a generic thank-you or mention a fix version when it is unknown or irrelevant. ## Close with comment When closing with a reply, mention the fix version when known and thank the reporter when appropriate to the conversation: ```bash gh issue close <number> --comment "Fixed in v1.2.3. Thanks for the report!" ``` ## Test fixes before closing For npm packages, simulate fresh install: ```bash npm pack --pack-destination /tmp/ cd /tmp && mkdir test && cd test echo '{"name":"test"}' > package.json bun add /tmp/package-name-1.0.0.tgz ./node_modules/.bin/command --help ```

Frequently asked questions

Github Issues