Carte de commandes de la première semaine Claude Code : 12 commandes dans l'ordre

Pourquoi créer un artefact dédié

Cet article construit une carte de commandes de première semaine pour débutants qui ont installé Claude Code et veulent une première semaine calme. L’échec fréquent est simple : les nouveaux passent de l’installation à de grandes demandes sans savoir quelle commande prouve le progrès. Un workflow Claude Code ne s’arrête pas à une réponse confiante. Il doit laisser un artefact qu’une autre personne peut contrôler. Ici, cet artefact est une carte par jour, de la lecture du repo à la vérification d’un petit changement.

Traitez l’artefact comme un contrat entre prompt, ligne de commande et page publique. Il doit montrer ce que Claude Code a lu, ce qu’il a changé, quelle commande prouve le résultat et quel chemin de revenus le lecteur voit ensuite. C’est lié à harness engineering, getting started et permissions.

La boucle opérationnelle

La boucle a cinq passages : définir l’action, choisir la preuve, laisser Claude Code faire le plus petit travail utile, vérifier la sortie, puis noter la prochaine action de revenu. Ici, la preuve utile n’est pas seulement le code qui tourne. Surveillez builds réussis, petits diffs, moins de surprises d’approbation et plus de départs PDF. Quand ces champs sont visibles, l’amélioration cesse d’être une devinette.

1. Le jour un reste en lecture seule : fichiers, commandes et dossiers risqués avant tout patch.

2. Le jour trois autorise une édition réversible, mais la preuve est choisie avant l’édition.

3. Le jour cinq écrit un handoff pour que la session suivante parte de preuves.

Starter à copier

$checks = @(
  "git status --short",
  "rg --files | Select-Object -First 40",
  "npm.cmd run build"
)

foreach ($cmd in $checks) {
  Write-Host "NEXT:" $cmd
}

Trois exemples terrain

Exemple 1. Le jour un reste en lecture seule : fichiers, commandes et dossiers risqués avant tout patch.

Exemple 2. Le jour trois autorise une édition réversible, mais la preuve est choisie avant l’édition.

Exemple 3. Le jour cinq écrit un handoff pour que la session suivante parte de preuves.

Checklist d’auto-revue

Avant de transformer ce workflow en habitude, relisez l’article comme une note de release. Le premier contrôle est le scope : le lecteur doit savoir quand utiliser une carte de commandes de première semaine et quand une checklist plus petite suffit. Le deuxième contrôle est la preuve : chaque recommandation doit pointer vers une commande, une URL, un diff ou une métrique. Le troisième contrôle est le routing : PDF gratuit, guide Gumroad et consultation doivent répondre à des urgences différentes.

Ajoutez une petite règle d’ownership. Une personne possède l’artefact, une autre la vérification, une autre la prochaine expérience CTA. En solo, ce peut être la même personne, mais les rôles doivent être nommés dans la note. Cela empêche Claude Code de mélanger publication, mesure et vente dans une tâche floue. La prochaine exécution sait aussi où reprendre.

La question utile est : qu’est-ce qui rendra cet article plus facile à vérifier demain matin ? Si la réponse est une capture, gardez-la. Si c’est un prompt plus fort, ajoutez-le au prompt pack. Si c’est une limite plus claire, ajoutez-la aux notes de setup. une carte par jour, de la lecture du repo à la vérification d’un petit changement n’a de valeur que s’il survit à la session suivante.

Échecs fréquents

Le premier échec consiste à prendre les pages vues comme seul score. Le deuxième est d’approuver sans commande de preuve. Le troisième est d’envoyer tous les lecteurs vers le même produit payant alors qu’un PDF gratuit ou une consultation convient mieux. Écrivez la règle de routing avant de changer le CTA.

Chemin de revenus

Routez par blocage. Si la personne manque de fluidité commande, envoyez-la vers le PDF gratuit ou le cheatsheet Gumroad gratuit. Si elle répète le même travail chaque semaine, proposez 50 Prompt Templates ou Setup Guide. Si le sujet est rollout, risque ou revenu, proposez la consultation. Pour cet article, le free cheatsheet aide au rappel quotidien, et Setup Guide sert quand il faut des règles d’équipe.

Métriques de vérification

Après publication, HTTP 200 ne suffit pas. Vérifiez h1, canonical, hero image, début du corps, liens CTA, mobile layout et langue. Ensuite, suivez builds réussis, petits diffs, moins de surprises d’approbation et plus de départs PDF. Si rien ne bouge, corrigez d’abord le CTA près du premier exemple concret.