Checklist d'audit de dépôt Claude Code avant la première modification

La première session Claude Code dans un dépôt existant ne doit pas commencer par une modification. Elle doit commencer par une carte. L’agent lit vite, mais cette vitesse n’est utile que s’il connaît les points d’entrée, zones protégées, commandes de preuve et chemins business.

L’intention est simple: utiliser Claude Code dans un vrai codebase sans perdre le contrôle. Le but n’est pas encore de livrer une fonctionnalité, mais de rendre visibles le périmètre, le risque, la vérification et les CTA revenus en 20 minutes.

À lire aussi: claude-code-getting-started-complete, claude-code-existing-codebase-map, claude-code-harness-lite-workflow.

Pourquoi ce cadre doit précéder la première modification

Claude Code est plus fiable quand la tâche a une frontière claire. Une bonne frontière nomme les fichiers lisibles, les fichiers éditables, les opérations interdites et la preuve qui termine le travail. Sans cela, un petit prompt débutant peut devenir une grande réécriture, et un changement de contenu peut casser le PDF gratuit, Gumroad ou la consultation.

Ce cadre aide aussi le revenu car il relie preuve technique et preuve lecteur. Une page qui build en local mais envoie le lecteur vers le mauvais produit n’est pas terminée. En enregistrant scope, commande, URL publique et CTA, on améliore demain depuis une preuve, pas depuis la mémoire.

Workflow pratique

1. Lire seulement README, package.json et les entrées de routing
2. Marquer generated, billing, auth, migrations et .env comme zones protégées
3. Limiter la première surface éditable à trois fichiers ou moins
4. Choisir une commande de preuve avant tout patch
5. Pour contenu ou landing page, auditer aussi PDF gratuit, Gumroad et consultation

Situation	Action sûre	Preuve
Site Astro de contenu	Avant de créer un article, inspecter collection, slug, heroImage et modèle de CTA. Le corps et le chemin payant font partie de l’audit.	build, diff, URL
Dashboard React	Pour un petit défaut de layout, rester sur composant, CSS et capture. Auth et billing restent protégés.	screenshot, test
Dépôt API	Lire d’abord la route et la commande de test. Migrations et secrets restent hors première tâche.	log, command, handoff

La première passe doit rester courte. L’audit doit produire une décision, pas un rapport géant. Si la décision reste floue après 20 minutes, l’étape sûre est de lire un fichier de plus, pas de commencer à modifier.

Prompt et code copiables

Audite ce dépôt avant la première modification. Ne modifie rien. Retourne fichiers d'entrée, zones protégées, fichiers sûrs, commande de preuve minimale, URL publique et checks CTA.

const audit = {
  repo: "customer-portal",
  intent: "first safe Claude Code session",
  scope: ["README.md", "package.json", "src/routes"],
  protected: [".env", "billing/", "migrations/"],
  proof: ["npm.cmd run build", "git diff --stat"],
};

export function readyForFirstEdit(report) {
  return report.scope.length > 0 &&
    report.protected.length > 0 &&
    report.proof.some((command) => command.includes("build"));
}

console.log(readyForFirstEdit(audit));

Le code est volontairement petit. Il transforme une règle d’exploitation en objet vérifiable: un scope existe, des zones protégées existent et une commande de preuve est attachée. Vous pouvez l’adapter à la publication, au développement, au debug ou au handoff.

Trois exemples réels

Site Astro de contenu

Avant de créer un article, inspecter collection, slug, heroImage et modèle de CTA. Le corps et le chemin payant font partie de l’audit.

Le point important est la preuve. Gardez une commande, une page visible ou une note qui montre que le travail a réellement atteint le lecteur.

Dashboard React

Pour un petit défaut de layout, rester sur composant, CSS et capture. Auth et billing restent protégés.

Le point important est la preuve. Gardez une commande, une page visible ou une note qui montre que le travail a réellement atteint le lecteur.

Dépôt API

Lire d’abord la route et la commande de test. Migrations et secrets restent hors première tâche.

Le point important est la preuve. Gardez une commande, une page visible ou une note qui montre que le travail a réellement atteint le lecteur.

Échecs à éviter

• Demander de tout corriger mélange audit et implémentation.
• Un build local ne suffit pas si l’URL publique ou le CTA pointe ailleurs.
• Sans zones protégées, une modification utile peut devenir incident.

Un autre échec discret est le drift de localisation. L’article anglais peut expliquer le bon chemin produit, tandis qu’une autre langue garde un ancien CTA. La vérification publique doit donc lire h1, début du corps et CTA dans chaque langue, pas seulement frontmatter lang.

Relier le lecteur au PDF, à Gumroad et à la consultation

Si le lecteur manque encore d’aisance avec les commandes, orientez-le vers le cheatsheet gratuit. Si le blocage concerne setup, permissions, CLAUDE.md, hooks, MCP ou CI/CD, le meilleur produit est le Setup Guide. Pour des prompts de review, debug et refactor répétés, proposez 50 Prompt Templates. Pour un déploiement d’équipe, un workflow ou une route de revenus, utilisez la consultation. La comparaison des offres se fait sur products.

Ne poussez pas immédiatement chaque lecteur vers un produit payant. Les débutants ont souvent besoin d’un PDF sans friction. Les lecteurs qui répètent des prompts sont proches des templates. Ceux bloqués par permissions, CLAUDE.md, hooks, MCP ou CI/CD sont proches du Setup Guide. Les équipes avec des questions de process sont proches de la consultation.

Ce qu’il faut vérifier avant et après publication

La vérification ne se limite pas au HTTP 200. Il faut lire le h1, le début du corps, l’image hero, les liens internes, les liens Gumroad et le chemin de consultation.

Pour publier en plusieurs langues, vérifiez séparément japonais, anglais, chinois, coréen, espagnol, français, allemand, portugais, hindi et indonésien. Le slug peut correspondre alors que le corps est ancien. Une capture mobile révèle plus vite le paragraphe d’ouverture et le CTA.

Chiffres à suivre ensuite

Surveillez les démarrages PDF, clics Gumroad, visites products, visites training, source de recherche, pays et taux clic article vers CTA. Si les PV montent sans clic Gumroad, il faut renforcer l’adéquation produit. Si la consultation monte depuis un article technique, le lecteur cherche sans doute un workflow.