How do I install the Github Pr Describe skill?

Run npx skillmds@latest add iambiswajitsahoo/github-pr-describe in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Github Pr Describe safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Github Pr Describe?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Github Pr Describe free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Github Pr Describe?

IamBiswajitSahoo (@iambiswajitsahoo) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Github Pr Describe by iambiswajitsahoo

Name: Github Pr Describe
Author: IamBiswajitSahoo

Github Pr Describe

Generate a well-structured PR description by analyzing the diff between the PR branch and its base branch, then push it to GitHub. Use when the user wants to describe a PR, generate a PR body, or write a PR summary.

IamBiswajitSahoo c232651 3 files · 6.5 KB Updated Sep 17, 2026

File contents

PR Description Generator

Generate a structured PR description from the diff, then push it to GitHub.

Phase 1 — Validate & gather

If $ARGUMENTS is empty or not a number, ask via AskUserQuestion: "Which PR number would you like me to describe?"

bash "${CLAUDE_SKILL_DIR}/scripts/gather-pr-info.sh" $ARGUMENTS

Returns {repo, metadata, diff: {content, lines, bytes}}. On error, stop.

Edge cases:

diff.lines == 0: "This PR has no commits/changes yet. Nothing to describe." → stop.
diff.lines > 5000: delegate diff analysis to an Agent sub-call to avoid context bloat. Ask it to return a structured per-file summary of changes.
If metadata.body contains ticket links (#123, JIRA-456, issue-tracker URLs), preserve them for the final description.

Phase 2 — Analyze the diff

For every meaningful change (skip whitespace/format-only), extract: files changed, what (added/modified/removed), why, notable implementation details. Group related changes by area (UI, API, tests, config).

Phase 3 — Draft

Load ${CLAUDE_SKILL_DIR}/templates/description.md and follow its section and formatting rules. Key points:

Only include sections that have relevant changes — omit empty sections.
TL;DR table + bullets always come first.
Preserve any ticket/issue links from the existing PR body under **Tickets:** at the top.
Concise but precise — a reviewer should understand the what and why without reading the code.
Never fabricate changes.

Phase 4 — User review

Output the full drafted markdown description as plain text so the user can read it. Then ask via AskUserQuestion: "Ready to push this description to PR #{PR_NUMBER}?" — Post / Edit.

On Edit, apply the user's feedback, re-display, repeat until Post.

Phase 5 — Push

gh pr edit {PR_NUMBER} --body "$(cat <<'EOF'
{FINAL_DESCRIPTION}
EOF
)"

Output the PR URL from metadata.url to confirm.

---name: github-pr-describedescription: Generate a well-structured PR description by analyzing the diff between the PR branch and its base branch, then push it to GitHub. Use when the user wants to describe a PR, generate a PR body, or write a PR summary.---# PR Description GeneratorGenerate a structured PR description from the diff, then push it to GitHub.## Phase 1 — Validate & gatherIf `$ARGUMENTS` is empty or not a number, ask via `AskUserQuestion`: *"Which PR number would you like me to describe?"*```bashbash "${CLAUDE_SKILL_DIR}/scripts/gather-pr-info.sh" $ARGUMENTS```Returns `{repo, metadata, diff: {content, lines, bytes}}`. On `error`, stop.**Edge cases:**- `diff.lines == 0`: "This PR has no commits/changes yet. Nothing to describe." → stop.- `diff.lines > 5000`: delegate diff analysis to an `Agent` sub-call to avoid context bloat. Ask it to return a structured per-file summary of changes.- If `metadata.body` contains ticket links (`#123`, `JIRA-456`, issue-tracker URLs), preserve them for the final description.## Phase 2 — Analyze the diffFor every meaningful change (skip whitespace/format-only), extract: files changed, what (added/modified/removed), why, notable implementation details. Group related changes by area (UI, API, tests, config).## Phase 3 — DraftLoad `${CLAUDE_SKILL_DIR}/templates/description.md` and follow its section and formatting rules. Key points:- Only include sections that have relevant changes — omit empty sections.- TL;DR table + bullets always come first.- Preserve any ticket/issue links from the existing PR body under `**Tickets:**` at the top.- Concise but precise — a reviewer should understand the *what* and *why* without reading the code.- Never fabricate changes.## Phase 4 — User reviewOutput the full drafted markdown description as plain text so the user can read it. Then ask via `AskUserQuestion`: *"Ready to push this description to PR #{PR_NUMBER}?"* — **Post** / **Edit**.On **Edit**, apply the user's feedback, re-display, repeat until **Post**.## Phase 5 — Push```bashgh pr edit {PR_NUMBER} --body "$(cat <<'EOF'{FINAL_DESCRIPTION}EOF)"```Output the PR URL from `metadata.url` to confirm.

Frequently asked questions