Une feature complète suivie minute par minute : un système de streak de
publication sur un SaaS de contenu. Tu verras où placer le plan mode,
/goal, /code-review et /usage dans une vraie session.
Le contexte
Tu construis un SaaS pour freelances qui les aide à publier sur LinkedIn. Problème constaté après 3 semaines de beta : 68% de tes utilisateurs créent 1 ou 2 contenus puis abandonnent. Tu veux les motiver à publier régulièrement avec un système de streak (série consécutive), sans que ce soit punitif.
Minute 0-5, brainstorm
Ce que tu tapes :
"Brainstorme un système de streak de publication. Les freelances publient 1-2 fois puis abandonnent. Je veux les motiver à publier régulièrement sans être punitif. Contexte : Next.js 16 + Supabase, déjà auth et dashboard en place."
Ce que Claude propose :
Option 1, streak quotidien (style Duolingo)
Simple mais punitif. Un jour raté = tout perdu. Inadapté aux freelances qui ne publient pas tous les jours.
Option 2, streak hebdomadaire (recommandé)
Plus flexible. "Publie au moins 1 contenu par semaine" → le streak augmente. 14 jours sans publication → le streak repart de zéro. Tu peux sauter des jours, il faut juste publier chaque semaine.
Option 3, points et niveaux
Gamification complète mais risque de distraire de l'objectif principal (créer du contenu de qualité).
Ce que tu réponds :
"Va pour le streak hebdomadaire. Bonne intuition sur la tolérance 14 jours."
Minute 5-15, planification
Tu passes en plan mode avec Shift+Tab : Claude explore le code en lecture seule et ne modifie rien tant que tu n'as pas validé.
Ce que tu tapes :
"Écris le plan d'implémentation pour le streak hebdomadaire. Table Supabase, Server Action, composant dashboard, tests."
Ce que Claude produit :
Un plan en 6 tâches numérotées avec, pour chacune : le fichier à créer ou modifier, ce que la tâche fait, la commande de vérification.
Tâche 1 : Migration SQL supabase/migrations/20260420_create_streaks.sql : table streaks (user_id, current_streak, best_streak, last_publication_date, updated_at) + policy RLS + index
Tâche 2 : Régénérer les types TypeScript → src/types/database.types.ts
Tâche 3 : Server Action src/lib/actions/streak.ts : getStreak() et updateStreakAfterPublish()
Tâche 4 : Composant UI src/components/dashboard/publishing-streak.tsx : flamme animée Framer Motion + compteur
Tâche 5 : Intégration dans src/app/(app)/dashboard/page.tsx
Tâche 6 : Tests unitaires tests/unit/actions/streak.test.ts : 4 scénarios
Ce que tu vérifies :
- L'ordre est logique ? Oui : BDD, types, logique, UI, intégration, tests
- Il manque quelque chose ? Non, c'est complet
- Le scope est raisonnable ? Oui, environ 30-40 minutes d'exécution
Ce que tu fais : tu valides le plan, Claude sort du plan mode. Ta session tourne en auto mode (le mode par défaut, voir chapitre 9) : un classifieur laisse passer le typecheck, le lint et les tests sans te demander, et bloque par défaut ce qui touche à la prod (déploiement, migration en production) ou détruit du travail, comme un force push.
Pour que Claude aille jusqu'au bout sans que tu relances à chaque étape, tu fixes une condition de fin :
/goal les 6 tâches du plan sont faites et npm run typecheck, npm run lint et npm run test passent
Le goal démarre tout de suite, pas besoin d'envoyer un autre message. Après chaque tour, un petit modèle rapide relit la conversation et vérifie si la condition est remplie. Tant qu'elle ne l'est pas, Claude repart pour un tour. L'indicateur ◎ /goal active reste affiché pendant ce temps. Tu peux l'arrêter à tout moment avec /goal clear (détails au chapitre 18).
Choisis une condition que Claude peut constater. L'évaluateur ne lance
rien lui-même, il lit seulement ce qui s'affiche dans la conversation. "Les
tests passent", il le voit dans le terminal. "Le code est propre" ne se mesure
pas, et il risque de tourner en rond. Si le plan est faux, /goal l'exécutera
quand même jusqu'au bout : relire le plan reste ton boulot.
Minute 15-25, exécution (tâches 1-3)
Claude travaille en autonomie. Ce qui se passe dans le chat :
Tâche 1, migration SQL
Claude crée supabase/migrations/20260420_create_streaks.sql :
- Table
streaksavec les 5 colonnes - Policy RLS : chaque utilisateur ne voit que son propre streak
- Index sur
user_idpour la performance
Il lance npx supabase migration up --local sur la base locale → migration appliquée en 340ms.
Une règle posée directement dans la base PostgreSQL (donc dans Supabase) qui filtre les lignes qu'un utilisateur a le droit de lire ou de modifier. Même si le code de l'app oublie un filtre, la base refuse de renvoyer le streak d'un autre. Une table Supabase sans policy RLS est la première faille à chercher en review.
Tâche 2, types TypeScript
Il régénère les types depuis la base de données avec npx supabase gen types typescript --local > src/types/database.types.ts. Le code TypeScript connaît désormais la table streaks et ses colonnes.
Il lance npm run typecheck → aucune erreur.
Tâche 3, Server Action
Il crée src/lib/actions/streak.ts avec la logique métier :
getStreak(): récupère le streak actuelupdateStreakAfterPublish(): appelé après chaque publication- Logique : si la dernière publication date de moins de 14 jours, streak++ ; sinon, streak = 1. Le
best_streakest mis à jour si le courant le dépasse.
Il lance npm run typecheck && npm run lint → tout passe.
Minute 25-40, exécution (tâches 4-6)
Tâche 4, composant UI
Claude crée src/components/dashboard/publishing-streak.tsx :
- Icône de flamme (
lucide-reactFlame) qui grossit avec le streak - Compteur "3 semaines consécutives"
- Message d'encouragement personnalisé
- Animation subtile d'entrée via Framer Motion
Il lance npm run typecheck, RAS.
Tâche 5, intégration dans le dashboard
Il modifie src/app/(app)/dashboard/page.tsx pour intégrer le composant streak en haut de la grille, à côté du widget "Contenus publiés ce mois".
Tâche 6, tests unitaires
Il crée tests/unit/actions/streak.test.ts avec :
- Test du calcul normal (streak +1 quand dernière publi < 14 jours)
- Test du streak cassé (reset à 1 après 14 jours)
- Test du best streak (record personnel préservé)
- Test du premier streak (nouvel utilisateur, pas de ligne existante)
Il lance npm run test streak → 4/4 tests passent en 180ms.
Minute 40-50, test visuel et itération
Tu ouvres localhost:3000/dashboard dans ton navigateur et tu vois le résultat.
Ce que tu observes :
- Le compteur de streak s'affiche bien dans le dashboard, OK
- La flamme est un peu petite, à corriger
- Le message d'encouragement est générique, à améliorer
Ce que tu tapes :
"Le compteur est trop petit. J'aimerais une flamme plus grande (48px au lieu de 24px), et un message d'encouragement différent selon le nombre de semaines : 1 semaine = 'C'est parti !', 2-3 = 'Beau rythme !', 4+ = 'Inarrêtable !'"
Claude ajuste en 2 minutes. Tu rafraîchis le navigateur, parfait.
Minute 50-60, review et commit
Ce que tu tapes :
/code-review
La revue tourne en subagent de fond (un Claude séparé, avec son propre contexte). Tu peux préciser un niveau, de low à max : /code-review high cherche plus loin, au prix de plus de tokens. Elle relit tout le code modifié et signale :
- Pas de bug détecté
- RLS correctement configuré (sécurité OK)
- Types cohérents
- Suggestion : ajouter un fallback si la table est vide (nouvel utilisateur qui n'a jamais publié)
Claude corrige la suggestion en ajoutant un ?? { current_streak: 0, best_streak: 0 } dans getStreak(). Puis :
/commit
Claude crée le commit : feat(dashboard): add weekly publishing streak with animated flame
/commit n'est pas une commande native : elle vient du plugin commit-commands (voir chapitre 16). Sans le plugin, écris simplement "Commite avec un message conventionnel", le résultat est le même.
Minute 60, le bilan avec /usage
Dernier réflexe avant de fermer :
/usage
Tu vois le coût estimé de la session, la répartition par subagent, skill et serveur MCP, et le taux de cache (la part du contexte relue pour presque rien au lieu d'être retraitée). Deux choses à regarder :
- Le subagent de review pèse lourd ? Normal sur un gros diff. Sur un petit fix,
/code-review lowsuffit. - Le taux de cache chute ? Souvent un changement de modèle en cours de route ou une longue pause. Le chapitre 19 explique comment l'éviter.
Puis /clear avant la feature suivante : c'est gratuit et Claude repart d'un contexte propre.
Résumé du timing
| Phase | Durée | Qui |
|---|---|---|
| Brainstorm | 5 min | Claude propose 3 options, tu choisis |
| Planification | 10 min | Claude écrit le plan, tu valides |
| Exécution | 25 min | /goal + auto mode, Claude code 6 tâches |
| Test + itération | 10 min | Tu testes, tu demandes des ajustements |
| Review + commit | 10 min | /code-review, correction, commit, /usage |
| Total | 60 min | Feature complète : BDD + logique + UI + tests |
Question
Quelle condition /goal a le plus de chances d'aboutir ?
Choisis une réponse pour voir l'explication.
À retenir
- Une heure pour la base, la logique, l'UI et les tests. Tu n'as pas tapé de code, tu as choisi l'approche, validé le plan et corrigé le rendu.
/goalmarche si sa condition se vérifie dans le terminal (tests, typecheck)./code-reviewpuis/usageavant de fermer, et/clearavant la feature suivante.