Description de PR TDAH
Format de corps de PR par défaut pour ce dépôt. Les relecteurs doivent finir la description en un coup d'œil. Le diff est déjà sur GitHub — ne reformulez pas les déplacements de fichiers.
Agents : chargez cette compétence à chaque fois que vous rédigez ou réécrivez une description de PR Nakama (y compris via ce-commit-push-pr). La structure du corps provient d'ici ; collectez toujours les affirmations réelles du diff (résultat, risque, ce que vous avez vérifié).
Structure (obligatoire)
## Résumé
<une ligne : qui fait quoi → résultat. Pas de brouillard de jargon sauf si le changement est du jargon.>
**Avant :** <une ligne — ancien comportement ou coût>
**Après :** <une ligne — nouveau comportement ; nommez la fonction/le chemin clé si cela aide pour le risque>
Pourquoi c'est sûr :
1. <raison>
2. <raison>
3. <raison> <!-- 2–3 éléments maximum ; supprimez #3 si rien à dire -->
Ne réintégrer / suivre que si <un risque résiduel ou déclencheur de rollback>.
## Plan de test
- [x] <commande déjà exécutée> (<N> succès)
- [ ] <une vérification manuelle qu'un humain peut faire en <2 min>
Optionnel après le plan de test (gardez si le workflow attend des badges Compound Engineering) :
---
[](https://github.com/EveryInc/compound-engineering-plugin)
Règles
- Le résultat en premier. La première ligne du résumé est le nouveau monde, pas « Cette PR supprime… ».
- Avant/Après = deux lignes. Étiquettes en gras. Pas de paragraphes les entourant.
- Pourquoi c'est sûr = numéroté, ≤3. Maximum 5 puces au total dans le corps ; si plus, ne gardez que celles qui changent la décision.
- Un résiduel. Nommez le cas qui vous ferait annuler cette modification. Sautez s'il n'y en a vraiment aucun.
- Pas de tourisme dans le diff. Ne listez pas les fichiers, le nombre de lignes comme récit, ou « aussi nettoyé les exports » sauf si cela est le risque.
- Plan de test = exécutable. Préférez les commandes cochées avec comptages ; une sonde manuelle non cochée.
- Le titre reste conventionnel.
type(scope): impératif— court. Le corps porte cette structure ; le titre n'a pas besoin d'émoji ou d'essai. - Appliquer avec
gh. Écrivez le corps dans un fichier temporaire ;gh pr edit <n> --body-file …ough pr create --body-file …. Jamais--body "$(cat …)".
Exemple en or
Respectez cette densité :
## Résumé
Approuver une proposition de mémoire d'organisation → la puce va dans `MEMORY.md`. Aucun appel LLM.
**Avant :** fusion déterministe, puis réécriture facultative du modèle du fichier entier.
**Après :** fusion déterministe uniquement (`applyApprovedOrgMemoryBullet`).
Pourquoi c'est sûr :
1. La déduplication + la suppression sont déjà actives dans cette fonction
2. Le chemin LLM a déjà échoué vers le résultat déterministe
3. −230 lignes, même résultat d'approbation
Ne réintégrer une réécriture LLM que si des puces contradictoires survivent à l'approbation.
## Plan de test
- [x] `bun test packages/agent/src` (80 succès)
- [x] `bun test apps/server/src/services/org-memory-service.test.ts` (15 succès)
- [ ] Approuver une proposition en attente (épinglée + journal récent) — la puce atterrit comme avant
Anti-patrons
| À ne pas faire | À faire |
|---|---|
| Résumé en plusieurs paragraphes | Une ligne de résultat + Avant/Après + Pourquoi c'est sûr |
| « Cette PR a pour but de… » / « Afin de… » | Commencez par le verbe ou l'action utilisateur |
### imbriqués sous Résumé | Uniquement ## Résumé + ## Plan de test à plat |
| Reformuler chaque fichier supprimé | Risque résiduel uniquement |
| « Tests passés » vague | Commande exacte + comptage |
Workflow
- Lire le diff / les commits de la PR (
gh pr view,git diff base...HEAD) - Nommer : résultat, avant, après, ≤3 pourquoi c'est sûr, un résiduel
- Remplir le template — coupez toute phrase que le diff prouve déjà
- Appliquer via
--body-file - Répondre avec l'URL de la PR (et « dites si vous voulez que le titre soit resserré » uniquement si utile)