Comment je parle à Claude

Voici des extraits réels de mes sessions Claude Code. Pas de prompts polis ou optimisés : ce sont les messages tels que je les tape au quotidien. Les typos font partie du deal.

1. Debug & Fix

Le type de prompt le plus fréquent. Court, direct, centré sur le problème. Pas de formules de politesse.

tordu-jardin

les font ne se chargent plus, corrige ça

granit-golem

comment je peux éditer un projet ? je n'ai pas accès à sa page pour le supprimer

sioule-2

en fait, les pièces jointes sont attachées au préambule, mais cela n'est pas visible ici

general

le shift d ne fonctionne pas depuis l'extension

Pattern observé : court, direct, centré sur le problème. Pas de politesse. "corrige ça" suffit.

2. Feature requests

Impératif, dépendant du contexte. Je pars du principe que Claude connaît le projet.

comrenov

seed moi l'appli avec des données que je puisse voir ce que ça donne en conditions réelles

granit-golem

et termine la feature de layout avec la navbar et footer dedans !

lab

ajoute uber eat, ajoute qu'on fait vraiment plus de détails dans la personnalisation de la compta !

Pattern observé : impératif, contexte implicite. Claude connaît le projet via CLAUDE.md, pas besoin de tout réexpliquer.

3. Architecture & refactoring

La critique directe fonctionne. Les décisions d'architecture se prennent en langage naturel.

sioule-backend

alos, c'est caca ton système, tu pourrais créer un module user-seed.module avec sa propre config qui ne soit pas intégré par défaut dans users.module

granit-golem

tu dois refaire tout ton diagnostique infra !

plan

k, landing: astro6, app backend: rust, axum, sqlx (même stack que l'actuel), app frontend: angular + lit pour les shared component, last version

Pattern observé : la critique directe marche. "c'est caca" est plus efficace que "ce n'est pas optimal". Les choix d'architecture se formulent en langage naturel, pas en diagrammes.

4. Qualité & review

Un pattern puissant : demander à Claude de prendre un rôle. Client, reviewer, testeur.

presentations

ensuite, analyse la présentation comme si tu étais un client, tu me liste tout ce qui ne va pas

totem

totem: test chaque composant de manière graphique (UI + tests) avec screenshots et analyse pour corriger tout ce qui ne va pas

ohs

ohs: analyse le business du site https://ohs-conseils.fr puis, défini le persona du client type entreprise

ohs

tu l'as testé en tant que client ?

Pattern observé : donner un rôle ("comme si tu étais un client") change complètement la qualité de la réponse. Claude sort du mode "développeur" et pointe des problèmes qu'il aurait ignorés autrement.

5. Design & itération

Parfois vague ("fais que ce soit ultime"), parfois précis au pixel ("1.5rem"). Les deux marchent dans des contextes différents.

siliceum-website

fais une boucle d'amélioration continue, améliore toutes les marges également

siliceum-website

continue d'améliorer, tu fais une boucle continue jusqu'à ce que ça soit ultime, ajoute des animations chouettes

siliceum-website

Mouais, pas encore convaincu par tes catégories, sois plus percutant

siliceum-website

réduis les margin-bottom des cases sur mobile, pas plus de 1.5rem

Pattern observé : itératif. Commencer vague pour explorer, puis affiner avec des valeurs précises. La boucle "continue d'améliorer" fonctionne bien avec le loop mode de Claude Code.

6. Infrastructure

Des prompts courts qui supposent un contexte partagé. Pas de specs formelles.

cloud

c'est sa conso ram tu veux dire le 512M ?

comrenov

attention, l'ordre des custom fields est important sur axonaut !

sioule-2

ajoute une interdiction de commit s'il y a ça

Pattern observé : le contexte fait le travail. "ça" dans "s'il y a ça" fait référence à quelque chose discuté juste avant dans la session. Claude suit le fil.

7. Ce qui ne marche PAS comme prompt

Les anti-patterns que j'ai identifiés après des milliers de sessions. Ces approches produisent des résultats médiocres ou des boucles sans fin.

✗

"Fais tout"

Trop vague. Claude part dans une direction aléatoire, fait des choix sans validation, et le résultat ne correspond pas à ce que j'attendais.

✗

"Implémente l'auth, les tests, le refactor et la doc"

4 tâches en 1 prompt = confusion. Claude en oublie une, mélange les contextes, ou produit un résultat moyen partout au lieu d'un résultat excellent sur une seule tâche.

✗

Long copier-coller de specs

Mieux vaut référencer un fichier. "Lis le fichier specs/auth.md et implémente" consomme moins de tokens et permet à Claude de relire si besoin.

✗

Trop de politesse

"S'il te plait, pourrais-tu considérer la possibilité de peut-être..." consomme des tokens pour zéro valeur ajoutée. "corrige ça" fait exactement le même travail.

8. Les patterns qui marchent

Ce que 10 581 sessions m'ont appris sur la façon de communiquer avec Claude Code.

1

Direct et court

"corrige ça", "ajoute X", "retire Y". Pas de fioritures. Le CLAUDE.md fournit le contexte, le prompt fournit l'intention.

les font ne se chargent plus, corrige ça

2

Donner un rôle

"analyse comme un client", "teste en tant qu'utilisateur". Le rôle change la perspective de Claude et fait émerger des problèmes invisibles en mode développeur.

analyse la présentation comme si tu étais un client

3

Boucle d'itération

"continue d'améliorer" fonctionne avec le loop mode. Claude itère seul, tourne en boucle d'amélioration jusqu'à ce que je coupe ou que le résultat me convienne.

continue d'améliorer, tu fais une boucle continue

4

Critique directe

"c'est caca" marche mieux que "ce n'est pas optimal". Le ton direct déclenche un effort plus important de la part de Claude pour corriger.

c'est caca ton système

5

Contexte implicite

Claude connaît le projet via CLAUDE.md et MEMORY.md. Pas besoin de tout réexpliquer. "ajoute ça" suffit quand le contexte est clair.

et termine la feature de layout avec la navbar et footer dedans !