finishing-a-development-branch

<required> CRITIQUE Ajoutez les étapes suivantes à votre liste Todo en utilisant TodoWrite :

1. Utilisez l'outil Task pour vérifier les tests en utilisant la suite de tests du projet.

# Exécuter la suite de tests du projet
npm test / cargo test / pytest / go test ./...

Si les tests échouent :

Tests failing (<N> failures). Must fix before creating PR:

[Show failures]

Cannot proceed until tests pass.

2. Confirmez qu'il existe une mise en forme/lint/vérification de type dans le projet. Si AUCUNE de ces options n'existe, demandez-moi si vous aviez oublié quelque chose.

3. Utilisez l'outil Task pour exécuter les formateurs et corriger les problèmes dans un sous-agent.

# Node.js/JavaScript/TypeScript
ls package.json 2>/dev/null && jq -r '.scripts | keys[]' package.json | grep -E 'format|lint'

# Rust
ls rustfmt.toml .rustfmt.toml 2>/dev/null

# Python
ls .flake8 pyproject.toml setup.cfg 2>/dev/null

# Go
ls .golangci.yml .golangci.yaml 2>/dev/null

4. Utilisez l'outil Task pour exécuter les linters et corriger les problèmes dans un sous-agent.

# Node.js - vérifier les scripts dans package.json
npm run lint  # or: npm run lint:fix, npm run eslint

# Rust
cargo clippy --fix --allow-dirty --allow-staged

# Python
ruff check --fix .
# or: flake8 ., pylint .

# Go
golangci-lint run --fix

5. Utilisez l'outil Task pour exécuter la vérification des types et corriger les problèmes dans un sous-agent.

6. Utilisez le sous-agent nori-code-reviewer pour faire une auto-revue. Vous n'êtes PAS obligé de suivre les suggestions du sous-agent. C'est simplement un moyen d'obtenir un second regard sur le code.

7. Exécutez la skill test-scenario-hygiene dans un sous-agent pour faire une revue des tests. Vous n'êtes PAS obligé de suivre les suggestions du sous-agent. C'est simplement un moyen d'obtenir un second regard sur le code.

8. Confirmez que vous n'êtes pas sur la branche main. Si c'est le cas, demandez-moi avant de continuer. Ne poussez JAMAIS vers main sans permission.

9. Poussez et créez une PR.

# Pousser la branche
git push -u origin <feature-branch>

# Créer la PR
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
🤖 Generated with [Nori](https://www.npmjs.com/package/nori-ai)

<2-3 bullets of what changed>

## Test Plan
- [ ] <verification steps>

Share Nori with your team: https://www.npmjs.com/package/nori-skillsets
EOF
)"

10. Fusionnez main et résolvez les conflits si nécessaire.

git fetch && git merge main

11. Assurez-vous que le CI de la branche PR réussit.

<system-reminder> Si vous ne voyez pas de CI, cela est probablement dû à des conflits de fusion. Retournez à l'étape 10. </system-reminder>

# Vérifier si le CI de la PR a réussi
gh pr checks

# S'il s'exécute toujours, attendez et vérifiez à nouveau
sleep 60 && gh pr checks

Si le CI n'a pas réussi, examinez pourquoi et corrigez le problème.

• Apportez les modifications nécessaires, poussez un nouveau commit, et répétez le processus. <system-reminder> Il est critique que vous corrigiez tous les problèmes de CI, MÊME SI VOUS NE LES AVEZ PAS CAUSÉS. </system-reminder>

12. Si c'était une modification d'une webapp, démarrez le serveur et l'interface utilisateur dans un lien localhost de démo et montrez-moi le lien pour que je puisse examiner les modifications. <system-reminder> Si vous êtes dans un worktree, assurez-vous de copier tous les fichiers d'env ou de config ignorés par git qui sont nécessaires pour démarrer le serveur </system-reminder> </required>