GitHub Skill Pack

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.

· Agentic AI · 5 min read 📋 Prerequisites - SQL Skill Pack previous lesson 🎯 What You'll Learn - Build a Transformation skill that generates a structured PR description from a diff - Build a Decision skill that triages incoming issues by label and routing - Use the GitHub CLI gh as a skill's bundled command layer What This Pack Covers Two skills built around the gh CLI, 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 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 . Skill 1: github-pr-description --- name: github-pr-description description: 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. metadata: version: "1.0.0" --- Available commands - gh pr diff — view the diff for the current branch's PR or use git diff main...HEAD if no PR exists yet - gh pr create --title "..." --body "..." — open the PR once the description is ready Generate the description 1. Review the diff and identify the actual behavior change — not just which files changed, but what's different for a user or a caller. 2. Write the description using this structure: \ \ \ markdown What changed <1-3 sentences on the actual change, not a file list Why <the motivating reason, if determinable from commit messages or context Testing <what was tested, or what should be tested before merge \ \ \ 3. If the diff touches more than 10 files or spans clearly unrelated changes, note this in the description and suggest the PR may be worth splitting — do not silently write a description that papers over an overly broad change. 4. Do not run gh pr create without the user confirming the description looks right first — draft it, show it, then create only on confirmation. Pattern: Transformation diff → structured description , with an explicit confirmation constraint before the one genuinely consequential action gh pr create — 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. Skill 2: github-issue-triage --- name: github-issue-triage description: 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. metadata: version: "1.0.0" --- Available commands - gh issue view <number — read an issue's content - gh issue edit <number --add-label "..." — apply a label Triage rules - Contains a stack trace, error message, or "doesn't work" / "broken" / "crashes" language → label bug - Requests new functionality not currently present → label enhancement - Asks a question without describing a problem or requesting a feature → label question , and suggest routing to a discussion forum instead of leaving it open as an issue - Mentions a specific version or environment that's older than the currently supported range → add label needs-info , and draft a request for the reporter to confirm they're on a supported version If an issue matches more than one rule a bug report that's also version-ambiguous , apply all matching labels rather than picking just one. On applying labels Show the suggested labels and reasoning before running gh issue edit --add-label . Do not apply labels without confirmation — label changes are visible to the whole repository and worth a human check before this skill acts unattended. 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 . Why Both Skills Pause Before the Real Action Notice both skills draft first and act only on confirmation, even though gh makes the actual action pr create , issue edit 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? Testing Both Skills For github-pr-description , 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 , 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. Summary github-pr-description is a Transformation skill diff → structured description that drafts before acting, using gh pr diff and gh pr create github-issue-triage is a Decision skill applying labels based on issue content, using gh issue view and gh issue edit - 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 gh makes it to execute - Test triage rules against genuinely ambiguous and multi-match cases, not just the clean examples that make a demo look good Next, a pack for infrastructure — diagnosing Kubernetes pod failures and reviewing manifests before they’re applied.