# Pr Desc > Write pull request descriptions from local git changes. Use when asked to summarize a branch diff into PR-ready markdown, including goal discovery, breaking-change detection, and template-based formatting. Select base branch as `main`/`master` by default, or `moonbeam-polkadot-stableNNNN` when the user provides a 4-digit release number. Use when this capability is needed. - Skill: `tomevault-io/pr-desc` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/pr-desc` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/pr-desc/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/pr-desc --- # PR Description Writer Follow this workflow to produce a paste-ready PR description. ## 1) Determine base branch 1. Use `moonbeam-polkadot-stableNNNN` when the user explicitly provides a 4-digit number (`NNNN`). 2. Otherwise prefer `main` if it exists, else `master`. 3. Confirm the selected base branch exists locally before diffing. ## 2) Review changes 1. Compute the effective diff against the merge-base with the selected base branch. 2. Read changed files and commit messages as needed to understand intent. 3. Capture concise notes for: purpose, key behavioral changes, testing, migration/ops impact. ## 3) Infer and confirm goal 1. Infer the main goal from the diff. 2. If the goal is ambiguous, propose 2-4 plausible goals and ask the user to choose before drafting the final description. ## 4) Detect breaking changes Check whether changes impact: - Users and integrators (public APIs, RPCs, runtime/extrinsic behavior, storage formats) - External tooling (indexers, SDK assumptions, event formats) - Node operators (CLI flags, defaults, config/env vars, runtime upgrade constraints) If any breaking change exists, start the PR description with exactly: `## :warning: Breaking changes :warning:` Then list the concrete breakage and required migration actions. ## 5) Build description body 1. If `.pr_desc_template.md` exists at repository root, follow its structure, answer only questions/sections that are truly relevant to the current changes, and skip non-relevant prompts. 2. If the template does not exist, write: - Goal of the changes - What reviewers need to know (key implementation decisions, risks, compatibility) Prefer concrete facts from the diff. Avoid vague claims. ## 6) Return copy/paste-ready markdown 1. Return the full PR description inside exactly one fenced code block so the user can copy in one action. 2. If the PR description itself must include fenced code blocks, wrap the outer fence with four backticks and keep inner blocks as three backticks. 3. Do not prepend or append extra prose outside the final block, except a short ambiguity question when clarification is required. ## Quality bar - Be precise and reviewer-focused. - Mention risky areas and migration requirements explicitly. - Keep wording concise; avoid boilerplate. --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/manuelmauro) — claim your Tome and manage your conversions.