Claude Code: Checkliste für die ersten 30 Minuten

Die ersten 30 Minuten sollen Vertrauen schaffen, keinen riesigen Patch

Viele erste Sitzungen mit Claude Code scheitern nicht am Werkzeug, sondern am zu großen Auftrag. Einsteiger bitten um ein komplettes Feature, eine vollständige Codebereinigung oder einen ganzen Relaunch. Nach 30 Minuten liegt dann ein Diff vor, der schwer zu prüfen ist. Der bessere Start ist kleiner: Repository verstehen, einen überprüfbaren Fortschritt erzielen, Belege speichern und den nächsten Schritt notieren.

Die offizielle Claude Code overview beschreibt Claude Code als agentisches Coding-Werkzeug, das Codebases lesen, Dateien bearbeiten, Befehle ausführen und mit Entwicklungstools zusammenarbeiten kann. Genau deshalb braucht die erste Sitzung klare Grenzen. Es geht nicht darum, alles zu automatisieren. Es geht darum, eine kleine Aufgabe sicher auszuführen.

Diese Checkliste passt zu First Task Runbook, Repo Map First Pass, Session Handoff Template und Verification Receipt Workflow. Wenn dieser Ablauf sitzt, kannst du ihn auf Bugs, Tests, Content-Arbeit und Team-Onboarding übertragen.

Begriffe für Einsteiger

Ein Repository ist der Projektordner mit Quellcode, Tests, Konfiguration, Skripten und Dokumentation. Ein Agent ist der Ausführer, der untersuchen, ändern, Befehle ausführen und Ergebnisse prüfen kann. Permissions sind die Sicherheitsregeln: Sie legen fest, was Claude Code lesen, ändern oder ausführen darf. Die offizielle Dokumentation zu permissions erklärt allow, ask und deny sowie verschiedene Genehmigungsmodi.

CLAUDE.md ist die Projektanleitung. Dort stehen Coding-Regeln, Architekturhinweise, verbotene Befehle, Build-Kommandos, Test-Kommandos und Review-Kriterien. Der offizielle Leitfaden zu memory zeigt, wie Projektanweisungen und Erinnerung spätere Sitzungen stabiler machen.

Verifikation bedeutet wiederholbare Evidenz. Das kann npm run build, ein grüner Test, ein Screenshot, ein Log-Check oder eine klare Liste offener Punkte sein. Ein plausibel wirkender Diff ist keine Verifikation. Lege vor der Änderung fest, welcher Beweis zählt.

Was nach 30 Minuten vorhanden sein sollte

Ergebnis	Inhalt	Nutzen
Repo-Karte	Einstiegspunkte, wichtige Ordner, Befehle, Risikobereiche	Nicht blind ändern
Kleiner Erfolg	Diagnose, Link-Korrektur, Test-Erklärung oder Repro-Notiz	Reviewbare Größe
Verifikationsnotiz	Befehle, Resultate, Restunsicherheit	Beweis wiederholbar machen
Nächster Schritt	Kleinste sinnvolle Folgeaufgabe	Zweite Sitzung beschleunigen

Große Änderungen sind später möglich. Die erste Sitzung trainiert aber zuerst die Trennung von Verstehen, Bearbeiten und Prüfen.

Minute 0 bis 5: Kontext statt Implementierung

Der erste Prompt sollte nur lesen. So erkennst du, ob Claude Code das Projekt versteht, bevor Dateien geändert werden.

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.

Dieser Prompt erzwingt Einstiegspunkte, Befehle, riskante Verzeichnisse und eine begrenzte erste Aufgabe. Die offiziellen common workflows folgen demselben Muster: erkunden, planen, umsetzen, verifizieren. Die ersten fünf Minuten gehören der Orientierung.

Minute 5 bis 20: einen Onboarding-Fall wählen

Der erste Praxisfall ist ein fehlgeschlagener Test. Bitte Claude Code nicht sofort um den Fix, sondern um eine Erklärung: welcher Test, welcher erwartete Wert, welcher tatsächliche Wert, welche Datei. Eine präzise Fehlerbeschreibung ist bereits ein Ergebnis.

Der zweite Fall ist eine kleine Content- oder CTA-Änderung. Auf einer monetarisierten Seite kann das heißen: Produktlink zeigt weiterhin auf /products/, Beratungslink zeigt weiterhin auf /training/, und der Text erklärt den nächsten Schritt. Der Diff bleibt klein, aber der geschäftliche Nutzen ist sichtbar.

Der dritte Fall ist ein vager Bug als Reproduktionsnotiz. “Das Dashboard bricht manchmal” ist kein guter Auftrag. Besser sind Umgebung, Schritte, erwartetes Ergebnis, tatsächliches Ergebnis, Logs und Kandidatendateien.

Der vierte Fall ist ein minimales CLAUDE.md. Schreibe nicht sofort ein vollständiges Team-Handbuch. Beginne mit verbotenen Befehlen, Build, Tests, Stilregeln und Review-Belegen. Wenn daraus geteilte Konfiguration wird, lies die offiziellen settings.

Kopierbare Skripte

Unter macOS, Linux oder WSL läuft dieses Skript im Repository-Root. Es liest Zustand und ändert keine Dateien.

#!/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

Unter Windows PowerShell nutzt du diese Variante.

$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

Für eine wiederholbare Handoff-Notiz speichere dies als first-30-handoff.mjs, passe die Werte an und führe node first-30-handoff.mjs aus.

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`);
}

Permissions sollten konservativ starten. Dieses Beispiel ist gültiges JSON; passe die Befehle an dein Projekt an.

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

Konkrete Fehlerfälle

Der erste Fehler ist “mach alles fertig”. Das hat keinen Umfang und kein Erfolgskriterium. Besser ist “erkläre einen fehlgeschlagenen Test” oder “aktualisiere einen CTA-Block und prüfe die Links”.

Der zweite Fehler sind zu breite Rechte im normalen Arbeitsbaum. Starke Modi gehören in isolierte Umgebungen, nicht in die erste Einsteiger-Sitzung. Wenn Credentials oder private Daten im Projekt liegen, lies die offizielle security-Dokumentation und sperre .env-Dateien.

Der dritte Fehler ist fehlende Verifikation. Eine gute Erklärung ersetzt keinen Nachweis. Entscheide vorher, ob npm run build, Tests, JSON-Parsing, Screenshot oder visuelle Prüfung der Beweis ist.

Der vierte Fehler ist ein Ende ohne Handoff. Ohne Notiz zu Änderung, Prüfung, Risiko und nächstem Schritt wiederholt die nächste Sitzung dieselbe Orientierung.

Nächster Schritt und Conversion-Pfad

Für eigenes Üben starte mit dem kostenlosen Cheatsheet, damit sichere Prompts und Prüfkommandos griffbereit sind. Für wiederverwendbare Prompts, CLAUDE.md-Vorlagen und Review-Checklisten nutze ClaudeCodeLab products. Wenn dein Team Permissions, Hooks, Verification Receipts und Training braucht, ist Claude Code training and consultation der passende nächste Schritt.

Im echten Repository war nicht das Skript der größte Gewinn, sondern die Gewohnheit, vor Änderungen eine Repo-Karte zu verlangen und am Ende git status --short zu prüfen. Japanische Notiz: 実際に試した結果, eine kleinere erste Aufgabe machte den Diff vertrauenswürdiger und die zweite Claude-Code-Sitzung deutlich schneller.