Claude Code Command Map für die erste Woche: 12 Befehle in sinnvoller Reihenfolge

Warum ein eigenes Artefakt nötig ist

Dieser Artikel baut eine Command Map für die erste Woche für Einsteiger, die Claude Code installiert haben und eine ruhige erste Woche brauchen. Der häufige Fehler ist einfach: neue Nutzer springen vom Installieren zu großen Aufgaben und wissen nicht, welcher Befehl Fortschritt beweist. Ein Claude-Code-Workflow endet nicht bei einer selbstsicheren Antwort. Er braucht ein Artefakt, das eine andere Person prüfen kann. Hier ist das eine Tageskarte vom Repo-Lesen bis zur Prüfung einer kleinen Änderung.

Behandle das Artefakt als Vertrag zwischen Prompt, Kommandozeile und öffentlicher Seite. Es zeigt, was Claude Code gelesen hat, was geändert wurde, welcher Befehl den Erfolg beweist und welchen Umsatzpfad der Leser danach sieht. Darum gehört es zu harness engineering, getting started und permissions.

Der operative Loop

Der Loop hat fünf Schritte: Aktion definieren, Nachweis wählen, Claude Code die kleinste nützliche Arbeit machen lassen, Output prüfen und die nächste Umsatzaktion notieren. Der Nachweis ist hier nicht nur “Code läuft”. Beobachte erfolgreiche Builds, kleinere Diffs, weniger Approval-Überraschungen und mehr PDF-Starts. Wenn diese Felder sichtbar sind, verbesserst du ohne Raten.

1. Tag eins bleibt read-only: Dateien, Befehle und riskante Ordner vor jedem Patch erfassen.

2. Tag drei erlaubt eine reversible Änderung, aber der Proof-Befehl steht vor dem Edit fest.

3. Tag fünf schreibt ein Handoff, damit die nächste Sitzung mit Belegen startet.

Kopierbarer Starter

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

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

Drei Praxisbeispiele

Beispiel 1. Tag eins bleibt read-only: Dateien, Befehle und riskante Ordner vor jedem Patch erfassen.

Beispiel 2. Tag drei erlaubt eine reversible Änderung, aber der Proof-Befehl steht vor dem Edit fest.

Beispiel 3. Tag fünf schreibt ein Handoff, damit die nächste Sitzung mit Belegen startet.

Self-Review-Checkliste

Bevor dieser Workflow zur Gewohnheit wird, prüfe den Artikel wie eine Release Note. Der erste Check ist Scope: Leser müssen wissen, wann eine Command Map für die erste Woche sinnvoll ist und wann eine kleinere Checkliste reicht. Der zweite Check ist Nachweis: Jede Empfehlung sollte auf Befehl, URL, Diff oder Metrik zeigen. Der dritte Check ist Routing: kostenloses PDF, Gumroad-Guide und Beratung sollen nicht konkurrieren, sondern unterschiedliche Dringlichkeiten beantworten.

Nutze eine kleine Ownership-Regel. Eine Person besitzt das Artefakt, eine die Verifikation und eine das nächste CTA-Experiment. Im Solo-Workflow kann das dieselbe Person sein, aber die Rollen sollten im Hinweis benannt werden. So behandelt Claude Code Publishing, Messen und Verkaufen nicht als eine verschwommene Aufgabe. Der nächste Lauf weiß außerdem, wo er fortsetzen soll.

Die praktische Frage lautet: Was macht diesen Artikel morgen früh leichter prüfbar? Ist die Antwort ein Screenshot, speichere ihn. Ist es ein stärkerer Prompt, kommt er in das Prompt Pack. Ist es eine klarere Grenze, gehört sie in die Setup-Notizen. eine Tageskarte vom Repo-Lesen bis zur Prüfung einer kleinen Änderung ist nur nützlich, wenn es die nächste Sitzung übersteht.

Fehlerfälle

Der erste Fehler ist, Pageviews als einzigen Score zu behandeln. Der zweite ist Approval ohne Proof-Befehl. Der dritte ist, jeden Leser zum gleichen Kaufprodukt zu schicken, obwohl PDF oder Beratung besser passt. Schreibe die Routing-Regel, bevor du den CTA änderst.

Umsatzpfad

Route nach Engpass. Bei fehlender Command-Sicherheit passt das kostenlose PDF oder das kostenlose Gumroad-Cheatsheet. Bei wiederholter Arbeit passen 50 Prompt Templates oder Setup Guide. Bei Rollout, Risiko oder Umsatzdesign passt Beratung. Für diesen Artikel gilt: das free cheatsheet hilft beim Erinnern, der Setup Guide bei Teamregeln.

Verifikationsmetriken

Nach dem Publishing reicht HTTP 200 nicht. Prüfe h1, canonical, hero image, Einstiegstext, CTA-Links, mobile layout und Sprache. Danach beobachte erfolgreiche Builds, kleinere Diffs, weniger Approval-Überraschungen und mehr PDF-Starts. Wenn nichts steigt, verbessere zuerst den CTA beim ersten konkreten Beispiel.