Créer une Pull Request GitHub

Créez des pull requests sur le repository GitHub NemoClaw en utilisant la CLI gh. Cette skill garantit que chaque PR suit exactement le modèle de PR du projet.

Prérequis

La CLI gh doit être authentifiée (gh auth status).
Vous devez être dans le repository git NemoClaw.
Vous devez avoir des commits sur une branche poussée vers le remote.

Étape 1 : Vérifier l'état de la branche

Avant de créer une PR, vérifiez la branche.

Pas sur main. Ne créez jamais de PRs à partir de main.
```
git branch --show-current
```
La branche a des commits en avant de main.
```
git log main..HEAD --oneline
```
L'arborescence de travail est propre. Stagez ou stashez d'abord les changements non commités.
```
git status
```

Étape 2 : Exécuter les vérifications pré-PR

Exécutez les deux vérifications et confirmez qu'elles réussissent avant de continuer. Ne sautez pas cette étape.

npx prek run --all-files
npm test

Si l'une d'elles échoue, corrigez les problèmes avant de créer la PR.

Étape 3 : Pousser la branche

Assurez-vous que la branche est poussée vers le remote.

git push -u origin HEAD

Étape 4 : Déterminer les métadonnées de la PR

Titre

Les titres de PR doivent suivre le format Conventional Commits :

<type>(<scope>): <description>

Types : feat, fix, docs, chore, refactor, test, ci, perf

Le scope est généralement le nom du composant (par ex. cli, blueprint, plugin, policy, docs).

Exemples :

feat(cli): add offline mode for onboarding
fix(blueprint): prevent SSRF bypass via redirect
docs: update quickstart for Windows prerequisites

Type de changement

Déterminez le type applicable selon le diff :

Changement de code pour une nouvelle fonctionnalité, correction de bug ou refactorisation — la plupart des PRs.
Changement de code avec mises à jour de documentation — code plus changements sous docs/.
Documentation seulement, modifications de prose sans changements d'exemples de code — prose Markdown uniquement.
Documentation seulement, inclut des changements d'exemples de code — changements de documentation qui modifient des blocs de code clôturés.

Issue liée

Vérifiez le nom de la branche et les messages de commit pour les références d'issue. Si une issue existe, utilisez Fixes #NNN ou Closes #NNN.

Signature DCO

Le corps de la PR doit inclure une ligne de signature DCO. Déterminez le nom et l'email de l'utilisateur depuis la config git :

git config user.name
git config user.email

Étape 5 : Composer le corps de la PR

Utilisez la structure de modèle exacte ci-dessous. Remplissez chaque section selon le diff (git diff main...HEAD). Cochez les cases applicables et laissez les autres décochées. N'ajoutez pas, ne supprimez pas et ne réorganisez pas les sections.

## Summary
<!-- 1-3 sentences: what this PR does and why. -->

## Related Issue
<!-- Fixes #NNN or Closes #NNN. Remove this section if none. -->

## Changes
<!-- Bullet list of key changes. -->

## Type of Change
- [ ] Code change (feature, bug fix, or refactor)
- [ ] Code change with doc updates
- [ ] Doc only (prose changes, no code sample modifications)
- [ ] Doc only (includes code sample changes)

## Verification
<!-- Check each item you ran and confirmed. Leave unchecked items you skipped. -->
- [ ] `npx prek run --all-files` passes
- [ ] `npm test` passes
- [ ] Tests added or updated for new or changed behavior
- [ ] No secrets, API keys, or credentials committed
- [ ] Docs updated for user-facing behavior changes
- [ ] `make docs` builds without warnings (doc changes only)
- [ ] Doc pages follow the [style guide](https://github.com/NVIDIA/NemoClaw/blob/main/docs/CONTRIBUTING.md) (doc changes only)
- [ ] New doc pages include SPDX header and frontmatter (new pages only)

---
<!-- DCO sign-off required by CI. Run: git config user.name && git config user.email -->
Signed-off-by: {name} <{email}>

Remplir le modèle

Suivez ces règles pour remplir le modèle :

Summary : Écrivez 1-3 phrases décrivant ce que la PR fait et pourquoi. Dérivez cela des messages de commit et du diff, pas de descriptions génériques.
Related Issue : Incluez Fixes #NNN ou Closes #NNN si une issue existe. Supprimez complètement la section s'il n'y a pas d'issue liée.
Changes : Liste à puces des changements clés. Soyez spécifique — référencez les noms de fichiers, les commandes ou les comportements qui ont changé.
Type of Change : Cochez exactement une case. Utilisez [x] pour coché, [ ] pour décoché.
Verification : Cochez seulement les cases pour les étapes que vous avez réellement exécutées et confirmées réussies. Ne cochez pas les cases pour les étapes que vous avez sautées ou non vérifiées.
DCO Sign-Off : Remplacez {name} et {email} par les valeurs de git config user.name et git config user.email.

Étape 6 : Créer la PR

Utilisez gh pr create avec le drapeau --assignee @me et un HEREDOC pour le corps afin de préserver le formatage.

gh pr create \
  --title "<type>(<scope>): <description>" \
  --assignee "@me" \
  --body "$(cat <<'EOF'
<full PR body from Step 5>
EOF
)"

Labels

Ajoutez des labels le cas échéant :

--label "documentation"   # for doc-only or doc-inclusive PRs
--label "topic:security"  # for security-related changes

PRs en brouillon

Pour un travail en cours qui n'est pas prêt pour la revue :

gh pr create --draft --title "..." --assignee "@me" --body "..."

Étape 7 : Rapporter le résultat

Une fois la PR créée, affichez l'URL de la PR comme un lien markdown cliquable :

Created PR [#NNN](https://github.com/NVIDIA/NemoClaw/pull/NNN)

Erreurs courantes à éviter

N'inventez pas votre propre format de corps de PR. Utilisez exactement le modèle de l'étape 5.
N'omettez pas les sections. Même si une section n'est pas applicable, conservez-la avec le commentaire "Skip if...".
Ne cochez pas les cases pour les étapes que vous n'avez pas exécutées. Si vous n'avez pas exécuté make docs, laissez cette case décochée.
N'oubliez pas la signature DCO. CI rejettera la PR sans elle.
N'oubliez pas --assignee @me. Chaque PR doit être assignée à son créateur.
Ne créez pas de PRs à partir de main. Utilisez toujours une branche de feature.

nemoclaw-contributor-create-pr