Notre avis
Analyse les changements de la branche courante par rapport à upstream/development et génère une description de pull request entièrement remplie, prête à coller dans GitHub.
Points forts
- Détecte les changements cassants propres à Helm : clés de values renommées ou supprimées, noms de Secrets/ConfigMaps, numéros de NodePort, montées de version majeure de sous-charts
- Vérifie la cohérence du chart (bump de Chart.yaml, requirements.yaml/lock, mise à jour du README pour les nouveaux NodePorts ou composants)
- Applique des règles explicites pour cocher ou non chaque élément de la checklist, sans texte générique
- Produit une sortie Markdown structurée avec titre au format [Scope] et liste concrète de fichiers et clés modifiés
Limites
- Suppose une branche de base nommée upstream/development et un dépôt de type chart Helm mlrun-ce ; il faut adapter les commandes git ailleurs
- La checklist générée est celle du template MLRun CE, non transposable telle quelle à un autre projet
- Les éléments nécessitant un test réel, une validation QA ou un accès Jira restent systématiquement non cochés, donc une revue humaine demeure nécessaire
À utiliser lorsqu'une branche de chart Helm est prête et qu'il faut rédiger rapidement une description de PR complète avec détection des changements cassants.
À éviter sur un dépôt qui n'est pas un chart Helm ou dont la branche de base ne s'appelle pas upstream/development, ou si vous voulez une description de PR rédigée indépendamment de tout template imposé.
Analyse de sécurité
SûrThe skill only runs read-only git commands (git diff and git log) scoped to a development branch, with no destructive operations, network exfiltration, or sensitive data access. The allowed tools match the declared tools and pose no meaningful execution risk.
Aucun point d'attention détecté
Exemples
Analyze my current branch against upstream/development and write the full PR description, flagging any breaking changes.Look at the diff on this branch and tell me whether Chart.yaml was bumped and whether the README needs updating for the new NodePort.Produce a [Scope] PR title and a filled PR template for these Helm chart changes, with a concrete list of changed values keys.name: pr description: Analyze branch changes and generate a fully filled PR description ready to paste into GitHub allowed-tools: Bash(git diff*) Bash(git log*) disable-model-invocation: false
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.
Architecte Docker Compose
DevOps
Concoit des configurations Docker Compose optimisees.
Rapport de Post-Mortem
DevOps
Rédige des rapports post-mortem d'incidents structurés et blameless.
Créateur de Runbooks
DevOps
Crée des runbooks opérationnels clairs pour les procédures DevOps courantes.