GitHub Skill Pack

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.

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, 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.

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.