PR Description

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Draft a pull request description from the real code changes, then either apply it to an existing PR or help open a new one. This skill never pushes, commits, or opens/edits a PR without the user explicitly confirming the specific action first.

Purpose

iru-pr-description detects which platform hosts the repository — GitHub, Bitbucket, Azure DevOps, or TFS — and uses that platform’s own tooling throughout instead of assuming gh/GitHub. It resolves the base branch the diff is read against — and that a new pull request would target — by inheritance rather than by re-derivation, taking the first of: an explicit base-branch argument (how iru-issue and iru-release hand over the base they already resolved), an iru-issue run earlier in the same conversation, a Base branch: line in the plan’s Task summary (implementation_plan.md, or its archived copy under .archive/, which is what carries the choice across sessions), and only failing all of those, the repository’s own default branch. That ordering is what keeps a PR opened through the iru-issue pipeline pointed at the base the user actually confirmed there, instead of silently describing and targeting a different one. After a cheap stat-only check confirms there’s something to describe, it delegates reading the actual diff for the current branch — commits already ahead of the base branch plus anything staged, unstaged, or untracked — and drafting a brief, concise description grounded in that diff (never invented) to a sub-agent, so the raw diff never has to load into this skill’s own context, only the drafted text. It then checks whether a pull request already exists for the branch, using the tool matching the detected host: if one does, it offers to replace that PR’s body with the draft; if not, it offers to commit, push, and open a new one, asking for a branch name, destination branch, and title (each with an inferred default). Every step that writes to shared state — editing a PR body, committing, pushing, opening a PR — requires the user’s explicit confirmation first; declining always leaves the drafted description as the deliverable.

Purpose group

Pull Request Lifecycle

Invocation

/iru-pr-description
/iru-pr-description base-branch: <branch-name>

Inputs

Argument Required Description Default

base-branch

No

An optional key: value line pinning the branch the diff is read against and that a new pull request would target. This is how Issue (Step 8) and Release (Step 14) hand over a base branch they already resolved and confirmed with the user, so the description isn’t drafted against a different base than the PR actually targets.

Resolved by inheritance instead: an iru-issue run earlier in the same conversation, then a Base branch: line in implementation_plan.md (or its archived copy under .archive/), then the repository’s own default branch (git symbolic-ref refs/remotes/origin/HEAD, falling back to main/master).

(everything else)

—

Nothing else is passed on the command line. The skill derives the current branch’s diff itself, detects the repository host (reusing iru-explore’s detection if it already ran this conversation), and prompts interactively (via `AskUserQuestion) for branch name, destination branch, and PR title only if the user chooses to open a new pull request.

Not applicable.

Outputs

  • A drafted pull request description in the conversation — a short summary, plus a bulleted list of the concrete changes when there is more than one logical change, with sparing emoji categorization and an optional Mermaid diagram (skipped for Bitbucket, which doesn’t render it) when a change reshapes control/data flow enough to warrant one.

  • If an existing PR was found and the user confirmed: the PR’s body is replaced with the draft using the tool matching the detected host (gh pr edit --body-file for GitHub; Bitbucket MCP tools or REST API; az repos pr update or Azure DevOps MCP tools), and its URL is reported.

  • If no PR existed and the user confirmed opening one: a new branch (if needed), a commit, a pushed branch, and a newly opened pull request via the host-matching tool, with its URL reported.

  • If the user declines any action, or no diff exists to describe: no repository or remote-hosting state is changed — the draft (or a "nothing to describe" notice) is the only output.

Execution flow

flowchart TD A[Start /iru-pr-description] --> B["Step 1: Detect repository host\n(GitHub/Bitbucket/Azure DevOps/TFS)"] B --> B2["Step 2: Resolve base branch\n(args, then this conversation's iru-issue run,\nthen the plan's 'Base branch:' line,\nthen the repository default)"] B2 --> C["Step 2: Determine current branch;\ncheck for changes against that base\n(stat only, not full diff)"] C --> D{Any changes to describe?} D -- no --> Z[Tell user, stop] D -- yes --> C2["Step 2: Delegate full diff read\n+ drafting to a sub-agent"] C2 --> E["Step 3: Check whether a PR\nalready exists via the host's own tool"] E --> F["Step 4: Show the drafted\ndescription to the user"] F --> G[Strip/flag Mermaid if host is Bitbucket] G --> H{PR already exists?} H -- yes --> I["Step 5: Show existing body vs draft,\nask to replace"] I -- yes --> J["Edit PR body via host-matching tool"] I -- no --> Y[Stop - draft is the deliverable] H -- no --> K["Step 6: Ask whether to commit,\npush, and open a new PR"] K -- decline --> Y K -- accept --> L["Collect branch name, destination\nbranch, and title via AskUserQuestion"] L --> M["Commit (if needed), push,\ncreate PR via host-matching tool\n(destination defaults to the resolved base,\nnever a claude/* branch)"] J --> N["Step 7: Report outcome"] M --> N

Dependencies

Invokes

None — iru-pr-description is a leaf skill. It only drafts text and, once the user explicitly confirms, runs git and the host-matching tool directly (gh/GitHub MCP tools, Bitbucket MCP tools/REST API, az repos/Azure DevOps MCP tools); it does not call any other skill in this catalog.

Invoked by

  • Issue — Step 8 runs iru-pr-description to fill in the description of the pull request it just opened for the ticket, passing the base branch it resolved and confirmed with the user in its Step 4.2 as a base-branch argument.

  • Release — Step 14 runs iru-pr-description to fill in the description of the release branch’s pull request, passing that PR’s target branch (main/master) as a base-branch argument.

Related agents

  • general-purpose (see Agents) — spawned once in Step 2, given the branch/base-branch names, to read the full diff and recent commit messages and draft the description — so the raw diff stays out of this skill’s own context and only the drafted text comes back. A plain, unnamed sub-agent is used rather than a dedicated custom agent since this is a single, localized delegation, not a shape repeated across several skills the way Gate Runner or Change Summarizer are.

Source

SKILL.md on GitHub — the file this page was generated from.