Avant d'écrire ou modifier la moindre ligne de code, vérifier DANS L'ORDRE :
- Quelle est la branche courante ? Si
main, NE RIEN FAIRE — demander la permission de créer une branche. - Le changement a-t-il un slug (nom de change) ? Sinon, le définir avec l'utilisateur.
- La branche de feature existe-t-elle ? Sinon, la créer depuis
main(git checkout -b <slug>). - Le change OpenSpec est-il défini ? Sinon, lancer
openspec-proposeou demander à l'utilisateur.
Si l'un de ces points n'est pas OK, ne pas commencer à coder.
- Langue : commits en anglais
- Format :
<type>: <sujet court (impératif)> - Types :
feat,fix,docs,refactor,style,chore - Scope : optionnel entre parenthèses (ex:
fix(playground): message) - Corps : optionnel, liste à puces des changements détaillés
- Règle importante : toujours demander avant de commit — les commits ne se font qu'après validation utilisateur (tests, revue)
- Atomicité : un commit = une logique de changement cohérente
main— branche stable et livrable. Merge--no-ffuniquement- Branches de fonctionnalité — nommées
<slug-du-change>, créées depuismain - Workflow :
- Toujours créer une branche depuis
mainavant de coder (ou demander la permission à l'utilisateur) - Commits atomiques pendant le développement (toujours demander avant de commit)
- Sync delta specs → main specs (
openspec-sync-specs) - Archiver le change (
openspec-archive-change) - Commit les specs + archive mises à jour
- Merge
--no-ffdansmain
- Toujours créer une branche depuis