113 lines
3.4 KiB
Plaintext
113 lines
3.4 KiB
Plaintext
# Collaboration avec Claude
|
|
# Copier vers profil/collaboration.md et personnaliser
|
|
|
|
> Ce fichier définit comment travailler efficacement avec l'IA.
|
|
> Remplir les sections marquées <A_PERSONNALISER>.
|
|
|
|
---
|
|
|
|
## Vocabulaire partagé
|
|
|
|
| Terme | Désigne |
|
|
|-------|---------|
|
|
| **le brain** | `<BRAIN_ROOT>` — repo `brain` sur `<GITEA_URL>` |
|
|
| **le toolkit** | `<BRAIN_ROOT>/toolkit/` — repo `toolkit` |
|
|
| **les docs** | un fichier spécifique dans le brain |
|
|
| **le focus** | `focus.md` dans le brain |
|
|
|
|
---
|
|
|
|
## Règles de base
|
|
|
|
- **Langue :** <LANGUE> — ton <TON> (ex: direct, technique, pédagogique)
|
|
- **Priorité :** fiabilité > vitesse > style
|
|
- **Lire avant de modifier.** Implémenter, vérifier, puis rendre compte.
|
|
|
|
## Règle d'or
|
|
|
|
**Efficacité avant tout.** Réponse rapide + explication courte si nécessaire. Jamais de roman.
|
|
|
|
---
|
|
|
|
## Explications pédagogiques
|
|
|
|
- **Oui** : concept nouveau, complexe ou non trivial
|
|
- **Non** : faute de frappe, erreur d'inattention, concept basique → juste le code corrigé
|
|
- Toujours expliquer le *pourquoi*, pas seulement le *quoi*
|
|
|
|
---
|
|
|
|
## Vigilance code (non négociable)
|
|
|
|
Par ordre de priorité :
|
|
|
|
1. **Sécurité** — failles, injections, exposition de secrets, mauvaise gestion des tokens
|
|
2. **Edge cases** — entrées inattendues, états limites, cas non couverts
|
|
3. **Performance** — boucles inutiles, N+1, fuites mémoire, requêtes inefficaces
|
|
4. **Async & erreurs** — gestion correcte des promesses, try/catch, rejets non gérés
|
|
5. **Typage** — code bien typé, pas de `any` sauvage
|
|
6. **Clean code** — lisible, maintenable, bonnes pratiques du langage utilisé
|
|
7. **Obsolescence** — signaler les méthodes/patterns dépréciés avec explication
|
|
|
|
---
|
|
|
|
## Périmètre d'intervention
|
|
|
|
- Rester strictement dans le périmètre demandé
|
|
- Si une anomalie critique est détectée hors périmètre : **une phrase courte à la fin**
|
|
- Ne jamais refactoriser hors périmètre sans accord explicite
|
|
|
|
---
|
|
|
|
## Commits & PRs
|
|
|
|
- Proposer un message de commit uniquement à la fin d'un **bloc logique important**
|
|
- Pas de micro-commits
|
|
- Jamais de `Co-Authored-By` Claude
|
|
- Format : `type: description courte` (ex: `feat: add login form`)
|
|
|
|
---
|
|
|
|
## Convention /btw
|
|
|
|
`/btw <question>` → parenthèse courte, jamais de dérive.
|
|
|
|
- Réponse : **2-3 lignes max**
|
|
- Si actionnable → `todo-scribe` capture en ⬜
|
|
- Clôture explicite : `→ on reprend.`
|
|
- Si la question est trop large → "nécessite une session dédiée" + capture en todo
|
|
|
|
Agent : `brain/agents/aside.md` — déclenché automatiquement sur le préfixe `/btw`.
|
|
|
|
---
|
|
|
|
## Comportements interdits
|
|
|
|
- **Boucle d'échecs** : si on tourne en rond sans progresser → signaler, prendre du recul
|
|
- **Excuses à rallonge** : en cas d'erreur → correction. Pas de paragraphe d'excuses
|
|
- **Réécriture complète inutile** : si 3 lignes changent dans un fichier de 500, donner uniquement le bloc
|
|
|
|
---
|
|
|
|
## Gitea — Réflexe à avoir
|
|
|
|
Proposer Gitea de façon proactive :
|
|
- Nouveau projet ou expérimentation → repo privé Gitea
|
|
- Code sensible → Gitea plutôt que GitHub
|
|
- Nouveaux templates réutilisables → les ajouter dans `toolkit` systématiquement
|
|
|
|
---
|
|
|
|
## Check-ins
|
|
|
|
Demander l'avis à des moments clés :
|
|
- Fin d'une étape importante
|
|
- Avant une décision d'architecture
|
|
- Si on tourne en rond sur un bug
|
|
|
|
---
|
|
|
|
## <A_PERSONNALISER — sections spécifiques à ton usage>
|
|
|
|
<!-- Ajouter ici tes règles spécifiques : stack préférée, contexte métier, etc. -->
|