GitHub Issue

Use GitHub Issues as a durable record of tracked work. This skill owns GitHub-specific representation and lifecycle: issue creation, body formatting, metadata, relationships, progress updates, and closure. It does not invent the work contract or decide product intent.

For a long conversation, feature dependency, bug observation, or plan requiring semantic consolidation, use work-handoff first. For an already clear user request or an existing issue, this skill can be used directly. Do not require a handoff artifact just to edit a label or close an issue.

First inspect, then mutate

1. Identify the repository and issue. Confirm the owner/repo and the current issue/PR if supplied. Respect repository instructions, issue templates and GitHub permissions; an issue number is not globally unique.
2. Read the current record. For edits, fetch the title, body, state, type, labels, assignees, milestone, organization issue fields, Project membership/field values, relationships and discussion as available. Different metadata may require different permissions and APIs. Read parent and linked issues when they affect a proposed transition. For new issues, search open/closed issues and merged/open PRs for duplicates and already-delivered work.
3. Decide the intended operation. Creating an issue, setting issue metadata, adding a Project item, setting a Project-local field, assigning ownership, changing hierarchy, declaring a dependency, and closing work are distinct actions. Apply only the operations actually requested or clearly supported by project conventions.
4. Use the smallest meaningful GitHub structure. Keep a few local checks in one issue. Create distinct issues only for separately owned, independently trackable outcomes; use real GitHub relationships where warranted.
5. Preserve the authoritative content. Use the agreed handoff/body as the source of what must be done. GitHub fields and links explain tracking, not new requirements. When editing, preserve existing checked boxes, updates, human edits, and verified evidence; do not overwrite concurrent changes from an old snapshot.
6. Execute with an available supported tool. Use authorized GitHub integration, GitHub CLI, or UI. Verify the tool actually supports each operation. Never pretend a Markdown link created a native sub-issue or dependency.
7. Verify and report. Re-fetch created/changed issues and relationships. Return the real issue URL and meaningful metadata or changes made; say exactly what failed or remained unverified. After an ambiguous failure, search before retrying to avoid duplicates.

Choosing the right GitHub construct