Github Issues
Create, triage, and link GitHub issues and project fields from the agent using MCP read tools and CLI write paths.
Overview
github-issues is an agent skill most often used in Build (also Ship, Grow) that manages GitHub issues and project items via MCP read tools and CLI/REST writes.
Install
npx skills add https://github.com/github/awesome-copilot --skill github-issuesWhat is this skill?
- MCP read surface: issue_read, list_issues, search_issues, and GitHub Projects list/get/write
- Write path via CLI/REST when MCP lacks create/update mutations
- Workflows for labels, assignees, milestones, custom fields, priority, and dates
- Issue linking, dependencies, blocked-by, and blocking relationship management
- Trigger phrases: create an issue, file a bug, request a feature, update issue X
- Documents 5+ MCP read tool families plus CLI/REST for writes
Adoption & trust: 12k installs on skills.sh; 34.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want bugs and features tracked in GitHub but doing issue hygiene manually breaks flow while coding with an agent.
Who is it for?
Solo builders on GitHub who use Copilot-class agents with the GitHub MCP server configured.
Skip if: Jira/Linear-only teams, air-gapped repos without GitHub API access, or orgs that forbid agents from mutating issues.
When should I use this skill?
User asks to create an issue, file a bug, request a feature, update an issue, set priority or dates, link issues, or manage blocked-by/blocking on GitHub.
What do I get? / Deliverables
Issues, labels, project fields, and dependency links stay current in GitHub from natural-language requests like create an issue or set priority on #42.
- Created or updated GitHub issues with labels, assignees, and milestones
- Project board items with custom fields and status updates
- Documented issue links and dependency relationships
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Issue and dependency tracking is anchored at build/pm because that is where specs become actionable tasks during implementation. Subphase pm fits bug reports, feature requests, milestones, assignees, and blocked-by relationships—not code review merges.
Where it fits
Break a spec into labeled issues with milestones before the first implementation PR.
Track release checklist items and blocking defects in a GitHub Project status column.
Convert a user-reported regression into a linked bug issue with assignee and priority field.
How it compares
GitHub-native issue + Projects playbook—not a generic markdown task list skill.
Common Questions / FAQ
Who is github-issues for?
Indie developers and small teams who keep roadmap and bugs in GitHub and want the agent to file and update issues consistently.
When should I use github-issues?
While building (pm/task breakdown), during ship launch prep (tracking release blockers), or in grow/support (customer-reported bugs)—whenever you say create an issue, link issues, or set blocked-by.
Is github-issues safe to install?
It can create and modify repository issues via your credentials; review the Security Audits panel on this page and scope tokens to least privilege.
SKILL.md
READMESKILL.md - Github Issues
# GitHub Issues Manage GitHub issues using the `@modelcontextprotocol/server-github` MCP server. ## Available Tools ### MCP Tools (read operations) | Tool | Purpose | |------|---------| | `mcp__github__issue_read` | Read issue details, sub-issues, comments, labels (methods: get, get_comments, get_sub_issues, get_labels) | | `mcp__github__list_issues` | List and filter repository issues by state, labels, date | | `mcp__github__search_issues` | Search issues across repos using GitHub search syntax | | `mcp__github__projects_list` | List projects, project fields, project items, status updates | | `mcp__github__projects_get` | Get details of a project, field, item, or status update | | `mcp__github__projects_write` | Add/update/delete project items, create status updates | ### CLI / REST API (write operations) The MCP server does not currently support creating, updating, or commenting on issues. Use `gh api` for these operations. | Operation | Command | |-----------|---------| | Create issue | `gh api repos/{owner}/{repo}/issues -X POST -f title=... -f body=...` | | Update issue | `gh api repos/{owner}/{repo}/issues/{number} -X PATCH -f title=... -f state=...` | | Add comment | `gh api repos/{owner}/{repo}/issues/{number}/comments -X POST -f body=...` | | Close issue | `gh api repos/{owner}/{repo}/issues/{number} -X PATCH -f state=closed` | | Set issue type | Include `-f type=Bug` in the create call (REST API only, not supported by `gh issue create` CLI) | **Note:** `gh issue create` works for basic issue creation but does **not** support the `--type` flag. Use `gh api` when you need to set issue types. ## Workflow 1. **Determine action**: Create, update, or query? 2. **Gather context**: Get repo info, existing labels, milestones if needed 3. **Structure content**: Use appropriate template from [references/templates.md](references/templates.md) 4. **Execute**: Use MCP tools for reads, `gh api` for writes 5. **Confirm**: Report the issue URL to user ## Creating Issues Use `gh api` to create issues. This supports all parameters including issue types. ```bash gh api repos/{owner}/{repo}/issues \ -X POST \ -f title="Issue title" \ -f body="Issue body in markdown" \ -f type="Bug" \ --jq '{number, html_url}' ``` ### Optional Parameters Add any of these flags to the `gh api` call: ``` -f type="Bug" # Issue type (Bug, Feature, Task, Epic, etc.) -f labels[]="bug" # Labels (repeat for multiple) -f assignees[]="username" # Assignees (repeat for multiple) -f milestone=1 # Milestone number ``` **Issue types** are organization-level metadata. To discover available types, use: ```bash gh api graphql -f query='{ organization(login: "ORG") { issueTypes(first: 10) { nodes { name } } } }' --jq '.data.organization.issueTypes.nodes[].name' ``` **Prefer issue types over labels for categorization.** When issue types are available (e.g., Bug, Feature, Task), use the `type` parameter instead of applying equivalent labels like `bug` or `enhancement`. Issue types are the canonical way to categorize issues on GitHub. Only fall back to labels when the org has no issue types configured. ### Title Guidelines - Be specific and actionable - Keep under 72 characters - When issue types are set, don't add redundant prefixes like `[Bug]` - Ex