Blomios
6969dc7988
Snapshot de l'état runtime accumulé sur develop : logs/handoffs de conversations, layouts, notes mémoire (dont git-owns-commit-merge-decisions) et catalogue de skills. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.4 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| git-owns-commit-merge-decisions | Ne jamais demander a l'utilisateur s'il faut committer/merger/brancher — c'est l'agent Git qui tranche toute la topologie du depot. |
|
Je ne dois PLUS demander a l'utilisateur s'il faut committer, merger, OU gerer les branches (creer/checkout/switch/rebase/supprimer une branche, ni quoi, ni quand). TOUTE la gestion des branches et la topologie du depot est decidee par l'agent Git — c'est LUI qui tranche.
Why: l'utilisateur a explicitement (CLAUDE.md §2.4 + confirme en session le 2026-06-17) defini Git comme garant du depot local : commits, merges, rebases ET toute la gestion de branches sont SA decision, pas celle de Main ni de l'utilisateur. Demander a l'utilisateur court-circuite ce role et le fait perdre du temps.
How to apply: quand un lot est vert, je delegue a Git (idea_ask_agent target=Git) en lui livrant l'etat (fichiers, tests verts, etat de compilation) et c'est Git qui decide/execute commit, merge, ET la branche (creer une feature/*, switch, rebase, supprimer apres merge…). Avant de demarrer une nouvelle feature, je passe la main a Git pour la decision de branche. En cas de doute sur le versioning/branching, je demande a Git, jamais a l'utilisateur. Les actions SORTANTES (push/publication) restent la seule chose soumise a validation explicite de l'utilisateur. Voir session-limit-handling-design.