Communitygithub.com

Gentle-IA — Compétence Branche & PR

Gentle-IA configure les agents de codage IA que vous utilisez déjà : Claude Code, Cursor, OpenCode, Codex, Pi, et plus encore. Choisissez la mémoire persistante, le développement piloté par les spécifications, des compétences sélectionnées, des serveurs MCP, des personas, et une revue facultative et limitée. Open source, sans verrouillage agent.

Qu'est-ce que Gentle-IA — Compétence Branche & PR ?

Cette compétence (ou "skill") pour agents IA de codage automatise le workflow de création de branches et de pull requests (PR) sur le dépôt [Gentleman-Programming/gentle-ai](https://github.com/Gentleman-Programming/gentle-ai). Elle est conçue pour être utilisée avec des agents comme Claude Code, Cursor, OpenCode, Codex ou Pi. Le skill impose des règles strictes pour garantir la qualité : chaque PR doit être liée à un issue approuvé (label `status:approved`), doit porter exactement un label de type (`type:bug`, `type:feature`, etc.), et doit respecter un budget de 400 lignes modifiées (sauf dérogation `size:exception` avec justification). Il fournit un modèle de corps de PR, une convention de nommage de branches basée sur les types de Conventional Commits, et vérifie automatiquement le passage des tests unitaires, de formatage Go et des tests E2E via Docker. En utilisant ce skill, un agent peut exécuter de manière fiable le flux complet : vérifier l'issue, créer la branche, implémenter, valider avec des commits conventionnels, ouvrir une PR conforme et s'assurer que toutes les vérifications automatisées passent avant la fusion.

Compatible avec✓Claude Code✓Codex CLI✓Cursor✓OpenCode
npx skills add Gentleman-Programming/gentle-ai
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Gentle IA — Compétence Branche & PR

Quand l'utiliser

Chargez cette compétence chaque fois que vous avez besoin de :

  • Créer une branche pour une nouvelle correction ou fonctionnalité
  • Ouvrir une pull request sur Gentleman-Programming/gentle-ai
  • Préparer des modifications pour une revue

Règles critiques

  1. Chaque PR DOIT lier un issue approuvé — Closes/Fixes/Resolves #<N> dans le corps de la PR, et cet issue DOIT avoir le label status:approved. Les PR sans cela sont automatiquement rejetées par l'IC.
  2. Catégorisation type:* ordinaire — L'IC rejette zéro ou plusieurs labels de type. Acheminez-la via le contrat de workflow de création d'issue canonique : une instruction humaine directe en cours lie la cible/action exacte, la capacité de l'hôte cible est vérifiée, et elle utilise une mutation limitée et une relecture de l'hôte cible ; sinon, attendez sans mutation.
  3. Étiquettes de politique protégées — L'ajout ou la suppression de status:approved ou size:exception nécessite une autorité de politique vérifiée provenant d'un mainteneur du dépôt hôte cible ou d'un approbateur autorisé par le dépôt pour la cible/action exacte, ainsi qu'une viewerPermission MAINTAIN ou ADMIN de l'acteur authentifié sur l'hôte cible. size:exception nécessite en plus une justification écrite de dépassement de budget.
  4. Budget de revue de 400 lignes — maintenez les PR dans 400 lignes modifiées (additions + deletions) ou documentez la justification nécessaire pour un label size:exception.
  5. Les vérifications automatisées doivent réussir — voir le tableau des vérifications automatisées ci-dessous.
  6. Pas de mentions Co-Authored-By — n'ajoutez jamais d'attribution IA aux commits.
  7. Pas de push forcé sur main/master — branche protégée.

Workflow

1. Confirmer que l'issue a le label status:approved
   gh issue view <N> --repo Gentleman-Programming/gentle-ai

2. Créer une branche à partir de main en suivant la convention de nommage ci-dessous

3. Implémenter les modifications selon les specs et la conception

4. Exécuter les vérifications localement (format + unitaires + E2E)

5. Commiter en utilisant le format Conventional Commits

6. Ouvrir une PR en référençant l'issue
   → Déclarer EXACTEMENT UN résultat type:* dans le corps de la PR
   → Utiliser le contrat de workflow de création d'issue canonique avant toute mutation de label de PR
   → Remplir le corps de la PR en utilisant le modèle

7. Toutes les vérifications automatisées doivent réussir avant la fusion

Nommage des branches

Les noms de branche doivent correspondre à ce motif :

^(feat|fix|chore|docs|style|refactor|perf|test|build|ci|revert)\/[a-z0-9._-]+$
TypeExemple
feat/feat/user-login
fix/fix/duplicate-observation-insert
docs/docs/api-reference-update
refactor/refactor/extract-query-sanitizer
chore/chore/bump-bubbletea-v0.26
style/style/fix-linter-warnings
perf/perf/optimize-catalog-loading
test/test/add-pipeline-coverage
build/build/update-goreleaser-config
ci/ci/add-e2e-docker-job
revert/revert/undo-model-picker-change

Règles :

  • Uniquement en minuscules
  • Utilisez des tirets, des points ou des underscores comme séparateurs (pas d'espaces, pas de majuscules)
  • La description doit être courte et descriptive

Format du corps de la PR

Le corps de la PR doit suivre le modèle dans .github/PULL_REQUEST_TEMPLATE.md. Toutes les sections sont obligatoires sauf indication contraire.

## 🔗 Issue lié

Closes #<N>

## 🏷️ Type de PR

- [ ] `type:bug` — Correction de bogue (changement non cassant qui résout un problème)
- [ ] `type:feature` — Nouvelle fonctionnalité (changement non cassant qui ajoute une fonctionnalité)
- [ ] `type:docs` — Documentation uniquement
- [ ] `type:refactor` — Réusinage de code (aucun changement fonctionnel)
- [ ] `type:chore` — Modifications de build, CI ou outillage
- [ ] `type:breaking-change` — Changement cassant

## 📝 Résumé

<!-- Description claire de ce que fait cette PR et pourquoi. -->

## 📂 Modifications

| Fichier / Zone | Quoi de changé |
|-------------|-------------|
| `path/to/file` | Brève description |

## 🧪 Plan de test

**Tests unitaires**
\`\`\`bash
go test ./...
\`\`\`

**Format Go**
\`\`\`bash
go run ./internal/gofmtcheck
\`\`\`

**Tests E2E** (Docker requis)
\`\`\`bash
cd e2e && ./docker-test.sh
\`\`\`

- [ ] Tests unitaires réussissent (`go test ./...`)
- [ ] Format Go réussi (`go run ./internal/gofmtcheck`)
- [ ] Tests E2E réussissent (`cd e2e && ./docker-test.sh`)
- [ ] Testé manuellement en local

## ✅ Liste de vérification du contributeur

- [ ] La PR est liée à un issue avec `status:approved`
- [ ] La PR reste dans 400 lignes modifiées, ou la justification `size:exception` et l'autorité de politique vérifiée sont documentées
- [ ] La relecture de l'API confirme exactement un label `type:*` approprié sur cette PR
- [ ] Tests unitaires réussissent (`go test ./...`)
- [ ] Tests E2E réussissent (`cd e2e && ./docker-test.sh`)
- [ ] J'ai mis à jour la documentation si nécessaire
- [ ] Mes commits suivent le format Conventional Commits
- [ ] Mes commits n'incluent pas de mentions `Co-Authored-By`

Vérifications automatisées

Ces vérifications sont exécutées sur chaque PR et doivent toutes réussir avant la fusion :

VérificationCe qu'elle vérifieComment corriger
Vérifier la charge cognitive de la PRLa PR reste dans 400 lignes modifiées (additions + deletions) ou a le label size:exceptionDivisez la PR, ou documentez la justification size:exception et vérifiez l'autorité de politique avant son action de workflow canonique
Vérifier la référence à l'issueLe corps de la PR contient Closes/Fixes/Resolves #NAjoutez Closes #<N> au corps de la PR
Vérifier que l'issue a status:approvedL'issue lié a le label requisUtilisez le contrat de workflow de création d'issue canonique uniquement lorsqu'une instruction directe en cours et une autorisation de capacité de l'hôte cible autorisent l'action exacte ; sinon, attendez
Vérifier que la PR a un label type:*Exactement un label type:* est appliqué à la PRUtilisez le contrat de workflow de création d'issue canonique uniquement lorsqu'une instruction directe en cours et une autorisation de capacité de l'hôte cible autorisent l'action exacte ; sinon, attendez
Tests unitairesgo test ./... réussitCorrigez les tests qui échouent avant le push
Format Gogo run ./internal/gofmtcheck réussitFormatez les fichiers Go mal formatés avant le push
Tests E2Ecd e2e && ./docker-test.sh réussitCorrigez les scénarios E2E qui échouent avant le push

Conventional Commits

Les messages de commit doivent correspondre à ce motif :

^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\([a-z0-9\._-]+\))?!?: .+

Format

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

[corps optionnel]

[pied de page optionnel]

Types autorisés

TypeObjectifLabel PR
featNouvelle fonctionnalitétype:feature
fixCorrection de boguetype:bug
docsDocumentation uniquementtype:docs
refactorChangement de code (pas de changement de comportement)type:refactor
choreMaintenance, dépendances, outillagetype:chore
styleFormatage, linting (pas de changement de logique)type:chore
perfAmélioration de performancetype:feature
testAjout ou mise à jour de teststype:chore
buildSystème de build ou dépendances externestype:chore
ciConfiguration CItype:chore
revertAnnule un commit précédentcorrespond au type annulé

Changements cassants

Ajoutez ! après le type/scope :

feat(cli)!: renommer le drapeau --config en --config-file

BREAKING CHANGE: le drapeau --config a été renommé en --config-file.

Les changements cassants sont mappés au label type:breaking-change.

Exemples

feat(tui): ajouter une barre de progression aux étapes d'installation
fix(agent): corriger la détection de Claude Code sur macOS
docs: mettre à jour le guide de contribution
chore(deps): mettre à jour bubbletea à v0.26
refactor(pipeline): extraire l'exécuteur d'étape
style: corriger les avertissements du linter dans le paquet catalog
perf(system): mettre en cache le résultat de la détection OS
test(installer): ajouter une couverture pour l'exécution de l'étape catalog
build: mettre à jour la configuration goreleaser pour arm64
ci: diviser les tâches de test unitaire et E2E
revert: annuler la refonte du sélecteur de modèle
feat(cli)!: changer le chemin de configuration par défaut

Commandes

Configuration

# Confirmer que l'issue est approuvé avant de commencer
gh issue view <N> --repo Gentleman-Programming/gentle-ai

# Créer une branche
git checkout main && git pull
git checkout -b fix/<description-courte>

Tests en local

# Tests unitaires
go test ./...

# Format Go
go run ./internal/gofmtcheck

# Tests unitaires — paquet spécifique
go test ./internal/tui/...

# Tests unitaires — verbeux
go test -v ./...

# Tests E2E (Docker doit être en cours d'exécution)
cd e2e && ./docker-test.sh

Ouvrir une PR

gh pr create \
  --repo Gentleman-Programming/gentle-ai \
  --title "fix(agent): corriger la détection de Claude Code sur Linux" \
  --body "$(cat <<'EOF'
## 🔗 Issue lié

Closes #42

## 🏷️ Type de PR

- [x] \`type:bug\` — Correction de bogue (changement non cassant qui résout un problème)

## 📝 Résumé

Corrige la détection du binaire Claude Code qui échoue sur Linux quand HOME n'est pas défini.

## 📂 Modifications

| Fichier / Zone | Quoi de changé |
|-------------|-------------|
| \`internal/agents/claude.go\` | Ajout d'un repli pour la variable d'environnement HOME |

## 🧪 Plan de test

- [x] Tests unitaires réussissent (\`go test ./...\`)
- [x] Tests E2E réussissent (\`cd e2e && ./docker-test.sh\`)
- [x] Testé manuellement en local

## ✅ Liste de vérification du contributeur

- [x] La PR est liée à un issue avec \`status:approved\`
- [x] La PR reste dans 400 lignes modifiées, ou la justification \`size:exception\` et l'autorité de politique vérifiée sont documentées
- [x] La relecture de l'API confirme exactement un label \`type:*\` approprié sur cette PR
- [x] Tests unitaires réussissent (\`go test ./...\`)
- [x] Tests E2E réussissent (\`cd e2e && ./docker-test.sh\`)
- [x] J'ai mis à jour la documentation si nécessaire
- [x] Mes commits suivent le format Conventional Commits
- [x] Mes commits n'incluent pas de mentions \`Co-Authored-By\`
EOF
)"

Vérifier l'état de la PR

gh pr checks --repo Gentleman-Programming/gentle-ai <numéro-PR>
gh pr view --repo Gentleman-Programming/gentle-ai <numéro-PR>

Skills associés

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community