Modèle de handoff de session Claude Code : laisser un contexte réutilisable à un humain ou un agent

Claude Code devient plus fiable quand la session survit au handoff

Beaucoup d’échecs viennent d’un contexte perdu entre deux sessions. Une note de handoff permet à quelqu’un d’autre, ou à vous demain, de reprendre sans deviner.

Cet article relie le runbook de première tâche et le modèle de bug report.

Modèle de handoff

# Claude Code Handoff

## Goal
- Objectif du jour:
- À ne pas faire:

## Current state
- branch:
- last commit:
- dirty files:
- URLs liées:

## What changed
- Changements:
- Fichiers touchés:
- Intention:

## Verification
- Commandes lancées:
- Résultat:
- Vérification visuelle:

## Risks
- Zones fragiles:
- Ne pas toucher:
- Non vérifié:

## Next prompt
À la prochaine session, commence par git status et le diff récent.
Confirme qu’ils ne contredisent pas ce handoff avant d’éditer.

Bon exemple

## Goal
- Ajouter des liens internes depuis /en/products/ vers les 3 articles du 25/5
- Ne pas modifier la structure pricing aujourd’hui

## Verification
- npm.cmd run build: succès
- production /en/products/: 200
- mobile 390px: pas d’overflow horizontal

## Risks
- Les liens Gumroad privilégient l’anglais
- Vérifier les corps non anglais sur URL publique

Oublis fréquents

• Écrire seulement build OK sans URL publique
• Laisser des dirty files sans explication
• Masquer le non vérifié par “ça semble bon”
• Oublier le prochain prompt

Un handoff n’est pas un journal. Il doit permettre de repartir en 5 minutes.

Étape suivante

Pour un usage individuel, fixez le rituel avec le cheatsheet gratuit. Pour une équipe, combinez Setup Guide et Prompt Templates. Pour une adoption guidée, voyez la page de conseil.

Le handoff doit être plus précis qu’un commit message et plus court qu’un journal

La note de handoff est une donnée d’exploitation. Un commit message manque souvent de vérification et de risques; un journal est trop long. Gardez état actuel, raison du changement, validation, zones fragiles et prochain prompt.

Révise ce handoff:
1. il ne contredit pas git status
2. la raison du changement tient en une phrase
3. build et URL publique sont séparés
4. les risques non vérifiés sont explicites
5. le prochain prompt suffit pour reprendre

Sur un site multilingue, notez URL publique, langue, largeur mobile et état des CTA. Un build réussi ne prouve pas que la page visible est correcte.