Analyzes branch changes to generate a comprehensive and ready-to-paste GitHub PR description.
Install
mkdir -p .claude/skills/pr-mlrun && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/11882" && unzip -o skill.zip -d .claude/skills/pr-mlrun && rm skill.zipInstalls to .claude/skills/pr-mlrun
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Analyze branch changes and generate a fully filled PR description ready to paste into GitHubKey capabilities
- →Gather Git context including diffs and commit list
- →Analyze diff for changed components and templates
- →Detect potential breaking changes like renamed keys or port changes
- →Provide an optional PR title following a specific format
- →Fill a structured PR template with concrete details
How it works
The skill gathers Git context, analyzes the diff for changes and potential breaking changes, and then fills a structured PR template with concrete information, marking checklist items based on diff confirmation.
Inputs & outputs
When to use pr
- →Generate PR description for a feature
- →Detect potential breaking changes in a PR
- →Format PR metadata for GitHub
About this skill
Analyze the current branch changes and generate a fully filled PR description ready to paste into GitHub.
Steps
-
Gather context — run these in parallel:
git diff upstream/development...HEAD— full diff against the base branchgit log upstream/development..HEAD --oneline— commit listgit diff upstream/development...HEAD --name-only— changed files
-
Analyze the diff carefully:
- What components or templates were changed? (check which
templates/subdirs,values.yamlsections,requirements.yaml,Chart.yaml) - Were any new values keys added? Do they need to be reflected in the three install-mode values files?
- Were any Secrets, ConfigMaps, or port numbers changed? (potential breaking changes)
- Was
Chart.yamlversion bumped? If not, flag it. - Were
requirements.yamlorrequirements.lockchanged? - Does
charts/mlrun-ce/README.mdneed updating (new NodePort, new component, new install step)?
- What components or templates were changed? (check which
-
Detect breaking changes — flag as breaking if any of:
- A value key was renamed or removed
- A Secret or ConfigMap name changed
- A NodePort number changed
- A sub-chart was upgraded with a major version bump
- The storage credentials structure changed
- Any hook annotation or hook-weight changed in a way that affects upgrade order
-
Provide an optional PR title following the
[Scope] descriptionformat, where Scope is one of:['feature', 'fix', 'docs', 'improvement', 'revert', 'breaking', 'ci']. For example:[Feature] Add Redis support to mlrun-ce. -
Fill the PR template — produce the complete filled template below. Be specific and concrete; do not use placeholder text.
Apply these checklist rules before writing the output:
[x]— you can confirm this item is satisfied from the diff alone[ ]— requires human action, judgment, or external system access
Specific rules:
- "tested" → always
[ ] - "documentation PR" → always
[ ] - "QA tests / Jira ticket" → always
[ ] - "installation verified" → always
[ ] Chart.yamlversion bump →[x]if diff shows version changed, otherwise[ ]and add to Warnings- Multi-namespace values files →
[x]if all three are in the diff OR the change has no effect on install-mode values;[ ]with a note if a new value was added only tovalues.yaml - README update →
[x]ifcharts/mlrun-ce/README.mdis in the diff OR no new NodePorts/components were added; otherwise[ ]
Output exactly this structure with real content (no placeholder text):
### 📝 Description
<2-4 sentences: what changed, why, and what it affects>
---
### 🛠️ Changes Made
<concrete bullet list — file paths, value keys, resource names>
---
### ✅ Checklist
- [ ] I have tested the changes in this PR
- [ ] I confirmed whether my changes require a change in documentation and if so, I created another PR in MLRun for the relevant documentation.
- [ ] I confirmed whether my changes require changes in QA tests, for example: credentials changes, resources naming change and if so, I updated the relevant Jira ticket for QA.
- [ ] I increased the Chart version in `charts/mlrun-ce/Chart.yaml`.
- [ ] I confirmed that the installation works both on a local Docker Desktop environment and on a real cluster when using the required [prerequisites](https://docs.mlrun.org/en/stable/install-mlrun-ce/kubernetes-install.html#prerequisites).
- [ ] If installation issues were found, I updated the relevant Jira ticket with the issue and steps to reproduce, or updated the prerequisites documentation if the issue is related to missing or outdated prerequisites.
- [ ] If needed, update https://github.com/mlrun/ce/blob/development/charts/mlrun-ce/README.md with the relevant installation instructions and version Matrix.
- [ ] If needed, update the following values files for multi namespace support:
- [ ] [Admin values](https://github.com/mlrun/ce/blob/development/charts/mlrun-ce/admin_installation_values.yaml)
- [ ] [User values Node Port](https://github.com/mlrun/ce/blob/development/charts/mlrun-ce/non_admin_installation_values.yaml)
- [ ] [User values ClusterIP](https://github.com/mlrun/ce/blob/development/charts/mlrun-ce/non_admin_cluster_ip_installation_values.yaml)
---
### 🧪 Testing
<what was tested: lint, helm template dry-run, Kind cluster, manual — based on nature of changes>
---
### 🔗 References
- Ticket link:
- External links:
- Design docs links (Optional):
---
### 🚨 Breaking Changes?
- [ ] Yes (explain below)
- [ ] No
<if breaking: bullet list of what downstream consumers must change — value keys to rename, Secrets to recreate, ports to update>
---
### 🔍️ Additional Notes
<follow-up tasks, known issues, affected areas — omit if nothing to add>
Then replace each [ ] with [x] on items you can confirm from the diff, following the rules above.
After outputting the filled template, add a short "Warnings" section (outside the template) listing anything that needs human attention before opening the PR (missing version bump, unsynced values files, potential breaking changes, etc.).
Between every sentence that ends with a . add two new lines to make it more readable.
When not to use it
- →When a fully filled PR description is not needed
- →When specific checklist items cannot be confirmed from the diff alone
- →When the user does not want a structured PR template
Limitations
- →Some checklist items always require human action or external system access.
- →The PR title follows a specific `[Scope] description` format.
- →The output structure is exactly the provided markdown template.
How it compares
This skill automates the generation of a detailed and structured GitHub PR description, including breaking change detection and checklist population based on diff analysis, which is more complete than manual PR drafting.
Compared to similar skills
pr side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| pr (this skill) | 0 | 3mo | Review | Intermediate |
| github-contributor | 1 | 2mo | Review | Intermediate |
| open-source-maintainer | 1 | 6mo | Review | Intermediate |
| code-changelog | 0 | 9mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
github-contributor
daymade
Strategic guide for becoming an effective GitHub contributor. Covers opportunity discovery, project selection, high-quality PR creation, and reputation building. Use when looking to contribute to open-source projects, building GitHub presence, or learning contribution best practices.
open-source-maintainer
numman-ali
End-to-end GitHub repository maintenance for open-source projects. Use when asked to triage issues, review PRs, analyze contributor activity, generate maintenance reports, or maintain a repository. Triggers include "triage", "maintain", "review PRs", "analyze issues", "repo maintenance", "what needs attention", "open source maintenance", or any request to understand and act on GitHub issues/PRs. Supports human-in-the-loop workflows with persistent memory across sessions.
code-changelog
bear2u
AI가 만든 모든 코드 변경사항을 reviews 폴더에 기록하고 간단한 HTML 뷰어로 웹 브라우저에서 실시간 확인할 수 있습니다. 매 수정마다 문서가 생성되고 Python 서버로 즉시 확인 가능합니다.
code-review
jonatron55
Instructions for reviewing changes and ensuring quality before completion. Use when asking for a review or before committing changes.
pr
Chemaclass
Push branch and create a GitHub PR following the bashdep PR template
pr
corv89
Commit changes, bump version, update changelog, and open a PR