# GitHub Skill Pack > Source: > Published: 2026-07-26 00:00:00+00:00 Β· 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 ## Testing \`\`\` 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 ` β€” read an issue's content - `gh issue edit --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.