How do I install the Pr Description skill?

Run npx skillmds@latest add input-output-hk/pr-description 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 Pr Description 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 Pr Description?

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 Pr Description free to use?

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

Who published Pr Description?

input-output-hk (@input-output-hk) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pr Description by input-output-hk — Agent Skill

Name: Pr Description
Author: input-output-hk

Pr Description

Generate a PR title and description for cardano-parts releases by analyzing commit diffs on the current branch. Use when the user asks to write, draft, or generate a PR description, release notes, or changelog for this repo.

input-output-hk f6073a1 2 files · 9.5 KB Updated Sep 17, 2026

File contents

Writing PR Descriptions for cardano-parts

Generate a PR title and description following the established pattern used in this repo's release PRs. Output is written to a local pr-description.md file for review, along with a not-included.md file listing minor changes that were intentionally omitted.

Workflow

Ask the user three questions before starting:
- Are there any breaking changes to document? (Usually none.)
- Are there any known issues to document? (Usually none.)
- Are there any additional action items to include in the "Additionally" section (e.g. tofu commands, AMI rebuilds, manual interventions)? (Often none beyond deploying machines.)
- Ask about anything else you're unsure about.
Identify the base branch this PR targets (usually main). Run:
```
git log --oneline main..HEAD
```
Review each commit's diff to understand all changes:
```
git diff main..HEAD
```
For large diffs, review commit-by-commit:
```
git log --oneline main..HEAD
git show <commit-hash>
```
Draft the PR title and description following the format in FORMAT.md.
Write output files:
- pr-description.md — the PR title (as an H1) followed by the full description body
- not-included.md — minor changes you chose to omit (formatting fixes, typo corrections, etc.) so the user can review what was left out

Style Rules

Tense: Use the infinitive ("fix X", "add Y", "bump Z"), not "fixes" or "fixed".
Tone: Short and to the point. Don't be overly wordy — readers will tune out. They can look at the actual changes for details.
Formatting:
- Surround file names and variable names in backticks (e.g. flake/colmena.nix, tcpTxOpt).
- Tables must use actual | and :---: column separators.
- Output must NOT have lines led by two spaces (no indented paragraphs).
- Bold with ** in the version table ONLY for versions that changed from the previous release.
Mithril: The mithril pre-release is almost always bumped and is typically unstable. If there's a problem building the latest unstable, mark it with ** in the table and add a footnote note explaining the workaround.
Omit trivial changes: Don't mention things like "applied nix formatting" or "fixed typo" unless the typo fix was significant (e.g. fixing an important bug from a prior release). List omitted items in not-included.md.
Action items / template files: Every template file modified on this branch should appear in the action items list. Align inline comments using spaces.
Key changes bullets: Each bullet should be a concise summary. Group related changes when it makes sense.

Reference

See FORMAT.md for the exact section structure, table format, and examples drawn from previous PRs.

---name: pr-descriptiondescription: Generate a PR title and description for cardano-parts releases by analyzing commit diffs on the current branch. Use when the user asks to write, draft, or generate a PR description, release notes, or changelog for this repo.---# Writing PR Descriptions for cardano-partsGenerate a PR title and description following the established pattern used in this repo's release PRs. Output is written to a local `pr-description.md` file for review, along with a `not-included.md` file listing minor changes that were intentionally omitted.## Workflow1. **Ask the user** three questions before starting: - Are there any breaking changes to document? (Usually none.) - Are there any known issues to document? (Usually none.) - Are there any additional action items to include in the "Additionally" section (e.g. tofu commands, AMI rebuilds, manual interventions)? (Often none beyond deploying machines.) - Ask about anything else you're unsure about.2. **Identify the base branch** this PR targets (usually `main`). Run: ```bash git log --oneline main..HEAD ```3. **Review each commit's diff** to understand all changes: ```bash git diff main..HEAD ``` For large diffs, review commit-by-commit: ```bash git log --oneline main..HEAD git show <commit-hash> ```4. **Draft the PR title and description** following the format in [FORMAT.md](FORMAT.md).5. **Write output files**: - `pr-description.md` — the PR title (as an H1) followed by the full description body - `not-included.md` — minor changes you chose to omit (formatting fixes, typo corrections, etc.) so the user can review what was left out## Style Rules- **Tense**: Use the infinitive ("fix X", "add Y", "bump Z"), not "fixes" or "fixed".- **Tone**: Short and to the point. Don't be overly wordy — readers will tune out. They can look at the actual changes for details.- **Formatting**: - Surround file names and variable names in backticks (e.g. `flake/colmena.nix`, `tcpTxOpt`). - Tables must use actual `|` and `:---:` column separators. - Output must NOT have lines led by two spaces (no indented paragraphs). - Bold with `**` in the version table ONLY for versions that changed from the previous release.- **Mithril**: The mithril pre-release is almost always bumped and is typically `unstable`. If there's a problem building the latest unstable, mark it with `**` in the table and add a footnote note explaining the workaround.- **Omit trivial changes**: Don't mention things like "applied nix formatting" or "fixed typo" unless the typo fix was significant (e.g. fixing an important bug from a prior release). List omitted items in `not-included.md`.- **Action items / template files**: Every template file modified on this branch should appear in the action items list. Align inline comments using spaces.- **Key changes bullets**: Each bullet should be a concise summary. Group related changes when it makes sense.## ReferenceSee [FORMAT.md](FORMAT.md) for the exact section structure, table format, and examples drawn from previous PRs.

Frequently asked questions