{"slug": "github-skill-pack", "title": "GitHub Skill Pack", "summary": "GitHub's official command-line tool, the gh CLI, is the foundation of two new skills in a GitHub Skill Pack: github-pr-description, which generates a structured pull request description from a diff and requires user confirmation before running gh pr create, and github-issue-triage, which suggests labels and routing for new issues and shows its reasoning before applying labels. The pack, part of a course on production agent skills engineering, demonstrates the Skill-vs-Tool distinction by having skills call well-defined external tools rather than reasoning in a vacuum.", "body_md": "· Agentic AI · 5 min read\n\n### 📋 Prerequisites\n\n- SQL Skill Pack (previous lesson)\n\n### 🎯 What You'll Learn\n\n- Build a Transformation skill that generates a structured PR description from a diff\n- Build a Decision skill that triages incoming issues by label and routing\n- Use the GitHub CLI (gh) as a skill's bundled command layer\n\n## What This Pack Covers\n\nTwo skills built around the `gh`\n\nCLI, GitHub’s official command-line tool — one that turns a diff into a structured pull request description, and one that triages a new issue into the right label and routing. Both are good examples of a skill whose real work is calling a well-defined external tool (`gh`\n\n) correctly, rather than reasoning in a vacuum — a direct, practical instance of the Skill-vs-Tool distinction from [From Prototype to Production](/courses/production-agent-skills-engineering/prototype-to-production-skills).\n\n## Skill 1: `github-pr-description`\n\n```\n---\nname: github-pr-description\ndescription: Generates a structured pull request description from the current branch's diff, following this project's PR template. Use when the user asks to open a PR, write a PR description, or summarize changes for review.\nmetadata:\n  version: \"1.0.0\"\n---\n\n## Available commands\n\n- `gh pr diff` — view the diff for the current branch's PR (or use\n  `git diff main...HEAD` if no PR exists yet)\n- `gh pr create --title \"...\" --body \"...\"` — open the PR once the\n  description is ready\n\n## Generate the description\n\n1. Review the diff and identify the actual behavior change — not just\n   which files changed, but what's different for a user or a caller.\n2. Write the description using this structure:\n\n   \\`\\`\\` markdown\n   ## What changed\n   <1-3 sentences on the actual change, not a file list>\n\n   ## Why\n   <the motivating reason, if determinable from commit messages or context>\n\n   ## Testing\n   <what was tested, or what should be tested before merge>\n   \\`\\`\\`\n\n3. If the diff touches more than 10 files or spans clearly unrelated\n   changes, note this in the description and suggest the PR may be worth\n   splitting — do not silently write a description that papers over an\n   overly broad change.\n4. Do not run `gh pr create` without the user confirming the description\n   looks right first — draft it, show it, then create only on confirmation.\n```\n\n**Pattern:** Transformation (diff → structured description), with an explicit confirmation constraint before the one genuinely consequential action (`gh pr create`\n\n) — the same non-negotiable-confirmation discipline from [Skill Engineering](/courses/production-agent-skills-engineering/skill-engineering-fundamentals), applied here because opening a PR is visible to a whole team, not something to do speculatively.\n\n## Skill 2: `github-issue-triage`\n\n```\n---\nname: github-issue-triage\ndescription: Triages a new GitHub issue by suggesting labels and routing. Use when a new issue needs categorizing, or when the user asks to triage, label, or route an issue.\nmetadata:\n  version: \"1.0.0\"\n---\n\n## Available commands\n\n- `gh issue view <number>` — read an issue's content\n- `gh issue edit <number> --add-label \"...\"` — apply a label\n\n## Triage rules\n\n- Contains a stack trace, error message, or \"doesn't work\" / \"broken\" /\n  \"crashes\" language → label `bug`\n- Requests new functionality not currently present → label `enhancement`\n- Asks a question without describing a problem or requesting a feature →\n  label `question`, and suggest routing to a discussion forum instead of\n  leaving it open as an issue\n- Mentions a specific version or environment that's older than the\n  currently supported range → add label `needs-info`, and draft a\n  request for the reporter to confirm they're on a supported version\n\nIf an issue matches more than one rule (a bug report that's also\nversion-ambiguous), apply all matching labels rather than picking just one.\n\n## On applying labels\n\nShow the suggested labels and reasoning before running\n`gh issue edit --add-label`. Do not apply labels without confirmation —\nlabel changes are visible to the whole repository and worth a human\ncheck before this skill acts unattended.\n```\n\n**Pattern:** Decision — the correct label depends entirely on what the issue’s content actually says, per the branching-logic pattern from [Skill Design Patterns](/courses/production-agent-skills-engineering/skill-design-patterns).\n\n## Why Both Skills Pause Before the Real Action\n\nNotice both skills draft first and act only on confirmation, even though `gh`\n\nmakes the actual action (`pr create`\n\n, `issue edit`\n\n) trivial to execute. This is deliberate: both actions are *visible* — a PR description or a set of applied labels is something the rest of a team sees immediately, which raises the bar for confirmation compared to, say, a private local file edit. When you build the next few packs in this course, ask the same question each time: is this action visible to other people, and does that change how much confirmation it deserves?\n\n## Testing Both Skills\n\nFor `github-pr-description`\n\n, test against a small, focused diff (should produce a tight description) and a large, sprawling diff touching unrelated areas (should flag the split suggestion, not silently write around it). For `github-issue-triage`\n\n, test against a clear bug report, a clear feature request, a genuinely ambiguous one that could be either, and one matching multiple rules at once — confirm it applies every matching label rather than just the first one it recognizes.\n\n## Summary\n\n`github-pr-description`\n\nis a Transformation skill (diff → structured description) that drafts before acting, using`gh pr diff`\n\nand`gh pr create`\n\n`github-issue-triage`\n\nis a Decision skill applying labels based on issue content, using`gh issue view`\n\nand`gh issue edit`\n\n- Both pause for confirmation before the visible, team-facing action — a deliberate design choice tied to how visible each action is, not just how easy\n`gh`\n\nmakes it to execute - Test triage rules against genuinely ambiguous and multi-match cases, not just the clean examples that make a demo look good\n\nNext, a pack for infrastructure — diagnosing Kubernetes pod failures and reviewing manifests before they’re applied.", "url": "https://wpnews.pro/news/github-skill-pack", "canonical_source": "https://superml.org/tutorials/github-skill-pack", "published_at": "2026-07-26 00:00:00+00:00", "updated_at": "2026-08-01 04:59:39.856810+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents"], "entities": ["GitHub", "gh CLI", "github-pr-description", "github-issue-triage"], "alternates": {"html": "https://wpnews.pro/news/github-skill-pack", "markdown": "https://wpnews.pro/news/github-skill-pack.md", "text": "https://wpnews.pro/news/github-skill-pack.txt", "jsonld": "https://wpnews.pro/news/github-skill-pack.jsonld"}}