Checklist des 30 premières minutes avec Claude Code

Les 30 premières minutes doivent créer de la confiance, pas un gros patch

La première session avec Claude Code échoue souvent quand la demande est trop large. Un débutant demande une fonctionnalité complète, un nettoyage global ou une refonte entière, puis il ne sait plus si le diff est sûr. Le bon objectif est plus limité: comprendre le dépôt, produire un petit résultat vérifiable, garder une preuve et écrire la prochaine étape.

La page officielle Claude Code overview explique que l’outil peut lire un codebase, modifier des fichiers, exécuter des commandes et s’intégrer aux outils de développement. Cette puissance demande des limites. Au premier essai, il ne faut pas prouver que Claude Code peut tout faire. Il faut prouver qu’il peut travailler dans une tâche étroite, contrôlable et vérifiable.

Cette checklist complète First Task Runbook, Repo Map First Pass, Session Handoff Template et Verification Receipt Workflow. Une fois cette base stable, tu peux l’étendre aux bugs, aux tests, aux articles et à l’onboarding d’équipe.

Les notions à comprendre avant de lancer

Un dépôt est le dossier du projet: code, tests, configuration, scripts et documentation. Un agent est l’exécutant qui peut explorer, modifier, lancer des commandes et proposer une vérification. Les permissions définissent ce que Claude Code peut lire, écrire ou exécuter. La documentation officielle des permissions décrit les règles allow, ask, deny et les modes d’approbation.

CLAUDE.md est une notice de projet. Tu peux y mettre les standards de code, décisions d’architecture, commandes de build, commandes de test et critères de review. Le guide officiel sur la mémoire explique comment les instructions de projet et la mémoire rendent les sessions suivantes plus cohérentes.

Vérifier signifie produire une preuve répétable. Cela peut être npm run build, un test qui passe, une capture d’écran, une vérification de logs ou une note qui précise ce qui reste non vérifié. Un diff plausible ne suffit pas. Avant toute édition, décide quelle preuve comptera.

Ce qui doit rester après 30 minutes

Résultat	Contenu	Utilité
Carte du dépôt	Points d’entrée, dossiers clés, commandes, zones risquées	Éviter les modifications à l’aveugle
Petite victoire	Diagnostic, lien corrigé, test expliqué ou reproduction	Garder un changement reviewable
Note de vérification	Commandes exécutées, résultat, incertitudes	Permettre au reviewer de répéter la preuve
Prochaine étape	Plus petite tâche utile	Accélérer la seconde session

Les grands changements viendront plus tard. La première session sert surtout à séparer compréhension, édition et preuve.

Minutes 0 à 5: demander du contexte, pas une implémentation

La première demande doit être en lecture seule. Elle sert à vérifier si Claude Code comprend le projet avant de toucher les fichiers.

Read this repository and tell me:
1. the main entry points
2. the commands I will probably need
3. the risky directories I should avoid first
4. the safest high-value first task for a 30-minute session

Do not edit files yet. Give me a short plan and the proof command you would run.

Ce prompt force l’identification des entrées, commandes, répertoires à risque et première tâche raisonnable. Les common workflows officiels suivent aussi ce rythme: explorer, planifier, implémenter, vérifier. Les cinq premières minutes sont donc consacrées à la lecture.

Minutes 5 à 20: choisir un cas d’onboarding

Premier cas: expliquer un test en échec. Demande quel test échoue, quelle valeur était attendue, quelle valeur a été obtenue et quel fichier semble concerné. Ne demande pas encore la correction. Une erreur bien décrite est déjà un résultat utile.

Deuxième cas: modifier un petit bloc de contenu ou de CTA. Pour un site monétisé, cela peut vouloir dire vérifier que le lien produit pointe toujours vers /products/, que le lien de consultation pointe vers /training/ et que le texte explique l’action suivante. Le diff est petit, mais l’impact business est réel.

Troisième cas: transformer un bug flou en reproduction. “Le dashboard casse parfois” n’est pas une tâche. Une bonne première session le transforme en environnement, étapes, résultat attendu, résultat réel, logs et fichiers candidats.

Quatrième cas: rédiger un CLAUDE.md minimal. Pas besoin d’écrire une charte complète. Commence par les commandes interdites, build, tests, style et preuves de review. Quand ces règles doivent devenir partagées, consulte la documentation officielle des settings.

Scripts à copier et exécuter

Sur macOS, Linux ou WSL, lance ce script depuis la racine du dépôt. Il lit l’état et ne modifie rien.

#!/usr/bin/env bash
set -euo pipefail

echo "== location =="
pwd

echo "== git status =="
git status --short

echo "== package scripts =="
if [ -f package.json ]; then
  node -e "const p=require('./package.json'); console.log(p.scripts || {})"
else
  echo "package.json not found"
fi

echo "== likely docs =="
find . -maxdepth 2 \( -name 'README*' -o -name 'CLAUDE.md' -o -name 'AGENTS.md' \) -print

echo "== recent changed files =="
git diff --name-only

Sur Windows PowerShell, utilise cette version.

$ErrorActionPreference = "Stop"

Write-Host "== location =="
Get-Location

Write-Host "== git status =="
git status --short

Write-Host "== package scripts =="
if (Test-Path package.json) {
  node -e "const p=require('./package.json'); console.log(p.scripts || {})"
} else {
  Write-Host "package.json not found"
}

Write-Host "== likely docs =="
Get-ChildItem -Force -File -Include README*,CLAUDE.md,AGENTS.md -Recurse -Depth 2 |
  Select-Object -ExpandProperty FullName

Write-Host "== recent changed files =="
git diff --name-only

Pour une note de handoff répétable, enregistre ceci sous first-30-handoff.mjs, modifie les valeurs puis lance node first-30-handoff.mjs.

const handoff = {
  outcome: "Adjusted one CTA sentence and confirmed the product/training links stayed visible.",
  verified: ["git status --short", "npm run build"],
  notVerified: ["Mobile visual check"],
  nextStep: "Open the page locally and inspect the CTA area at 390px width.",
};

for (const [label, value] of Object.entries(handoff)) {
  const body = Array.isArray(value) ? value.map((item) => `- ${item}`).join("\n") : value;
  console.log(`## ${label}\n${body}\n`);
}

Les permissions doivent commencer prudemment. Cet exemple est un JSON valide; adapte les commandes au projet.

{
  "permissions": {
    "allow": [
      "Bash(git status *)",
      "Bash(npm run build)",
      "Bash(npm test *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Erreurs concrètes à éviter

La première erreur est de demander “corrige tout”. Le périmètre est trop large et le critère de succès est absent. Remplace par “explique un test en échec” ou “mets à jour un bloc CTA et vérifie les liens”.

La deuxième erreur est d’utiliser des permissions trop larges dans un dossier de travail normal. Les modes forts peuvent servir en environnement isolé, mais un débutant doit commencer par lecture, confirmation d’édition et règles deny pour secrets ou actions destructrices. Si le projet contient des données privées, lis la documentation officielle de security.

La troisième erreur est de ne lancer aucune preuve. Une explication convaincante n’est pas une vérification. Décide si la preuve sera npm run build, des tests, un parse JSON, une vérification visuelle ou une capture d’écran.

La quatrième erreur est de terminer sans handoff. Sans note sur ce qui a changé, ce qui a été vérifié, ce qui reste incertain et la prochaine étape, la session suivante recommence l’exploration.

Prochaine étape et chemin de conversion

Pour t’entraîner seul, commence par la cheatsheet gratuite afin de garder les prompts sûrs sous la main. Pour des prompts réutilisables, modèles CLAUDE.md et checklists de review, consulte ClaudeCodeLab products. Si ton équipe doit cadrer permissions, hooks, preuves de vérification et formation, utilise Claude Code training and consultation.

Après essai dans un vrai dépôt, le plus utile n’était pas le script lui-même, mais l’habitude de demander une carte avant édition et de finir par git status --short. Note japonaise de l’article: 実際に試した結果, une première tâche plus petite rend le diff plus fiable et prépare beaucoup mieux la deuxième session Claude Code.