· 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.
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 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, usinggh pr diff
andgh pr create
github-issue-triage
is a Decision skill applying labels based on issue content, usinggh issue view
andgh issue edit
- Both 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.