Agent-Skills.md

Agent Skills: GitHub Issue Management and Triage

Create, update, query, and comment on GitHub issues using the gh CLI. Use this skill whenever the user wants to file a bug report, create a feature request, update an existing issue, search or list issues, read issue comments, add labels/milestones, or interact with GitHub issues in any way. Also trigger when the user mentions "open an issue", "file a bug", "update issue \#X", "list issues", "check my issues", "add a comment to issue", "close issue", "label issue", or discusses GitHub issue workflows — even if they don't explicitly say "GitHub issue". If the user is working in a git repository and mentions tracking work, reporting bugs, or requesting features, this skill likely applies.

UncategorizedID: warpcode/dotfiles/github-issues

Repository

warpcode/dotfiles
warpcode
22

Install this agent skill to your local

pnpm dlx add-skill https://github.com/warpcode/dotfiles/tree/HEAD/.github/skills/github-issues

Skill Files

Browse the full folder contents for github-issues.

Download Skill

Loading file tree…

.github/skills/github-issues/SKILL.md

Skill Metadata

Name
github-issues
Description
>

GitHub Issue Management and Triage

This skill provides guidelines, procedures, and templates for managing GitHub issues and issue comments.

Prerequisites: This skill requires either the GitHub MCP server or the gh CLI to be available and authenticated. However, this file contains ZERO script or MCP direct references for usage. For execution, refer to the github-cli skill.

1. Safety and Explicit Consent

  • Explicit Approval Gates: ALWAYS present the full proposed content (title, body, labels, assignees, or comment text) to the user for explicit approval before creating or modifying an issue, changing issue metadata, or posting/modifying issue comments.
  • Never Assume Context: Resolve target repository explicitly (current directory, specified <owner>/<repo>, or ask the user if ambiguous).
  • Surgical Updates: When modifying existing issues or comments, make targeted changes strictly to the specified sections; do not overwrite or modify unrelated existing content.

2. Context Gathering & Template Detection

  • Resolve the target repository (<owner>/<repo>).
  • Check for existing repository-specific issue templates:
    • .github/ISSUE_TEMPLATE/*.md
    • .github/ISSUE_TEMPLATE.md
  • If repository templates exist, structure the issue body to match the repository template.

3. Content Structuring & Fallback Templates

If no repository-specific templates exist, use the standard fallback templates located in @templates/:

  • Bug Report: @templates/bug_report.md
  • Feature Request: @templates/feature_request.md
  • Task / Chore: @templates/task_chore.md
  • Question / Discussion: @templates/question_discussion.md
  • Security Vulnerability: @templates/security_vulnerability.md

Structuring Principles

  • Adapt the selected template to the specific task and omit empty/irrelevant sections.
  • The user's input and technical facts are the source of truth.
  • Ensure clear, reproducible descriptions, expected vs actual behavior, and environment/version details where applicable.

4. Issue Comments Guidelines

  • Tone & Style: Strictly neutral, objective, and concise. Avoid conversational filler, subjective praise, emotional preamble, or informal sign-offs.
  • Technical Content: Focus on actionable technical updates, minimal reproduction steps, specific error logs, or concrete proposed fixes.
  • Referencing: Explicitly cross-reference linked pull requests, parent issues, or related tickets (#number or owner/repo#number).
  • Batching & Updates: When posting status updates on ongoing tasks, consolidate updates to avoid comment spamming.