Vibe Coding mit Claude Code

Das vollständige Fakten-Dossier – von der Idee bis zum kontrollierten Betrieb

Stand: 8. August 2026 Zielgruppe: Menschen ohne klassische Entwicklerausbildung, die sich technische Projekte zutrauen und Claude Code kontrolliert einsetzen wollen. Umfang: Grundlagen, Installation, Projektaufbau, Git, CLAUDE.md, Skills, Permissions, Hooks, lokale Entwicklung, Windows, macOS, Synology NAS, Apache, VPS, SSH/SFTP, Docker, Datenbanken, Secrets, Deployment, DNS, HTTPS, Tests, Backups, Restore, Praxisprozess, Prompts, Best Practices sowie Vor- und Nachteile.

Faktenstatus Dieses Dossier unterscheidet vier Ebenen: FAKT bezeichnet durch Quellen belegte Aussagen. EMPFEHLUNG bezeichnet eine aus Quellen und technischer Praxis abgeleitete Vorgehensweise. VORLAGE bezeichnet frei anpassbare Projektdateien, Skills, Prompts oder Konfigurationen. UNKLAR bezeichnet Punkte, die ohne das konkrete Projekt, Betriebssystem, NAS-Modell oder Hostingangebot nicht belastbar entschieden werden können.

Aktualität Claude Code verändert sich schnell. Installationswege, Befehle, Skills, Hooks, Berechtigungsmodi, Abonnements und unterstützte Plattformen müssen unmittelbar vor Veröffentlichung oder praktischer Nutzung erneut geprüft werden. Die Quellenliste nennt deshalb bei laufender Dokumentation den Abrufstand 08.08.2026.

Sicherheitsgrenze Das Dossier zeigt, wie Claude Code technische Arbeit ausführen kann. Es empfiehlt nicht, der KI pauschalen Zugriff auf Produktivserver, Backups, private Schlüssel oder Kundendaten zu geben. Ein erfolgreicher Build ist kein Sicherheitsnachweis. Ein Git-Commit ist kein vollständiges Backup. Ein Deployment ist keine Abnahme.

\newpage

Management-Zusammenfassung

Die zentrale Aussage

FAKT: Claude Code ist eine agentische Entwicklungsumgebung. Das Werkzeug kann einen Projektbestand lesen, Dateien verändern, Befehle im Terminal ausführen, Tests und Builds starten, Git verwenden und aufgrund der Ergebnisse weiterarbeiten. Anthropic beschreibt diesen Ablauf als wiederholten Zyklus aus Kontextbeschaffung, Handlung und Verifikation. [S001] [S005]

EMPFEHLUNG: Für Einsteiger sollte Claude Code nicht als „Chatbot, der Webseiten schreibt“, sondern als technischer Mitarbeiter innerhalb einer kontrollierten Projektumgebung erklärt werden. Der Mensch muss nicht jede Syntax beherrschen. Er muss aber Ziel, Daten, Zugriffe, Prüfkriterien, Rücksprungpunkte und Betriebsgrenzen verstehen.

Der Unterschied ist praktisch:

```text Normaler KI-Chat Idee → Codeblock → Benutzer kopiert Dateien → offene technische Fragen

Claude Code Idee → Projektordner → Analyse → Plan → Dateiänderungen → Tests → Git → Deployment ```

Die 20 wichtigsten Ergebnisse der Recherche

1. Lokal beginnen. Der beste Einstieg ist ein einzelner Projektordner auf dem eigenen Windows- oder Mac-Rechner. Dort sind Fehler leichter zu begrenzen als auf einem öffentlichen Server.

1. Ein Projekt ist eine Grenze. Claude wird im konkreten Projektordner gestartet. Dadurch werden Kontext, Git-Historie, Abhängigkeiten und Berechtigungen voneinander getrennt. [S002] [S009]

1. Git gehört von Anfang an dazu. Claude kann Git bedienen, doch der Benutzer muss verstehen, was Repository, Commit, Branch, Remote und Rücksprungpunkt bedeuten. [S002] [S030–S034]

1. Git ist kein vollständiges Backup. Git versioniert den Projektbestand. Datenbanken, Uploads, Serverkonfiguration, externe Dienste, Secrets und Container-Volumes benötigen eigene Sicherungsverfahren. [S035] [S060] [S072–S075]

1. CLAUDE.md ist Projektwissen, keine Firewall. Die Datei wird in Sitzungen als Kontext geladen und eignet sich für Architektur, Befehle, Konventionen und Arbeitsregeln. Sie erzwingt diese Regeln nicht technisch. [S007] [S009]

1. CLAUDE.md muss kurz bleiben. Anthropic empfiehlt derzeit weniger als 200 Zeilen je Datei. Umfangreiche Abläufe gehören eher in Skills oder pfadbezogene Rules. [S007]

1. Skills sind wiederverwendbare Verfahren. Ein Skill besteht mindestens aus einer SKILL.md. Er kann automatisch passend geladen oder per /skill-name gestartet werden. [S012]

1. Seiteneffekte nur manuell. Deployment, Restore, Commit, Versand oder andere folgenreiche Abläufe sollten mit disable-model-invocation: true gegen automatische Modellauslösung geschützt werden. [S012]

1. Permissions werden außerhalb des Modells ausgewertet. deny, ask und allow steuern, was Claude Code tatsächlich zulässt. Die Auswertung erfolgt in der Reihenfolge deny, ask, allow. Eine breite Deny-Regel kann nicht durch eine engere Allow-Regel aufgehoben werden. [S009]

1. Breite Shell-Freigaben sind riskant. Eine Regel wie Bash(git *) umfasst nicht nur harmlose Statusabfragen, sondern auch Pushes oder andere Git-Unterbefehle. Berechtigungen müssen eng und nachvollziehbar formuliert werden. [S009]

1. Sandbox und Hooks sind härtere Schutzschichten. Die Sandbox begrenzt Dateisystem- und Netzwerkzugriffe von Shell-Prozessen. PreToolUse-Hooks können Aktionen vor Ausführung blockieren. [S010] [S013]

1. Checkpoints ersetzen Git nicht. Claude Code legt vor Benutzerprompts Zustandsaufnahmen für Dateiänderungen an. Änderungen durch beliebige Shell-Kommandos sind jedoch nicht vollständig erfasst; Checkpoints sind deshalb nur ein zusätzliches Sicherheitsnetz. [S011]

1. Ein NAS ist nicht automatisch die beste Entwicklungsmaschine. Eine Synology kann als interner Webserver, Container-Host, Git-Ziel und Backupziel sinnvoll sein. Synology empfiehlt für generische Entwicklung eine Containerumgebung statt Eingriffen in das DSM-System. [S051–S058]

1. Ein NAS ist nicht automatisch ein Backup. RAID, Snapshots und Backup erfüllen verschiedene Aufgaben. Synology empfiehlt eine 3-2-1-Strategie mit externer Kopie. [S055–S057]

1. Ein VPS verlagert Verantwortung zum Benutzer. Wer einen virtuellen Server betreibt, muss Benutzerrechte, SSH, Firewall, Updates, Dienste, Logs, Zertifikate und Backups organisieren. [S066–S071]

1. SFTP und SSH sind für neue Setups geeigneter als unverschlüsseltes FTP. SFTP läuft über SSH; FTPS ist FTP mit TLS und technisch etwas anderes. [S036] [S066] [S067]

1. Docker ist kein Pflichtschritt für den Anfang. Docker Compose kann mehrere Dienste reproduzierbar definieren und starten. Für eine erste statische Website oder ein einfaches lokales Projekt erhöht Docker jedoch zunächst die Komplexität. [S059–S065]

1. Verifikation ist der stärkste Prompt-Hebel. Claude arbeitet zuverlässiger, wenn es sein Ergebnis durch Tests, Build, Linter, gestartete Anwendung oder visuelle Prüfung überprüfen kann. [S005] [S006] [S026]

1. Es gibt keinen belastbaren universellen Produktivitätsfaktor. Studien zeigen positive, neutrale und negative Effekte je nach Aufgabe, Erfahrung und Messverfahren. Eine METR-Studie fand in einem engen Setting 2025 eine Verlangsamung erfahrener Open-Source-Entwickler; andere Studien und Selbstauskünfte berichten deutliche Vorteile. [S086–S091]

1. Kontrolliertes Vibe Coding ist ein Prozess, kein Prompt. Der belastbare Ablauf lautet: verstehen, spezifizieren, planen, bauen, prüfen, versionieren, sichern, veröffentlichen und betreiben.

Das empfohlene Reifegradmodell

EMPFEHLUNG: Anfänger sollten nicht alle technischen Ebenen gleichzeitig lernen. Ein vierstufiges Modell reduziert Risiken.

Die Reihenfolge ist didaktisch begründet: Ein VPS verlangt gleichzeitig Linux-, Netzwerk-, Sicherheits- und Betriebswissen. Ein lokales Projekt trennt zunächst das Erstellen der Anwendung vom öffentlichen Betrieb.

Minimaler professioneller Standard

Ein Projekt sollte spätestens vor der ersten echten Veröffentlichung mindestens enthalten:

``text mein-projekt/ ├── CLAUDE.md ├── SPEC.md ├── README.md ├── .gitignore ├── .env.example ├── docs/ │ ├── architecture.md │ ├── deployment.md │ └── backup-restore.md ├── src/ oder app/ ├── tests/ └── .claude/ ├── settings.json ├── rules/ └── skills/ ``

VORLAGE: Diese Struktur ist keine Anthropic-Vorgabe. Sie ist eine abgeleitete Arbeitsvorlage. Die tatsächliche Struktur hängt von Sprache, Framework und Betriebsmodell ab. Anthropic schreibt nur die Lage und Funktion bestimmter Claude-Dateien vor, nicht die gesamte Projektarchitektur. [S007] [S008] [S012]

Was dieses Dossier nicht verspricht

Es gibt keinen universellen Prompt, der aus jeder Idee automatisch ein sicheres, rechtmäßiges, wartbares und wirtschaftliches Produkt erzeugt. Ein Werkzeug kann technische Schritte ausführen, aber es kann fehlende Geschäftsentscheidungen, unklare Verantwortlichkeiten, ungetestete Backups oder unzureichende Rechtekonzepte nicht durch sprachliche Eleganz ersetzen.

Das Dossier bietet deshalb:

• eine nachvollziehbare technische Linie,
• konkrete Start- und Prüfverfahren,
• ein Starterkit mit Projektdateien und Skills,
• klare Sicherheitsgrenzen,
• Varianten für lokale Rechner, NAS und VPS,
• Quellen und Aktualitätshinweise.

\newpage

Was „Vibe Coding“ bedeutet – und was nicht

Herkunft und begriffliche Unschärfe

FAKT: Der Ausdruck „Vibe Coding“ wurde 2025 durch Andrej Karpathy populär. In seiner ursprünglichen, zugespitzten Bedeutung ging es um eine Arbeitsweise, bei der ein Anwender KI-generierten Code weitgehend akzeptiert, ohne ihn vollständig zu lesen oder zu verstehen. Simon Willison wies bereits im März 2025 darauf hin, dass nicht jede KI-unterstützte Programmierung deshalb Vibe Coding sei. [S092] [S093]

Inzwischen wird der Begriff im Markt weiter verwendet. Er kann mindestens drei unterschiedliche Vorgehensweisen bezeichnen:

1. Unkontrolliertes Vibe Coding: Der Benutzer beschreibt einen Wunsch, übernimmt Ergebnisse und reagiert nur auf sichtbare Fehler.
2. KI-unterstützte Entwicklung: Ein Entwickler nutzt KI für Teilaufgaben, prüft Code und integriert ihn in bestehende Verfahren.
3. Agentische Entwicklung: Ein System wie Claude Code erhält Werkzeugzugriff, untersucht ein Repository, verändert mehrere Dateien und verifiziert Ergebnisse.

EMPFEHLUNG: Dieses Dossier verwendet „Vibe Coding“ als leicht verständlichen Oberbegriff, grenzt aber die Zielmethode klar ab. Gemeint ist kontrollierte agentische Softwareentwicklung für fachlich starke Nicht-Programmierer.

Warum die begriffliche Trennung wichtig ist

Wer glaubt, Vibe Coding bedeute nur „Ich sage der KI, was ich will“, unterschätzt die Hälfte der Arbeit. Die eigentliche Produktentwicklung besteht nicht nur aus Quellcode. Sie umfasst auch:

• Anforderungen und Grenzen,
• Datenmodell und Rechte,
• lokale Entwicklungsumgebung,
• Versionsverwaltung,
• Tests und Abnahme,
• Deployment und Konfiguration,
• Backups und Restore,
• Sicherheitsupdates und Betrieb.

Eine funktionierende HTML-Vorschau im Chat ist noch keine veröffentlichte Website. Eine öffentlich erreichbare Website ist noch kein zuverlässig betriebenes System. Ein Login ist noch kein belastbares Rechtekonzept.

Die neue Rollenverteilung

In der klassischen Entwicklung schreibt der Mensch den Großteil des Codes selbst. Bei agentischer Entwicklung verschiebt sich die Arbeit:

EMPFEHLUNG: Der Nicht-Programmierer muss weniger Programmiersyntax lernen, dafür aber bessere Entscheidungen treffen. Die Kernkompetenz lautet nicht „jede Zeile selbst schreiben“, sondern „ein technisches Vorhaben prüfbar führen“.

Drei Qualitätsstufen

Stufe A: Demonstration

Ein Prototyp zeigt eine Idee. Daten können erfunden sein. Verfügbarkeit, Backup und Sicherheit sind nicht produktionsreif. Das ist legitim, sofern es klar benannt wird.

Stufe B: internes Werkzeug

Das System wird in einem begrenzten Umfeld verwendet. Es braucht echte Daten, Benutzerrechte, Backup und Wartung, aber möglicherweise keine öffentliche Skalierung.

Stufe C: öffentliches Produktivsystem

Echte Benutzer verlassen sich auf die Anwendung. Datenschutz, Verfügbarkeit, Missbrauchsschutz, Monitoring, Restore und verantwortliche Freigaben werden zwingend.

EMPFEHLUNG: Jede Projektdefinition sollte die Qualitätsstufe ausdrücklich nennen. Viele Vibe-Coding-Projekte scheitern nicht am Code, sondern daran, dass ein Demonstrator stillschweigend wie ein Produktivsystem behandelt wird.

Was ein Zehntklässler verstehen muss

Einsteiger müssen nicht zuerst Informatik studieren. Sie sollten aber folgende Sätze erklären können:

• Mein Projekt liegt in einem bestimmten Ordner.
• Claude Code arbeitet in diesem Ordner und erhält dort definierte Rechte.
• localhost bezeichnet meinen eigenen Rechner als Netzwerkziel.
• Ein Webserver beantwortet Browseranfragen.
• Git speichert nachvollziehbare Projektstände.
• Ein Remote ist eine weitere Repository-Kopie, nicht automatisch das vollständige Betriebsbackup.
• Eine Domain ist ein Name; DNS weist diesen Namen einem Ziel zu.
• SSH steuert einen entfernten Rechner über eine verschlüsselte Verbindung.
• SFTP überträgt Dateien über SSH.
• Secrets gehören nicht in Git.
• Vor destruktiven Änderungen brauche ich ein nachweislich rückspielbares Backup.
• Produktion ist eine andere Risikoklasse als mein lokaler Rechner.

Wer diese Grundsätze versteht, kann sehr viel technische Umsetzung delegieren, ohne blind zu arbeiten.

\newpage

Was Claude Code tatsächlich leistet

Ein agentisches Werkzeug im Terminal

FAKT: Claude Code läuft als Entwicklungswerkzeug im Terminal und zusätzlich über Integrationen, unter anderem für Visual Studio Code. Es kann den Projektbestand lesen, nach Code suchen, Dateien bearbeiten, Shell-Befehle ausführen und mit Entwicklungswerkzeugen zusammenarbeiten. [S001] [S003] [S017]

Das Terminal ist dabei kein nostalgisches Entwicklerwerkzeug, sondern die gemeinsame Schnittstelle zwischen Mensch, Claude und Betriebssystem:

``text Benutzer beschreibt Ziel ↓ Claude analysiert Projekt ↓ Claude schlägt Werkzeugaufruf vor ↓ Claude Code prüft Berechtigung ↓ Betriebssystem führt Befehl aus ↓ Claude liest Ergebnis ↓ Claude arbeitet weiter ``

Der agentische Zyklus

FAKT: Anthropic beschreibt die Arbeitsweise als Agentenschleife: Kontext sammeln, handeln, Ergebnis überprüfen und bei Bedarf wiederholen. [S005]

Dieser Zyklus wird stark, wenn das Projekt überprüfbare Signale bietet:

• ein Test schlägt fehl oder besteht,
• der Build beendet sich erfolgreich oder mit Fehler,
• ein Linter meldet konkrete Probleme,
• die Anwendung lässt sich starten,
• ein Browserablauf funktioniert,
• ein Screenshot weicht von einer Vorlage ab,
• eine Datenbankmigration läuft oder bricht kontrolliert ab.

EMPFEHLUNG: Jeder Auftrag an Claude sollte nicht nur sagen, was gebaut werden soll, sondern auch, wie der Erfolg festgestellt wird.

Was Claude Code eigenständig tun kann

Abhängig von Berechtigungen und Umgebung kann Claude Code unter anderem:

• Verzeichnisstrukturen untersuchen,
• relevante Dateien finden,
• Abhängigkeiten und Skripte erkennen,
• Quellcode und Dokumentation ändern,
• Tests und Builds ausführen,
• lokale Entwicklungsserver starten,
• Git-Diffs auswerten,
• Branches und Commits vorbereiten,
• externe Werkzeuge über MCP anbinden,
• spezialisierte Skills und Subagents einsetzen. [S001] [S002] [S012–S016]

Was Claude Code nicht automatisch weiß

Claude kennt nicht automatisch:

• den tatsächlichen Geschäftszweck,
• informelle Absprachen,
• rechtliche oder vertragliche Pflichten,
• nicht dokumentierte Produktionszugänge,
• die gewünschte Risikotoleranz,
• die Bedeutung einzelner Kundendaten,
• den letzten wirklich getesteten Backupstand,
• interne Freigabeprozesse,
• ob ein sichtbar funktionierendes Verhalten fachlich korrekt ist.

Claude kann diese Punkte erfragen und dokumentieren. Die Entscheidung und Verantwortung bleiben beim Betreiber.

Berechtigungen sind nicht gleich Fähigkeit

Ein häufiger Denkfehler lautet: „Claude kann SSH, also soll Claude direkt auf dem Produktivserver arbeiten.“ Technische Fähigkeit beantwortet aber nicht die Frage nach dem sinnvollen Zugriff.

Vier Stufen sind zu unterscheiden:

EMPFEHLUNG: Je größer die Auswirkung, desto stärker müssen Bestätigung, Backup, Rollback und getrennte Zugänge sein.

Claude Code, Chat und Weboberfläche

Ein normaler Chat eignet sich besonders für:

• Ideen,
• Fachkonzepte,
• Erklärungen,
• erste Spezifikationen,
• unabhängige Text- oder Codeschnipsel.

Claude Code eignet sich besonders für:

• vorhandene Repositories,
• projektweite Änderungen,
• Terminal- und Git-Arbeit,
• wiederholte Tests,
• konkrete Datei- und Verzeichnisstrukturen,
• dokumentierte Entwicklungsabläufe.

EMPFEHLUNG: Die erste Diskussion darf im normalen Chat beginnen. Spätestens wenn reale Dateien, Versionen und Tests entstehen, sollte die Arbeit in einem klaren Projektordner fortgesetzt werden.

Kosten und Abonnement

FAKT: Claude Code kann je nach aktueller Produktkonfiguration über geeignete Claude-Abonnements oder API-Abrechnung genutzt werden. Anthropic führt eigene Seiten zu Pro-, Max- und Kostenverwaltung. Preise, Nutzungslimits und Inklusivleistungen ändern sich schnell und müssen vor Veröffentlichung aktuell geprüft werden. [S020–S022]

UNKLAR: Ein sinnvoller pauschaler Monatsbetrag für jedes Projekt ist nicht belegbar. Kosten hängen von Modell, Kontextgröße, Arbeitsintensität, Abonnement und möglicher API-Nutzung ab.

Datenschutz und Inhaltszugriff

FAKT: Anthropic veröffentlicht gesonderte Informationen zur Datennutzung und Aufbewahrung für Verbraucher- und andere Produktkontexte. Diese Angaben sind produkt- und kontospezifisch und können sich ändern. [S023] [S024]

EMPFEHLUNG: Vor Arbeit mit Kunden-, Mitarbeiter- oder Produktionsdaten muss geprüft werden, welches Konto, welche Vertragsgrundlage und welche Datenrichtlinie tatsächlich gelten. Technisch mögliche Datei- oder Serverzugriffe sind keine datenschutzrechtliche Freigabe.

\newpage

Die vollständige technische Pipeline

Vom Wunsch zur betriebenen Anwendung

Die vollständige Linie lautet:

```text

1. Idee und Problem
2. Projektinterview
3. SPEC.md
4. Architekturentscheidung
5. Projektordner
6. Git-Repository
7. CLAUDE.md, Rules, Skills, Permissions
8. lokale Entwicklungsumgebung
9. Plan
10. Implementierung
11. automatisierte Prüfung
12. manueller Funktionstest
13. Git-Checkpoint
14. Staging
15. Freigabe
16. Produktions-Deployment
17. DNS und HTTPS
18. Monitoring und Logs
19. Backups und Restore-Test
20. Wartung und nächste Version

```

Das ist keine unnötige Bürokratie. Jeder Schritt beantwortet eine andere Frage:

• Was soll entstehen? – Spezifikation.
• Wie wird es gebaut? – Architektur und Entwicklung.
• Woher wissen wir, dass es funktioniert? – Tests und Abnahme.
• Wie kommt es ins Internet? – Deployment, DNS, HTTPS.
• Wie überlebt es Fehler? – Git, Rollback, Backup, Restore.
• Wer hält es funktionsfähig? – Betrieb und Verantwortlichkeit.

Stufe 1: Idee und Projektinterview

Ein schwacher Startauftrag lautet:

``text Mach mir eine moderne Website für einen Handwerksbetrieb. ``

Das Ergebnis kann optisch ansprechend sein. Es bleiben aber Fragen offen:

• Welche Leistungen?
• Welche Region?
• Welches Ziel der Website?
• Welche Formulare?
• Wo landen Anfragen?
• Werden personenbezogene Daten gespeichert?
• Wer pflegt Inhalte?
• Welche Domain existiert?
• Statisch, CMS oder individuelle Anwendung?
• Wer betreibt Backups?

EMPFEHLUNG: Der erste Claude-Auftrag sollte ausdrücklich noch keine Implementierung verlangen. Er sollte fehlende Entscheidungen ermitteln und eine SPEC.md erzeugen.

Stufe 2: Spezifikation

Eine brauchbare SPEC.md enthält mindestens:

• Problem und Ziel,
• Benutzer und Rollen,
• Muss-/Soll-/Kann-Funktionen,
• Daten und Löschung,
• Schnittstellen,
• technische Randbedingungen,
• Sicherheits- und Datenschutzanforderungen,
• Akzeptanzkriterien,
• Hosting, Backup und Betrieb,
• offene Entscheidungen.

VORLAGE: Das mitgelieferte Starterkit enthält eine solche Struktur. Sie ist bewusst technikneutral.

Stufe 3: Architekturentscheidung

Für eine einfache Firmenwebsite können mehrere Lösungen fachlich richtig sein:

EMPFEHLUNG: Nicht die modernste Technik wählen, sondern die einfachste Architektur, die die Anforderungen zuverlässig erfüllt.

Stufe 4: lokaler Projektaufbau

Das Projekt wird auf dem eigenen Rechner angelegt und versioniert. Claude Code arbeitet im Projektordner. Lokal können Fehler entstehen, ohne sofort echte Benutzer zu treffen.

``text ~/Projekte/mein-projekt/ ``

oder unter Windows beispielsweise:

``text C:\Projekte\mein-projekt\ ``

Stufe 5: Entwicklung in kleinen Einheiten

Eine große Aufgabe wird in überprüfbare Schritte zerlegt:

``text Grundgerüst → Startseite → Navigation → Leistungsseiten → Formular → Tests → Veröffentlichung ``

Nach jedem tragfähigen Abschnitt:

1. Anwendung starten.
2. Tests ausführen.
3. wichtigen Benutzerweg prüfen.
4. Git-Diff ansehen.
5. Commit erzeugen.

Stufe 6: Staging

Staging ist eine möglichst produktionsnahe Testumgebung. Sie wird vor Produktion aktualisiert. Dort können Domain, HTTPS, Datenbank, E-Mail und Serverkonfiguration geprüft werden, ohne die öffentliche Hauptseite sofort zu verändern.

EMPFEHLUNG: Selbst kleine Kundenprojekte profitieren von einer Staging-Subdomain oder einem getrennten Ziel. Das reduziert die Versuchung, direkt auf dem Live-System zu experimentieren.

Stufe 7: Produktion

Produktions-Deployment braucht:

• eine benannte Version oder einen Commit,
• bestandene Prüfungen,
• dokumentierte Konfiguration,
• Backupstatus,
• Rollback- oder Restore-Weg,
• verantwortliche Freigabe,
• Funktionstest nach Veröffentlichung.

EMPFEHLUNG: Produktiv-Deployment als manuellen Skill definieren. Claude darf vorbereiten und prüfen; der Benutzer löst den Seiteneffekt bewusst aus.

Stufe 8: Betrieb

Nach der Veröffentlichung beginnt der Betrieb:

• Softwareupdates,
• Zertifikatserneuerung,
• Logprüfung,
• Backupkontrolle,
• Restore-Tests,
• Speicher- und Datenbankpflege,
• Fehlerbehebung,
• weitere Versionen.

Eine Webseite ist nicht „fertig“, sobald sie einmal online ist. Sie besitzt einen Lebenszyklus.

\newpage

Web- und Computergrundlagen ohne Fachchinesisch

Datei, Ordner und Projekt

Eine Datei enthält Daten, zum Beispiel HTML, CSS, Bilder, Quellcode oder Konfiguration. Ein Ordner gruppiert Dateien. Ein Projekt ist eine fachlich zusammengehörige Sammlung aus Dateien, Abhängigkeiten, Dokumentation und Versionen.

Ein Projektordner ist nicht bloß Ordnung. Er bestimmt:

• welchen Bestand Claude untersucht,
• welche Git-Historie gilt,
• welche CLAUDE.md geladen wird,
• welche Skills und Settings gelten,
• welche Dateien von Befehlen betroffen sind.

Programmcode

Programmcode ist Text in einer formalen Sprache. Der Computer führt ihn nicht aufgrund seiner Bedeutung für Menschen aus, sondern nach festen Regeln. KI kann Code erzeugen, doch der Code bleibt ausführbare technische Anweisung.

Daraus folgt eine einfache Sicherheitsregel:

Je näher ein KI-generierter Befehl an Daten, Servern oder Backups arbeitet, desto weniger darf er blind bestätigt werden.

Frontend und Backend

Frontend bezeichnet den Teil, den ein Benutzer direkt sieht und bedient: Seiten, Formulare, Navigation, Darstellung.

Backend verarbeitet Logik im Hintergrund: Benutzerkonten, Berechtigungen, Datenbankzugriffe, E-Mail-Versand oder externe Schnittstellen.

Eine statische Website kann nur aus Frontend-Dateien bestehen. Ein Kundenportal benötigt typischerweise zusätzlich Backend und Datenbank.

Client und Server

FAKT: Im Web fordert ein Client, meist der Browser, Ressourcen über das Netzwerk an. Ein Server beantwortet diese Anfragen. HTTP definiert den Austausch. [S042] [S044]

``text Browser (Client) ── Anfrage ──> Webserver Browser (Client) <─ Antwort ─── Webserver ``

„Server“ kann zweierlei bedeuten:

• die Software, die Anfragen beantwortet,
• der Rechner oder virtuelle Rechner, auf dem diese Software läuft.

IP-Adresse

Eine IP-Adresse identifiziert ein Netzwerkziel. Im Heimnetz kann eine NAS beispielsweise eine private Adresse wie 192.168.1.50 besitzen. Ein öffentlicher VPS besitzt eine über das Internet erreichbare Adresse.

Private Heimnetzadressen sind normalerweise nicht direkt aus dem Internet erreichbar. Für öffentlichen Zugriff wären zusätzliche Router-, Firewall- und Sicherheitsentscheidungen erforderlich.

Port

Ein Port unterscheidet Dienste auf derselben IP-Adresse. Typische Beispiele:

• Port 80: HTTP,
• Port 443: HTTPS,
• Port 22: SSH,
• Port 3000 oder 5173: häufig lokale Entwicklungsserver, abhängig vom Framework.

Eine Adresse wie:

``text http://localhost:3000 ``

bedeutet: HTTP-Verbindung zum eigenen Rechner auf Port 3000.

localhost

localhost bezeichnet den eigenen Rechner. Die Anwendung ist damit zunächst nur lokal erreichbar, sofern sie nicht zusätzlich an eine Netzwerkadresse gebunden oder freigegeben wird.

Das ist für Anfänger ideal:

• keine Domain erforderlich,
• keine öffentliche Angriffsfläche,
• schnelle Änderungen,
• einfache Fehlersuche.

Webserver und Entwicklungsserver

Ein Webserver liefert Inhalte über HTTP oder HTTPS aus. Apache ist ein klassischer Webserver. Viele moderne Frameworks bringen für die Entwicklung einen eigenen Entwicklungsserver mit.

FAKT: Pythons http.server kann Dateien einfach über HTTP ausliefern, die Python-Dokumentation warnt jedoch ausdrücklich, dass das Modul nicht für Produktion empfohlen wird. [S047]

EMPFEHLUNG: Für lokale Entwicklung den vom Projekt vorgesehenen Entwicklungsserver verwenden. Apache erst einsetzen, wenn das Projekt Apache benötigt, etwa für klassische PHP-Anwendungen, lokale Produktionsnähe oder ein NAS-Webportal.

Domain und DNS

FAKT: Eine Domain ist ein menschenlesbarer Name. DNS löst Namen in technische Zielinformationen auf. [S042] [S043]

``text www.beispiel.de ↓ DNS 203.0.113.10 ↓ Webserver ``

Wichtig: Ein Virtual Host in Apache erzeugt keinen DNS-Eintrag. Domainverwaltung und Webserverkonfiguration sind zwei getrennte Schritte. [S046]

HTTP und HTTPS

HTTP überträgt Webanfragen und Antworten. HTTPS verwendet TLS, um die Verbindung zu verschlüsseln und die Serveridentität über ein Zertifikat zu bestätigen.

Let’s Encrypt kann Zertifikate automatisiert ausstellen, wenn der Betreiber die Kontrolle über die Domain nachweist. Je nach Challenge-Typ gelten unterschiedliche Voraussetzungen. HTTP-01 verwendet typischerweise Port 80; DNS-01 arbeitet über DNS-Einträge und ermöglicht auch Wildcard-Zertifikate. [S049]

Statisch und dynamisch

Statische Website

Der Server liefert vorhandene Dateien aus:

``text index.html styles.css app.js bilder/ ``

Dynamische Anwendung

Eine Anfrage wird verarbeitet:

``text Browser ↓ Backend ↓ Datenbank ↓ individuelle Antwort ``

Je mehr dynamische Bestandteile, desto mehr Betriebsaufgaben entstehen: Datenbank, Secrets, Migrationen, Backups, Rechte und Updates.

Entwicklungs-, Staging- und Produktionsumgebung

EMPFEHLUNG: Umgebungen nicht nur durch verschiedene URLs, sondern auch durch getrennte Zugangsdaten, Datenbanken und Konfigurationen unterscheiden.

\newpage

Die richtige Arbeitsumgebung: Rechner, NAS oder VPS

Vier realistische Varianten

Variante A: eigener Windows-Rechner

Geeignet für:

• Einsteiger,
• lokale Websites und Anwendungen,
• schnelle Lernschritte,
• Arbeit mit VS Code und Browser.

Vorteile:

• vorhandene Hardware,
• direkter Zugriff,
• keine öffentliche Serveradministration,
• einfache lokale Tests.

Nachteile:

• Windows-, PowerShell- und Git-Bash-Unterschiede,
• mögliche Pfad- und Zeilenendungsprobleme,
• Rechner muss für lokale Dienste laufen.

Variante B: eigener Mac

Geeignet für dieselben Aufgaben. macOS besitzt eine Unix-nahe Kommandozeilenumgebung und wird von Claude Code nativ unterstützt. [S002] [S003]

Vorteile:

• Bash/Zsh-orientierte Werkzeuge,
• viele Serverbefehle ähneln Linux,
• gute lokale Entwicklungsumgebung.

Nachteile:

• Produktions-Linux bleibt trotzdem ein anderes System,
• systemweite Pakete und Rechte müssen weiterhin verstanden werden.

Variante C: Synology NAS

Geeignet als:

• interner Webserver,
• lokales Testziel,
• Container-Host bei unterstützten Modellen,
• privates Git- oder Dateiziel,
• Backup- und Snapshot-System. [S051–S057]

Nicht pauschal geeignet als:

• universelle Entwicklungsmaschine,
• öffentlich exponierter Server für jedes Projekt,
• Ersatz für ein externes Backup,
• Plattform für ungeprüfte Shell-Eingriffe in DSM.

Variante D: VPS

Geeignet, wenn:

• eine Anwendung öffentlich und dauerhaft erreichbar sein soll,
• eigene Serverkontrolle erforderlich ist,
• der Betreiber Updates, Firewall, Backups und Monitoring übernimmt.

Nachteile:

• höchste Betriebsverantwortung,
• öffentliche Angriffsfläche,
• Fehler können echte Benutzer treffen,
• laufende Pflege erforderlich.

Empfohlener Einstiegspfad

EMPFEHLUNG:

``text Windows oder Mac lokal ↓ optional Synology im Heimnetz ↓ Staging auf Hosting/VPS ↓ Produktion ``

Dieser Pfad verhindert, dass ein Anfänger gleichzeitig Code, Git, Linux, DNS, HTTPS, Firewall und Backup lernen muss.

Windows: native Nutzung oder WSL2

FAKT: Claude Code unterstützt Windows nativ. Anthropic empfiehlt unter nativem Windows Git for Windows; aktuelle Versionen können je nach Umgebung auch PowerShell nutzen. WSL2 ist eine weitere unterstützte Option. Anthropic empfiehlt bei WSL, Projekte im Linux-Dateisystem der WSL-Distribution abzulegen, statt im eingehängten Windows-Dateisystem, unter anderem wegen Werkzeug- und Dateiwächterverhalten. WSL1 wird nicht unterstützt. [S002] [S003]

Native Windows-Nutzung

Geeignet für Benutzer, die:

• PowerShell oder Git Bash verwenden,
• ihre Projekte unter C:\Projekte verwalten,
• keine Linux-Umgebung benötigen.

WSL2

Geeignet, wenn:

• das Projekt stark Linux-orientiert ist,
• Docker/Linux-Werkzeuge genutzt werden,
• Produktionsnähe wichtiger wird.

Typischer WSL-Pfad:

``text /home/andreas/projekte/mein-projekt ``

statt:

``text /mnt/c/Projekte/mein-projekt ``

für performance- und watcherintensive Projekte. [S003]

macOS

Claude Code unterstützt aktuelle macOS-Versionen gemäß der jeweils aktuellen Systemanforderung. Die Installation kann nativ oder über unterstützte Paketwege erfolgen. [S002] [S003]

Empfohlener Projektpfad:

``text ~/Projekte/mein-projekt ``

Nicht empfohlen:

• Projekte unstrukturiert auf dem Desktop verteilen,
• produktive Schlüssel im Projektordner ablegen,
• systemweite Befehle ohne Verständnis mit sudo bestätigen.

NAS als „Mini-Heimserver“

Die Synology-Idee ist didaktisch stark, weil sie Serverkonzepte sichtbar macht:

``text Arbeitsrechner ↓ LAN Synology NAS ↓ Web Station oder Container Browser auf Notebook/Tablet/Telefon ``

Der Benutzer lernt:

• IP-Adresse im Heimnetz,
• Dienst und Port,
• Webroot oder Container,
• Netzwerkzugriff,
• Backup und Snapshot.

EMPFEHLUNG: Claude Code selbst zunächst auf dem Arbeitsrechner ausführen. Das Projekt kann anschließend kontrolliert auf die NAS übertragen oder dort in einem Container gestartet werden. Direkte Entwicklung im DSM-System ist nicht der Standardweg.

VPS als Produktionsziel

Ein VPS ist kein „Ordner im Internet“, sondern ein eigener virtueller Rechner. Typische Bestandteile:

``text Ubuntu/Linux ├── Benutzer und SSH ├── Firewall ├── Webserver/Reverse Proxy ├── Runtime oder Docker ├── Anwendung ├── Datenbank oder externer DB-Dienst ├── Logs ├── Backups └── Updates ``

FAKT: Ubuntu dokumentiert OpenSSH, UFW, automatische Updates, AppArmor und Paketverwaltung als getrennte Betriebsbausteine. [S066–S071]

EMPFEHLUNG: Ein VPS sollte erst eingesetzt werden, wenn eine verantwortliche Person regelmäßige Pflege, Monitoring und Restore übernimmt.

Entscheidungsbaum

```text Nur lernen oder Prototyp? └─ Ja → eigener Rechner

Im Heimnetz auf mehreren Geräten testen? └─ Ja → Rechner im LAN oder Synology

Öffentlich, aber ohne eigene Serverpflege? └─ Ja → Managed Hosting/Plattform prüfen

Eigene Serverkontrolle erforderlich und Betriebskompetenz vorhanden? └─ Ja → VPS ```

Was vor der Hardwarewahl geklärt werden muss

• statische Website oder dynamische Anwendung,
• erwartete Nutzerzahl,
• personenbezogene/vertrauliche Daten,
• benötigte Datenbank,
• E-Mail-Versand,
• Datei-Uploads,
• Verfügbarkeit,
• Wartungsverantwortung,
• Backupziel und Restore,
• Budget,
• gewünschte Anbieterunabhängigkeit.

Ohne diese Angaben ist die Aussage „Synology, VPS oder eigener Rechner ist am besten“ UNKLAR.

\newpage

Software und Installation unter Windows und macOS

Die Minimalsoftware

Für den ersten kontrollierten Start genügen:

Nicht am ersten Tag erforderlich:

• Docker,
• Apache,
• Datenbankserver,
• VPS,
• Synology,
• FTP-Client,
• CI/CD.

Diese Werkzeuge werden erst installiert, wenn die gewählte Architektur sie wirklich benötigt.

Systemanforderungen von Claude Code

FAKT: Zum Stand 08.08.2026 nennt Anthropic unter anderem macOS 13+, Windows 10 ab Version 1809 beziehungsweise Windows Server 2019+, Ubuntu 20.04+, Debian 10+ und Alpine 3.19+. Genannt werden mindestens 4 GB RAM, x64- oder ARM64-Prozessor, Internetverbindung und eine unterstützte Shell wie Bash, Zsh, PowerShell oder CMD. [S003]

Refresh nötig: Systemanforderungen gehören zu den schnell veraltenden Angaben. Vor Installation stets die aktuelle Setup-Seite prüfen.

Claude Code unter Windows installieren

FAKT: Anthropic empfiehlt aktuell die native Installation. In PowerShell lautet der offizielle Befehl: [S002] [S003]

``powershell irm https://claude.ai/install.ps1 | iex ``

Unter der klassischen Windows-Eingabeaufforderung dokumentiert Anthropic: [S002]

``cmd curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd ``

Alternativ steht WinGet zur Verfügung: [S002]

``powershell winget install Anthropic.ClaudeCode ``

WinGet-Installationen aktualisieren sich laut aktueller Dokumentation nicht automatisch. Der dokumentierte Updateweg lautet: [S002]

``powershell winget upgrade Anthropic.ClaudeCode ``

Verifikation

``powershell claude --version ``

Die Ausgabe muss eine Versionsnummer und den Hinweis auf Claude Code enthalten. [S002]

PowerShell oder CMD erkennen

Anthropic weist auf einen häufigen Anfängerfehler hin: PowerShell zeigt typischerweise ein Präfix wie PS C:\, CMD dagegen C:\. Ein PowerShell-Befehl funktioniert nicht automatisch in CMD und umgekehrt. [S002]

Git for Windows

FAKT: Anthropic empfiehlt Git for Windows bei nativer Windows-Nutzung, damit Claude Code das Bash-Werkzeug verwenden kann. Ohne Git for Windows kann Claude Code in aktuellen Versionen PowerShell als Shell-Werkzeug nutzen. WSL benötigt Git for Windows nicht. [S002] [S003]

Git kann über die offizielle Git-Distribution oder einen Paketmanager installiert werden. Die Git-Dokumentation nennt die jeweiligen Plattformwege. [S030]

Nach der Installation:

``powershell git --version ``

Claude Code unter macOS installieren

Die aktuell empfohlene native Installation lautet: [S002] [S003]

``bash curl -fsSL https://claude.ai/install.sh | bash ``

Alternativ über Homebrew: [S002]

``bash brew install --cask claude-code ``

Anthropic unterscheidet derzeit einen stabilen Cask und einen neuesten Kanal. Homebrew-Installationen aktualisieren sich laut Dokumentation nicht automatisch. [S002] [S003]

Update des stabilen Casks:

``bash brew upgrade claude-code ``

Verifikation:

``bash claude --version ``

Warum Installationsbefehle nicht blind übernommen werden sollten

Ein Befehl wie:

``bash curl ... | bash ``

lädt Inhalt aus dem Internet und führt ihn aus. Dass dieser Weg vom Hersteller dokumentiert wird, ist ein starkes Herkunftssignal, aber keine allgemeine Erlaubnis, beliebige Skripte so auszuführen.

EMPFEHLUNG:

1. Domain und Quelle prüfen.
2. Nur den aktuellen Herstellerbefehl verwenden.
3. Bei Unternehmensgeräten interne IT-Vorgaben beachten.
4. Keine ähnlich aussehenden Befehle aus Foren, Anzeigen oder unbekannten Repositories übernehmen.
5. Nach Installation Version und Herkunft prüfen.

Anmeldung und erster Start

FAKT: Beim ersten Start mit claude führt Claude Code durch die Anmeldung. Unterstützt werden je nach aktuellem Angebot unter anderem geeignete Claude-Abonnements, Console-Konten und bestimmte Cloudanbieter. [S002]

``bash claude ``

Für den Projektstart:

``bash cd pfad/zum/projekt claude ``

Unter Windows PowerShell beispielsweise:

``powershell cd C:\Projekte\meine-webseite claude ``

Unter macOS:

``bash cd ~/Projekte/meine-webseite claude ``

VS Code

FAKT: Claude Code bietet eine Integration für Visual Studio Code. Sie unterstützt unter anderem Projektkontext und Diff-Ansichten. Die genauen Funktionen und Mindestversionen ändern sich und sind aktuell zu prüfen. [S017]

EMPFEHLUNG: VS Code ist für Anfänger sinnvoll, weil der Benutzer:

• den Projektbaum sieht,
• Änderungen farblich vergleichen kann,
• Dateien nicht nur über Terminalausgaben wahrnimmt,
• integrierte Terminals verwenden kann.

VS Code ist jedoch kein Ersatz für Git, Tests oder Dokumentation.

Projektspezifische Runtime

Claude Code ist nicht automatisch Node.js, Python, PHP oder Java. Das Projekt benötigt die Laufzeitumgebung seiner gewählten Technik.

Beispiele:

EMPFEHLUNG: Runtime und Version erst nach Architekturentscheidung installieren. Version in README.md, CLAUDE.md oder einer projektspezifischen Versionsdatei dokumentieren.

Installationsprüfung als erster Claude-Auftrag

VORLAGE:

```text Untersuche nur meine lokale Entwicklungsumgebung. Installiere noch nichts.

Prüfe:

• Betriebssystem und Shell,
• Claude-Code-Version,
• Git-Version und Git-Konfiguration,
• vorhandene projektbezogene Runtime,
• den aktuellen Projektpfad,
• ob ein Git-Repository vorhanden ist,
• ob sensible Dateien sichtbar oder versioniert sind.

Erkläre jeden fehlenden Bestandteil in einfacher Sprache. Zeige für jede notwendige Installation ausschließlich den aktuellen offiziellen Herstellerweg und fordere vor systemweiten Änderungen meine Bestätigung an. ```

Dieser Prompt ist eine eigene Vorlage. Er folgt dem Grundsatz, zunächst Kontext zu sammeln und erst danach zu handeln. [S005] [S006]

Häufige Installationsfehler

claude wird nicht gefunden

Mögliche Ursachen:

• Terminal nach Installation nicht neu geöffnet,
• Installationspfad nicht in PATH,
• falsche Shell,
• Installation abgebrochen,
• Unternehmensrichtlinie blockiert Ausführung.

Prüfung:

``bash claude --version ``

und anschließend die offizielle Troubleshooting-Dokumentation nutzen.

Git wird nicht gefunden

``bash git --version ``

Bei Windows zusätzlich prüfen, ob Git Bash beziehungsweise Git for Windows korrekt installiert ist.

Falscher Projektordner

``bash pwd ``

beziehungsweise in PowerShell:

``powershell Get-Location ``

Claude sollte nicht aus dem Benutzerhauptverzeichnis oder einem Ordner gestartet werden, der viele unabhängige Projekte und private Dateien enthält.

WSL-Projekt liegt auf C:

Bei WSL2 empfiehlt Anthropic, aktive Projekte im Linux-Dateisystem zu speichern. [S003]

\newpage

Terminal-Grundlagen

Was ein Terminal ist

Das Terminal ist eine textbasierte Oberfläche zum Betriebssystem. Die Shell interpretiert Befehle. Unter Windows sind PowerShell, CMD und Git Bash verbreitet; unter macOS typischerweise Zsh beziehungsweise Bash-kompatible Werkzeuge.

Das Terminal zeigt meistens:

``text aktueller Pfad > Eingabemarke ``

Der wichtigste Anfängerfehler ist nicht ein komplizierter Befehl, sondern Arbeit im falschen Ordner.

Die fünf wichtigsten Befehlsgruppen

Aktuellen Ort anzeigen

macOS/Linux/Git Bash:

``bash pwd ``

PowerShell:

``powershell Get-Location ``

Inhalt anzeigen

macOS/Linux/Git Bash:

``bash ls ``

PowerShell:

``powershell Get-ChildItem ``

ls funktioniert in PowerShell häufig ebenfalls als Alias, sollte in Dokumentation aber nicht mit identischer Semantik über alle Umgebungen vorausgesetzt werden.

Ordner wechseln

``bash cd mein-projekt ``

Eine Ebene höher:

``bash cd .. ``

Ordner erstellen

``bash mkdir mein-projekt ``

Programm starten

``bash claude ``

oder projektspezifisch etwa:

``bash npm run dev ``

Pfade verstehen

Absoluter Pfad

Windows:

``text C:\Projekte\kunde-a\website ``

macOS/Linux:

``text /Users/andreas/Projekte/kunde-a/website ``

Relativer Pfad

``text ./src/index.html ``

./ bedeutet: ausgehend vom aktuellen Ordner.

../ bedeutet: eine Ebene höher.

Leerzeichen und Anführungszeichen

Ein Pfad mit Leerzeichen muss oft in Anführungszeichen gesetzt werden:

``bash cd "Mein Projekt" ``

EMPFEHLUNG: Projektordner möglichst ohne problematische Sonderzeichen und mit klaren Namen anlegen:

``text kunde-a-website ``

statt:

``text Website NEU final wirklich final 3 ``

Befehle verbinden

Shells besitzen Operatoren wie &&, ;, Pipes und Umleitungen. Diese können mehrere Wirkungen in einem Befehl bündeln.

Beispiel:

``bash npm test && npm run build ``

Der Build läuft nur, wenn der Test erfolgreich war.

WARNUNG: Verbundene Befehle erschweren die Berechtigungsprüfung. Ein harmlos beginnender Befehl kann nach &&, ; oder | weitere Aktionen ausführen. Claude-Code-Permissions und Hooks müssen deshalb die aktuelle Syntax und Grenzen berücksichtigen. [S009] [S013]

sudo und Administratorrechte

sudo unter macOS/Linux und „Als Administrator ausführen“ unter Windows erhöhen Rechte.

EMPFEHLUNG: Claude niemals routinemäßig mit Administratorrechten betreiben. Systemweite Änderungen nur durchführen, wenn:

• Zweck verstanden ist,
• Herstellerquelle feststeht,
• Befehl geprüft wurde,
• eine Rücknahme möglich ist.

Terminalausgaben lesen

Fehlerausgaben enthalten meist:

• Befehl,
• Fehlercode,
• betroffene Datei oder Zeile,
• Ursache oder Folgefehler.

Ein guter Fehlerauftrag an Claude lautet nicht:

``text Geht nicht. Reparier. ``

sondern:

```text Der folgende Befehl schlägt fehl: [Befehl]

Vollständige Ausgabe: [Ausgabe]

Untersuche zuerst Ursache und betroffene Umgebung. Ändere noch nichts. Nenne die wahrscheinlichste Ursache, Alternativen und den kleinsten Prüfschritt. ```

Prozesse beenden

Ein gestarteter Entwicklungsserver läuft oft, bis er beendet wird. Im Vordergrund funktioniert typischerweise:

``text Strg + C ``

Wenn ein Port weiter belegt ist, muss der betreffende Prozess ermittelt werden. Die genauen Befehle unterscheiden sich zwischen Windows, macOS und Linux.

EMPFEHLUNG: Claude darf den Prozess identifizieren. Es sollte nicht pauschal alle Prozesse eines Namens oder alle Portnutzer beenden, wenn deren Zugehörigkeit unklar ist.

Die Sicherheitsfrage vor jedem Befehl

Vor Bestätigung eines Befehls vier Fragen stellen:

1. Wo wirkt er?
2. Was liest, ändert oder löscht er?
3. Welche Rechte verwendet er?
4. Wie wird die Wirkung rückgängig gemacht?

Diese vier Fragen genügen, um einen großen Teil typischer Vibe-Coding-Fehler zu vermeiden.

\newpage

Git, GitHub und Rücksprungpunkte

Git in einem Satz

Git ist ein verteiltes Versionsverwaltungssystem. Es speichert nachvollziehbare Zustände und Änderungen eines Projekts. Ein Git-Repository kann lokal vollständig funktionieren; GitHub ist ein möglicher Onlinedienst für solche Repositories. [S030–S035]

Die wichtigsten Begriffe

Repository

Der Projektbestand einschließlich Git-Historie.

Working Tree

Die aktuell sichtbaren Dateien, an denen gearbeitet wird.

Staging Area

Auswahl der Änderungen, die in den nächsten Commit aufgenommen werden sollen.

Commit

Ein benannter, nachvollziehbarer Projektzustand.

Branch

Eine Entwicklungslinie, auf der Änderungen unabhängig vorbereitet werden können.

Remote

Ein anderes Git-Repository, etwa auf GitHub, GitLab, einer NAS oder einem eigenen Server. [S033]

Clone

Eine lokale Kopie eines vorhandenen Repositories einschließlich Historie.

Neues Repository anlegen

Im Projektordner:

``bash git init ``

FAKT: git init erzeugt ein neues Git-Repository beziehungsweise initialisiert die nötige Git-Struktur. [S031]

Danach:

``bash git status ``

Erste Identität konfigurieren

Git-Commits enthalten Autorinformationen. Typisch:

``bash git config --global user.name "Andreas Rüdiger" git config --global user.email "[email protected]" ``

EMPFEHLUNG: In Unternehmen prüfen, welche E-Mail-Adresse und Datenschutzvorgaben gelten. Die Werte werden in Commit-Metadaten sichtbar.

.gitignore

.gitignore beschreibt Dateien und Ordner, die Git bei unversionierten Dateien ignorieren soll. [S032]

Typische Einträge:

``gitignore .env node_modules/ dist/ backups/ *.log ``

WICHTIGER FAKT: .gitignore entfernt keine Datei, die bereits versioniert wurde. Das Ignorieren wirkt nicht rückwirkend auf verfolgte Dateien. [S032]

Wenn ein Secret bereits committed wurde, sind mindestens zwei Aufgaben getrennt zu behandeln:

1. Secret sperren oder rotieren.
2. Datei beziehungsweise Wert aus aktuellem Bestand und gegebenenfalls Historie entfernen. [S041] [S083]

Nur .gitignore nachzutragen genügt nicht.

Ein Commit in verständlichen Schritten

``bash git status git diff git add <dateien> git commit -m "Kontaktformular mit Validierung ergänzen" ``

Claude kann diese Schritte ausführen. Der Benutzer sollte vor dem Commit wissen:

• welche Dateien geändert wurden,
• warum sie geändert wurden,
• welche Tests ausgeführt wurden,
• ob unbeabsichtigte Dateien enthalten sind.

Gute Commit-Größe

Ein Commit sollte eine zusammenhängende, überprüfbare Änderung abbilden.

Schlecht:

``text Website komplett fertig ``

Besser:

``text Startseiten-Grundgerüst anlegen Navigation responsiv machen Kontaktformular serverseitig validieren Backup-Handbuch ergänzen ``

EMPFEHLUNG: Nach jedem tragfähigen Teilziel committen, nicht nach jedem einzelnen Zeichen und nicht erst nach mehreren Tagen unübersichtlicher Arbeit.

Branches

Ein Branch erlaubt parallele Arbeit:

``text main ├─ feature/kontaktformular └─ fix/mobile-navigation ``

Für kleine Einzelprojekte kann eine einfache Strategie genügen:

• main bleibt funktionsfähig,
• größere Änderungen entstehen auf einem Feature-Branch,
• nach Prüfung werden sie zusammengeführt.

Git Worktrees

FAKT: Git Worktrees erlauben, mehrere Arbeitsverzeichnisse mit verschiedenen Branches desselben Repositories parallel zu verwenden. [S034]

Das kann bei parallelen Claude-Sitzungen nützlich sein, ist aber kein Anfängerpflichtwissen. Ohne klare Trennung können mehrere Agenten dieselben Dateien überschreiben.

EMPFEHLUNG: Erst verwenden, wenn normale Branches verstanden sind.

GitHub oder eigener Remote

GitHub ist praktisch für:

• externe Repository-Kopie,
• Zusammenarbeit,
• Pull Requests,
• Regeln und Codeprüfung,
• CI/CD,
• Secret Scanning und Push Protection, abhängig von Plan und Repositorytyp. [S037–S040]

Eine Synology oder ein eigener Git-Server kann mehr Datenkontrolle bieten, verlangt aber Betrieb und Backup.

SSH für GitHub

FAKT: GitHub unterstützt SSH-Schlüssel zur Authentifizierung. Der private Schlüssel verbleibt beim Benutzer; der öffentliche Schlüssel wird beim Dienst hinterlegt. [S036]

Typischer Aufbau:

``text Privater Schlüssel: ~/.ssh/id_ed25519 Öffentlicher Schlüssel: ~/.ssh/id_ed25519.pub ``

Der private Schlüssel darf nicht:

• in Git,
• in CLAUDE.md,
• in Chatnachrichten,
• in Screenshots,
• auf einen öffentlichen Server kopiert werden.

Branchschutz und Rulesets

FAKT: GitHub bietet Rulesets und Branchregeln, mit denen beispielsweise direkte Änderungen, erforderliche Prüfungen oder Review-Anforderungen kontrolliert werden können. Verfügbarkeit und Details sind plan- und produktspezifisch. [S037]

EMPFEHLUNG: Bei produktiven Teamprojekten main nicht als freie Experimentierfläche behandeln. Mindestens Tests und ein nachvollziehbarer Freigabeweg sollten vor Merge oder Deployment stehen.

Git als Backup – was stimmt und was nicht

Was Git gut schützt

• Quellcode,
• Textkonfiguration ohne Secrets,
• Dokumentation,
• Historie,
• Branches und Tags.

Was Git typischerweise nicht schützt

• laufende Datenbankdaten,
• hochgeladene Kundendateien,
• lokale .env-Werte,
• Serverzustand,
• Docker-Volumes,
• E-Mail-Postfächer,
• externe SaaS-Daten.

FAKT: GitHub dokumentiert für Disaster Recovery zusätzliche Repository-Sicherungsverfahren, etwa Mirror-Kopien. [S035]

Empfohlenes Git-Minimum für Anfänger

Der Benutzer muss zunächst nur diese Kommandos erkennen:

``bash git status git diff git log --oneline git add git commit git branch git switch git pull git push ``

Er muss sie nicht alle auswendig beherrschen. Er muss wissen, welche Wirkung Claude gerade vorschlägt.

Git-Prompt für Claude

VORLAGE:

```text Prüfe den aktuellen Git-Stand. Verändere noch nichts.

1. Zeige git status.
2. Fasse den vollständigen Diff nach fachlichen Änderungen zusammen.
3. Markiere unklare, fremde oder möglicherweise sensible Dateien.
4. Nenne die Tests, die vor einem Commit fehlen.
5. Schlage eine präzise Commit-Aufteilung und Commit-Nachrichten vor.

Erstelle keinen Commit, keinen Tag und keinen Push ohne meine ausdrückliche Bestätigung. ```

Rückkehr zu einem früheren Zustand

Git bietet mehrere Wege, Änderungen zu verwerfen, Commits rückgängig zu machen oder einen früheren Stand wiederherzustellen. Die richtige Methode hängt davon ab, ob Änderungen bereits veröffentlicht wurden und ob Historie erhalten bleiben soll.

EMPFEHLUNG: Anfänger sollten nicht mit reset --hard, Force Push oder Historienbereinigung experimentieren. Claude soll zuerst erklären:

• welchen Zustand es ändern will,
• ob nicht veröffentlichte Arbeit verloren geht,
• ob ein neuer Revert-Commit sicherer ist,
• ob eine Backupkopie existiert.

\newpage

Der professionelle Projektordner

Warum ein Projekt pro Ordner

Ein einzelner Projektordner begrenzt:

• Dateizugriff,
• Git-Historie,
• Abhängigkeiten,
• Claude-Kontext,
• Regeln und Skills,
• Deployment- und Backupdokumentation.

Mehrere Kundenprojekte in demselben Repository führen leicht zu:

• falschen Änderungen,
• vermischten Secrets,
• unklaren Deployments,
• gemeinsamen Abhängigkeiten ohne Absicht,
• schwer rückspielbarer Historie.

Eine technikneutrale Grundstruktur

``text mein-projekt/ ├── README.md ├── SPEC.md ├── CLAUDE.md ├── CHANGELOG.md ├── .gitignore ├── .env.example ├── docs/ │ ├── architecture.md │ ├── deployment.md │ ├── backup-restore.md │ └── decisions/ ├── src/ oder app/ ├── tests/ └── .claude/ ├── settings.json ├── rules/ └── skills/ ``

VORLAGE: Diese Struktur ist eine Arbeitsvorlage, keine Norm. Ein Framework kann andere Ordner vorgeben.

README.md

Die README beantwortet für Menschen:

• Was ist das Projekt?
• Wie wird es installiert?
• Wie wird es lokal gestartet?
• Wie werden Tests ausgeführt?
• Welche Konfiguration wird benötigt?
• Wo stehen Deployment und Backup?

Eine README darf keine echten Secrets enthalten.

SPEC.md

Die Spezifikation beantwortet:

• Was soll das Produkt fachlich leisten?
• Für wen?
• Welche Daten und Rechte gibt es?
• Welche Akzeptanzkriterien gelten?
• Was gehört nicht zum Projekt?

Sie schützt vor dem typischen Drift, bei dem Claude während der Entwicklung immer neue Funktionen ergänzt, ohne dass deren Nutzen oder Betrieb geklärt ist.

docs/architecture.md

Architekturdokumentation muss nicht akademisch sein. Sie sollte erklären:

``text Browser ↓ HTTPS Webanwendung ↓ Datenbank ↓ Backup ``

Zusätzlich:

• externe APIs,
• Vertrauensgrenzen,
• Datenflüsse,
• Authentifizierung,
• Dateispeicher,
• öffentliche und interne Komponenten.

Architekturentscheidungen als ADR

Ein Architecture Decision Record hält eine folgenreiche Entscheidung fest:

• Kontext,
• gewählte Variante,
• Alternativen,
• Folgen,
• mögliche Rücknahme.

Beispiel:

``text ADR 0001: PostgreSQL statt SQLite für Produktion ``

Das verhindert, dass Claude eine frühere Entscheidung später ohne Kenntnis der Gründe ersetzt.

.env.example

.env.example enthält Variablennamen ohne echte Geheimwerte:

``dotenv APP_URL=http://localhost:3000 DATABASE_URL= MAIL_PASSWORD= SESSION_SECRET= ``

Die echte .env bleibt lokal beziehungsweise wird durch ein Secret-System ersetzt.

Projektstart-Skill statt Mega-Prompt

Ein Start-Skill kann prüfen:

• Ist Git eingerichtet?
• Gibt es eine Spezifikation?
• Sind .gitignore und .env.example vorhanden?
• Sind Start, Test und Build dokumentiert?
• Gibt es Backup- und Deploymenthandbuch?
• Sind Claude-Settings vorsichtig konfiguriert?

EMPFEHLUNG: Der Skill darf nicht pauschal systemweite Software installieren. Er soll erkennen, erklären, Plan und Diff erzeugen und vor privilegierten Änderungen fragen.

Monorepo oder mehrere Repositories

Ein Monorepo enthält mehrere zusammengehörige Anwendungen oder Pakete in einem Repository. Das kann sinnvoll sein, wenn Frontend, Backend und gemeinsame Bibliotheken eng zusammengehören.

Für Anfänger gilt:

• ein Produkt mit einer Anwendung: einfaches Repository,
• mehrere unabhängige Kunden: getrennte Repositories,
• Monorepo nur bei begründetem gemeinsamen Lebenszyklus.

Projektname und Pfad

Ein guter Projektname ist:

• kurz,
• eindeutig,
• ohne Kundengeheimnis,
• ohne Leerzeichen oder problematische Sonderzeichen,
• dauerhaft verständlich.

Beispiel:

``text musterbau-website ``

statt:

``text Neues Projekt 7 final ``

\newpage

CLAUDE.md, Rules und Auto Memory

Funktion von CLAUDE.md

FAKT: Claude Code lädt CLAUDE.md-Dateien als persistenten Kontext. Sie eignen sich für Projektarchitektur, Build- und Testbefehle, Konventionen, Projektlayout und dauerhafte Arbeitsregeln. [S007]

FAKT: Anthropic beschreibt CLAUDE.md und Auto Memory ausdrücklich als Kontext, nicht als technisch erzwungene Konfiguration. Für das Blockieren einer Aktion werden beispielsweise Permissions oder PreToolUse-Hooks benötigt. [S007] [S009] [S013]

Was hinein gehört

Gute Inhalte:

• Zweck des Projekts,
• verlässliche Start-, Test- und Buildbefehle,
• ungewöhnliche Architekturentscheidungen,
• Namens- und Codekonventionen,
• Umgang mit Dokumentation,
• Git- und Freigaberegeln,
• bekannte Stolperstellen,
• Hinweise auf SPEC.md und Betriebsdokumentation.

Beispiel:

```markdown

Projekt

Kundenportal für Muster GmbH. Fachliche Quelle ist SPEC.md.

Befehle

• Entwicklung: npm run dev
• Tests: npm test
• Build: npm run build

Regeln

• Keine Commits oder Deployments ohne ausdrücklichen Auftrag.
• Neue Endpunkte benötigen Validierung und Tests.
• Datenbankänderungen benötigen Migration und Rollback-Hinweis.

```

Was nicht hinein gehört

Nicht hinein gehören:

• Passwörter,
• API-Schlüssel,
• private SSH-Schlüssel,
• Produktionsdaten,
• vollständige API-Dokumentationen,
• lange Tutorials,
• jede einzelne Datei des Projekts,
• mehrstufige Verfahren, die nur gelegentlich gebraucht werden.

FAKT: Anthropic empfiehlt, CLAUDE.md unter ungefähr 200 Zeilen zu halten und Verfahren beziehungsweise pfadspezifische Regeln auszulagern. [S007]

/init

FAKT: Claude Code kann mit /init einen Projektbestand analysieren und eine initiale CLAUDE.md erstellen beziehungsweise den Start unterstützen. [S006] [S007]

EMPFEHLUNG: /init nicht als unfehlbaren Generator behandeln. Die erzeugte Datei muss geprüft, gekürzt und um tatsächliche fachliche Regeln ergänzt werden.

Ablageorte und Geltungsbereiche

FAKT: Claude Code unterstützt CLAUDE.md auf unterschiedlichen Ebenen, darunter Organisation, Benutzer und Projekt. Die genauen Pfade unterscheiden sich nach Betriebssystem und Scope. [S007]

Für ein einzelnes Projekt ist typisch:

``text ./CLAUDE.md ``

oder:

``text ./.claude/CLAUDE.md ``

Eine persönliche Datei kann projektübergreifende Arbeitspräferenzen enthalten. Projektregeln sollten im Repository liegen, wenn das Team sie teilen soll.

.claude/rules/

FAKT: Regeln können unter .claude/rules/ organisiert und mit Pfadmustern nur bei bestimmten Dateien geladen werden. [S007]

Beispiel:

```markdown

paths:

• "src/api/**"

API-Regeln

• Jeder Endpunkt validiert Eingaben.
• Fehlerantworten folgen dem Projektformat.

```

Vorteil: Eine Regel für Datenbankmigrationen belastet nicht jede Designänderung im Frontend.

Imports

Claude-Code-Dokumentation erlaubt Imports beziehungsweise Verweise auf zusätzliche Dateien. Organisation wird dadurch besser, doch geladener Inhalt verbraucht weiterhin Kontext. [S007]

EMPFEHLUNG: Nicht glauben, dass Aufteilen allein Token spart. Pfadregeln und Skills sind geeigneter, wenn Inhalt nur situativ gebraucht wird.

Auto Memory

FAKT: Neben manuellen CLAUDE.md-Anweisungen kann Claude Code projektspezifische Erkenntnisse im Auto Memory speichern. Die aktuell geladenen Grenzen und Speicherorte sind versionsabhängig; Anthropic nennt derzeit unter anderem die ersten 200 Zeilen beziehungsweise 25 KB für die beim Start geladene Memory-Hauptdatei. [S007]

Auto Memory eignet sich für:

• wiederholt entdeckte Buildhinweise,
• Debugging-Erkenntnisse,
• Präferenzen und Korrekturen.

Es eignet sich nicht als einzige Quelle für:

• freigegebene Architektur,
• rechtlich relevante Anforderungen,
• Produktionszugänge,
• Betriebs- oder Backupverfahren.

Diese Informationen gehören in kontrollierte Projektdateien.

Ein guter Pflegeprozess

EMPFEHLUNG:

1. Claude macht denselben Fehler ein zweites Mal.
2. Ursache prüfen.
3. Dauerhafte Regel formulieren.
4. Entscheiden: CLAUDE.md, pfadbezogene Rule oder Skill?
5. Änderung committen.
6. Nach einigen Wochen veraltete Regeln entfernen.

CLAUDE.md als lebendes Betriebshandbuch

Die Datei sollte keine vollständige Dokumentation ersetzen. Ihre Aufgabe lautet:

Claude in jeder Sitzung die wenigen Informationen geben, die ohne erneute Erklärung zuverlässig präsent sein müssen.

Das ist deutlich enger als „alles, was es über das Projekt zu wissen gibt“.

\newpage

Permissions, Sandbox, Hooks und Checkpoints

Vier unterschiedliche Schutzmechanismen

Diese Mechanismen ergänzen sich. Keine einzelne Ebene löst alle Risiken.

Permission-Regeln

FAKT: Claude Code kennt Allow-, Ask- und Deny-Regeln. Die Auswertung erfolgt in der Reihenfolge deny, dann ask, dann allow. Die erste passende Kategorie entscheidet; eine breite Deny-Regel kann nicht durch eine engere Allow-Regel überstimmt werden. [S009]

Beispiel aus der aktuellen Syntax:

``json { "$schema": "https://json.schemastore.org/claude-code-settings.json", "permissions": { "allow": [ "Bash(npm run lint)", "Bash(npm run test *)" ], "deny": [ "Read(./.env)", "Read(./secrets/**)" ] } } ``

Die offizielle JSON-Schema-Zeile ermöglicht in unterstützten Editoren Validierung und Autovervollständigung. Das Schema kann neuen CLI-Funktionen zeitlich hinterherlaufen. [S008]

Permission-Modi

FAKT: Claude Code bietet verschiedene Berechtigungsmodi. Der Modus default beziehungsweise die aktuelle UI-Bezeichnung „Manual“ fragt beim ersten entsprechenden Werkzeugzugriff. plan erlaubt primär Untersuchung ohne normale Quellcodeänderungen; andere Modi können Bearbeitungen stärker automatisieren. Die genaue Modusauswahl ist schnell veraltend. [S009]

EMPFEHLUNG: Anfänger starten im Standard-/Manual-Modus. bypassPermissions beziehungsweise gefährliche Skip-Flags gehören nicht in den normalen Workflow.

Aktuelle Settings können diese Modi deaktivieren:

``json { "permissions": { "defaultMode": "default", "disableBypassPermissionsMode": "disable", "disableAutoMode": "disable" } } ``

Die Felder sind aktuell dokumentiert; vor Einsatz Version und aktives Laden mit /status prüfen. [S008]

Warum Bash(git *) zu breit ist

Eine Regel:

``json "Bash(git *)" ``

passt nicht nur zu:

``bash git status ``

sondern auch zu:

``bash git push git reset --hard git clean -fd git tag git rebase ``

EMPFEHLUNG: Nur einzelne ungefährliche Befehle automatisch zulassen oder Git-Aktionen im Standardmodus bestätigen lassen.

Read- und Edit-Sperren

Typische Deny-Regeln:

``json "Read(./.env)", "Read(./.env.production)", "Read(./secrets/)", "Read(.//*.pem)" ``

FAKT: Claude-Code-Dateiregeln greifen für eingebaute Dateiwerkzeuge und bestimmte erkannte Shell-Dateibefehle. Beliebige Python- oder Node-Prozesse können eine Datei indirekt lesen; für harte Dateisystemgrenzen ist die Sandbox relevanter. [S009]

Sandbox

FAKT: Claude Code kann Shellbefehle in einer Sandbox ausführen, die Dateisystem- und Netzwerkzugriffe begrenzt. Unterstützungsumfang und Plattformdetails unterscheiden sich; die aktuelle Dokumentation nennt macOS, Linux und WSL2, während native Windows-Nutzung Einschränkungen hat. [S010]

EMPFEHLUNG: Sandbox besonders dann einsetzen, wenn Claude:

• fremde Repositories untersucht,
• externe Dateien verarbeitet,
• umfangreiche Shellbefehle ausführt,
• Netzwerkzugriff nicht benötigt,
• durch Prompt Injection beeinflusst werden könnte.

Hooks

FAKT: Hooks führen bei definierten Ereignissen Skripte aus. PreToolUse läuft vor einem Werkzeugaufruf. Ein Hook kann mit Exit-Code 2 eine Aktion blockieren und Claude eine Begründung über stderr liefern. [S013]

Typische Anwendungen:

• Änderungen an geschützten Dateien blockieren,
• destruktive Datenbankbefehle blockieren,
• vor Commit Tests ausführen,
• Toolaufrufe protokollieren,
• nach Änderungen formatieren.

Beispielstruktur:

``json { "hooks": { "PreToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect_files.py" } ] } ] } } ``

VORLAGE: Das Starterkit liefert bewusst nur deaktivierte Hook-Beispiele. Hooks sind ausführbarer Code und müssen selbst geprüft werden.

Hooks sind keine magische Shell-Firewall

Ein einfacher regulärer Ausdruck erkennt nicht jede verschachtelte Shellkonstruktion, jeden Alias oder jedes aufgerufene Skript. Außerdem können mehrere Hooks parallel laufen; ein blockierender Hook verhindert nicht automatisch, dass ein anderer Hook bereits eigene Seiteneffekte ausführt. [S013]

EMPFEHLUNG:

• Permissions für grobe Toolgrenzen,
• Sandbox für OS-nahe Grenzen,
• Hooks für zusätzliche deterministische Prüfungen,
• Betriebssystemrechte für echte Minimalrechte,
• Backups für den Fehlerfall.

Checkpoints und /rewind

FAKT: Claude Code erstellt Checkpoints, die Dateiänderungen und Gesprächszustände innerhalb einer Sitzung zurückspulen können. Über /rewind beziehungsweise die dokumentierte Tastenkombination lassen sich Gespräch, Code oder beide Ebenen zurücksetzen. [S011]

WICHTIGE GRENZEN:

• Dateiänderungen durch Bash-Kommandos werden nicht vollständig erfasst.
• Externe Änderungen sind nicht zuverlässig enthalten.
• Viele Subagent-Änderungen werden abhängig vom Ausführungsmodus nicht wiederhergestellt.
• Checkpoints sind kein Ersatz für Git. [S011]

Sicherheitsmodell für Anfänger

EMPFEHLUNG:

Normal automatisch erlaubt

• Lesen normaler Projektdateien,
• Suchen im Projekt,
• ungefährliche Statusabfragen,
• projektspezifische Tests nach Prüfung.

Bestätigung erforderlich

• Commits,
• Pushes,
• Abhängigkeitsinstallation,
• Docker-Start/Stop,
• SSH/SFTP,
• Datenbankmigrationen,
• systemweite Änderungen.

Standardmäßig blockiert oder getrennt

• Lesen von Secrets,
• private Schlüssel,
• produktive Datenbanklöschung,
• Backup-Löschung,
• unbestätigtes Produktions-Deployment,
• pauschale Administratorrechte.

Beispiel für vorsichtige Projektsettings

``json { "$schema": "https://json.schemastore.org/claude-code-settings.json", "permissions": { "defaultMode": "default", "disableBypassPermissionsMode": "disable", "disableAutoMode": "disable", "deny": [ "Read(./.env)", "Read(./.env.production)", "Read(./secrets/)", "Read(.//*.pem)", "Read(./**/*.key)" ], "ask": [ "Bash(git commit *)", "Bash(git push *)", "Bash(git tag *)", "Bash(ssh *)", "Bash(scp *)", "Bash(sftp *)", "Bash(docker compose down *)" ] } } ``

VORLAGE: Diese Konfiguration ist ein konservativer Ausgangspunkt, kein vollständiges Sicherheitsprofil. Sie muss gegen das aktuelle Claude-Code-Schema und das konkrete Projekt geprüft werden. Deny-Regeln für .env.* können auch ungefährliche Beispieldateien erfassen; deshalb werden im Beispiel konkrete Namen verwendet.

Prompt Injection im Entwicklungsumfeld

FAKT: Prompt Injection bezeichnet manipulierte Eingaben, die ein Modell zu unerwünschtem Verhalten bewegen können. OWASP führt Prompt Injection als zentrales Risiko für LLM-Anwendungen. Bei agentischen Werkzeugen kann die Auswirkung über falsche Antworten hinaus bis zu Werkzeugaufrufen reichen. [S081]

Mögliche Quellen:

• README eines fremden Repositories,
• Issue-Text,
• Webseite,
• Logdatei,
• hochgeladene Datei,
• MCP-Werkzeugausgabe,
• Kommentar im Quellcode.

EMPFEHLUNG: Externe Inhalte als Daten, nicht als Autorität behandeln. Rechte, Sandbox und Hooks so konfigurieren, dass eine manipulierte Anweisung nicht automatisch auf Produktivsysteme oder Secrets zugreifen kann.

\newpage

Skills, Subagents, MCP und Plugins

Warum Skills ein Kernbestandteil sind

FAKT: Claude-Code-Skills werden über eine SKILL.md definiert. Claude kann sie passend zum Auftrag automatisch laden oder der Benutzer ruft sie als /skill-name auf. Skill-Inhalt wird grundsätzlich erst geladen, wenn er benötigt wird. [S012]

Das löst zwei Probleme:

• wiederkehrende Verfahren müssen nicht in jedem Prompt neu erklärt werden,
• CLAUDE.md bleibt kurz und enthält nur dauerhaft relevante Regeln.

Ein Skill ist besonders sinnvoll, wenn der Benutzer denselben Ablauf wiederholt:

• Projekt anlegen,
• Anforderungen erheben,
• Release prüfen,
• Sicherheitsreview,
• Backup prüfen,
• Deployment vorbereiten,
• Übergabe dokumentieren.

Struktur eines Skills

Typisch:

``text .claude/skills/project-audit/ ├── SKILL.md ├── templates/ ├── examples/ ├── references/ └── scripts/ ``

Nur SKILL.md ist erforderlich. Weitere Dateien können Vorlagen, Beispiele, Referenzen oder ausführbare Hilfen enthalten. [S012]

Ein minimales Beispiel:

```markdown

name: project-audit description: Analysiert ein vorhandenes Projekt, seine Startfähigkeit und Risiken.

Untersuche Repository, Dokumentation, Tests und Betriebswege. Verändere zunächst nichts. Trenne bestätigte Befunde von Annahmen. ```

Frontmatter

FAKT: Claude Code unterstützt derzeit unter anderem folgende Skill-Felder: name, description, when_to_use, argument-hint, arguments, disable-model-invocation, user-invocable, allowed-tools, disallowed-tools, model, effort, context, agent, background, hooks, paths und shell. Nicht alle Felder gehören zum allgemeinen Agent-Skills-Standard; einige sind Claude-Code-Erweiterungen. [S012]

Refresh nötig: Diese Liste verändert sich schnell. Vor Veröffentlichung die aktuelle Skill-Referenz prüfen.

Automatische und manuelle Skills

Automatisch geeignete Skills

• Codekonventionen,
• Dokumentationsregeln,
• projektbezogene Prüfchecklisten,
• risikoarme Analyse.

Nur manuell geeignete Skills

• Commit,
• Push,
• Deployment,
• E-Mail-Versand,
• Backup-Restore,
• Datenmigration mit Seiteneffekt.

Dafür:

``yaml disable-model-invocation: true ``

FAKT: Anthropic nennt Deployment und ähnliche Task-Workflows ausdrücklich als Fall für manuelle Auslösung. [S012]

Forked Context

Ein Skill kann mit:

``yaml context: fork ``

in einem getrennten Subagent-Kontext laufen. Das eignet sich für umfangreiche Analysen, die den Hauptkontext nicht mit jeder gelesenen Datei füllen sollen. [S012]

Aktuell kann zusätzlich gesteuert werden, ob ein solcher Fork im Hintergrund läuft. Bei Dateiänderungen ist wichtig, dass Checkpoint-Restore nicht jede Hintergrund-Subagent-Änderung erfasst. [S011] [S012]

EMPFEHLUNG: Analyse-Skills dürfen geforkt laufen. Ändernde Skills sollten im Vordergrund, mit Git und klarer Diff-Prüfung arbeiten.

Gebündelte Skills

FAKT: Aktuelle Claude-Code-Versionen enthalten gebündelte Skills, darunter je nach Version /run, /verify, /code-review, /debug und weitere. /run und /verify können eine Anwendung starten und praktisch prüfen. Für nicht standardisierte Startabläufe kann Claude eine projektspezifische Run-/Verify-Anleitung als Skill aufzeichnen. [S012]

EMPFEHLUNG: Vor eigenen Doppelentwicklungen prüfen, welche gebündelten Skills die aktuelle Version bereits bietet. Eigene Skills sollten das Projektspezifische ergänzen: Datenbankstart, Umgebungsvariablen, Testdaten, Browserweg und Stop-Bedingungen.

Die zehn empfohlenen Projekt-Skills

/project-spec

Erhebt fachliche und technische Anforderungen. Ergebnis: belastbare SPEC.md.

/project-init

Prüft Git, Struktur, Claude-Dateien, Dokumentation, Test- und Startbefehle.

/project-audit

Analysiert ein vorhandenes Repository ohne sofortige Änderungen.

/checkpoint

Prüft Diff, Tests und sensible Dateien; bereitet einen Commit vor.

/security-review

Prüft defensive Sicherheitsaspekte anhand der tatsächlichen Architektur.

/backup-check

Inventarisiert Git, Datenbanken, Uploads, Volumes, Konfiguration und externe Dienste.

/deploy-staging

Veröffentlicht nach Bestätigung eine benannte Version in Staging.

/deploy-production

Nur manuell. Verlangt Version, Backupstatus, Rollback und Freigabe.

/restore-backup

Nur manuell. Standardmäßig ausschließlich in isolierter Testumgebung.

/handover

Erstellt eine nachvollziehbare Übergabe für nächste Sitzung oder Person.

VORLAGE: Vollständige Skills liegen im Starterkit dieses Dossiers. Sie sind bewusst technikneutral und müssen an das Projekt angepasst werden.

Skill-Qualität prüfen

Ein guter Skill besitzt:

• klaren Auslöser,
• klaren Zweck,
• Eingaben,
• feste Prüfschritte,
• Stop-Bedingungen,
• gewünschtes Ausgabeformat,
• Sicherheitsgrenzen,
• explizite Seiteneffekte.

Ein schlechter Skill lautet:

``text Mach das Projekt fertig und gut. ``

Ein besserer Skill trennt Analyse, Änderungen, Verifikation und Freigabe.

Subagents

FAKT: Claude Code unterstützt spezialisierte Subagents. Sie können eigene Anweisungen, Werkzeuge und Kontext verwenden. [S015]

Geeignete Rollen:

• Repository-Explorer,
• Testprüfer,
• Sicherheitsreviewer,
• Dokumentationsprüfer,
• Datenbankanalyst.

EMPFEHLUNG: Subagents nicht als unabhängige Entwickler ohne Koordination starten. Mehrere Agenten können konkurrierende Änderungen erzeugen. Aufgaben und Dateibereiche müssen getrennt sein; Git Worktrees können bei fortgeschrittener paralleler Arbeit helfen. [S034]

MCP

FAKT: Das Model Context Protocol kann Claude Code mit externen Werkzeugen und Datenquellen verbinden. [S016]

Mögliche Anbindungen:

• GitHub,
• Datenbanken,
• Browser- und Testwerkzeuge,
• interne Dokumentationssysteme,
• Ticketsysteme,
• eigene APIs.

MCP erhöht Nutzen und Risiko gleichzeitig. Ein MCP-Server kann Daten bereitstellen oder Aktionen auslösen. Zugangsdaten, Berechtigungen und die Vertrauenswürdigkeit des Servers müssen geprüft werden.

FAKT: OWASP veröffentlicht seit 2026 eine eigene Risikosammlung für MCP-bezogene Gefahren. [S082]

EMPFEHLUNG:

• MCP-Server nur aus geprüfter Quelle,
• minimale Berechtigungen,
• schreibende Werkzeuge zunächst ask,
• keine produktiven Zugangsdaten im Repository,
• Ausgaben als potenziell untrusted behandeln,
• nicht benötigte MCP-Server deaktivieren.

Plugins

Claude-Code-Plugins können Skills, Hooks, Agents und MCP-Konfiguration bündeln. [S014]

Vorteil:

• zentrale Verteilung,
• wiederverwendbare Organisationstandards,
• einfache Aktivierung.

Risiko:

• ausführbarer beziehungsweise handlungssteuernder Fremdinhalt,
• Lieferkettenrisiko,
• unerwartete Rechte und Hooks,
• Versionsabhängigkeit.

EMPFEHLUNG: Plugins wie Softwareabhängigkeiten behandeln: Herkunft, Inhalt, Version, Wartung und Berechtigungen prüfen.

Skills versus CLAUDE.md versus Hooks

Diese Trennung ist die wichtigste Architektur des Claude-Code-Starterkits.

\newpage

Prompts und Arbeitsabläufe

Der Prompt ist nicht der gesamte Prozess

Ein guter Prompt kann eine schlechte Projektumgebung nicht vollständig retten. Ohne Git, Tests, Spezifikation und Backup bleibt selbst eine perfekte Formulierung riskant.

FAKT: Anthropic empfiehlt klare Ziele, relevanten Kontext, konkrete Verifikationsmöglichkeiten und bei größeren Änderungen zunächst Exploration und Planung. [S006] [S026] [S027]

Die fünf Bestandteile eines starken Auftrags

1. Ziel: Was soll fachlich erreicht werden?
2. Kontext: Welche Dateien, Spezifikation und Grenzen gelten?
3. Vorgehen: Erst untersuchen, dann planen, dann ändern.
4. Verifikation: Welche Tests und Benutzerwege beweisen Erfolg?
5. Ausgabe: Was soll Claude am Ende berichten?

Beispiel:

```text Implementiere das Kontaktformular entsprechend SPEC.md.

Untersuche zuerst bestehende Formular-, Mail- und Validierungslogik. Zeige einen kurzen Plan. Ändere nur erforderliche Dateien.

Prüfe anschließend:

• Pflichtfelder,
• ungültige E-Mail-Adressen,
• Spam-Schutz,
• Fehlerfall des Maildienstes,
• mobile Darstellung,
• Tastaturbedienung.

Führe vorhandene Tests und Build aus. Berichte, was tatsächlich geprüft wurde, was nicht geprüft werden konnte und welche Risiken bleiben. Kein Commit und kein Deployment. ```

Explore → Plan → Implement → Verify → Commit

FAKT: Anthropic beschreibt einen bewährten Ablauf aus Untersuchung, Planung, Implementierung und Commit beziehungsweise Verifikation. [S006] [S026]

Für die Zielgruppe lautet er:

``text Verstehen → Planen → Bauen → Prüfen → Sichern ``

Verstehen

Claude liest Spezifikation, relevante Dateien, Tests und Architektur.

Planen

Claude nennt betroffene Dateien, Risiken und Akzeptanzkriterien.

Bauen

Claude ändert einen begrenzten Abschnitt.

Prüfen

Tests, Build, gestartete Anwendung und manueller Benutzerweg.

Sichern

Git-Diff prüfen und Commit herstellen.

Der Projektinterview-Prompt

VORLAGE:

```text Ich möchte folgendes Projekt entwickeln:

[PROJEKTIDEE]

Implementiere noch nichts. Führe zuerst eine vollständige Projektdefinition durch.

Kläre nur entscheidungsrelevante Punkte zu:

• Ziel und messbarem Erfolg,
• Benutzern und Rollen,
• Muss-/Soll-/Kann-Funktionen,
• Daten, Datenschutz, Aufbewahrung und Löschung,
• Login, Rechte und Administration,
• externen APIs und Diensten,
• lokaler Entwicklung,
• Hosting, Domain, Datenbank und Dateispeicher,
• Tests, Sicherheit, Backup, Restore und Deployment,
• Betrieb, Updates und Verantwortung.

Bei fehlenden Informationen nicht raten, sondern UNKLAR markieren. Erstelle anschließend SPEC.md, offene Entscheidungen, Architekturvarianten, Risiken und benötigte Software. Noch keinen produktiven Code schreiben. ```

Die konkrete Formulierung ist eine eigene Vorlage. Das zugrunde liegende Vorgehen – erst Interview und Spezifikation, dann Umsetzung – entspricht Anthropic-Best-Practice für größere Vorhaben. [S006]

Prompt für ein vorhandenes Projekt

```text Analysiere dieses Repository. Verändere zunächst nichts.

Ermittle:

• Zweck und Architektur,
• Start-, Test-, Lint- und Buildbefehle,
• Datenbank und externe Dienste,
• Authentifizierung und Rollen,
• Deployment- und Backupweg,
• sensible oder fehlkonfigurierte Dateien,
• fehlende Dokumentation,
• technische Risiken.

Trenne bestätigte Fakten, begründete Schlussfolgerungen und UNKLAR. Erstelle danach einen priorisierten Verbesserungsplan. ```

Prompt für eine Fehlerbehebung

```text Fehlerbild: [FEHLER] Erwartetes Verhalten: [ERWARTUNG]

Reproduziere zuerst oder erkläre, warum dies nicht möglich ist. Ändere noch nichts. Ermittle Ursache anhand von Code, Logs und Tests. Lege nach Möglichkeit einen Regressionstest an, der vor der Korrektur fehlschlägt. Implementiere die kleinste tragfähige Korrektur. Führe relevante Tests und einen praktischen Gegencheck aus. Melde die Behebung nur als bestätigt, wenn sie verifiziert wurde. ```

Prompt für Architekturentscheidung

```text Vergleiche für [THEMA] mindestens zwei realistische Varianten.

Bewerte:

• Entwicklungs- und Betriebsaufwand,
• Sicherheit und Datenschutz,
• Backup und Restore,
• Kosten und Anbieterabhängigkeit,
• Wartung,
• erwartete Last,
• Migration und Rückfall.

Trenne Fakten von Annahmen. Markiere fehlende Angaben UNKLAR. Empfiehl eine Variante und entwirf einen ADR. Noch keinen Anwendungscode ändern. ```

Prompt für Release-Prüfung

```text Prüfe den aktuellen Stand als Release-Kandidaten. Nichts committen oder deployen.

Prüfe Git-Diff, Anforderungen, Tests, Linter, Build, Startfähigkeit, Migrationen, Konfiguration, Secrets, Backup, Rollback, zentrale Benutzerwege, Dokumentation und Sicherheitsrisiken.

Ergebnis ausschließlich:

• FREIGABEFÄHIG,
• MIT AUFLAGEN oder
• NICHT FREIGABEFÄHIG.

Begründe mit Befunden und nenne alle nicht ausgeführten Prüfungen. ```

Prompt für UI-Arbeit

```text Ändere [SEITE/KOMPONENTE] entsprechend [ZIEL].

Erhalte bestehende Funktionen und Designregeln. Prüfe Desktop und mobile Breite, Tastaturbedienung, Kontrast, Fokuszustände, Lade-, Leer- und Fehlerzustände. Nutze vorhandene Browser-/UI-Tests oder starte die Anwendung und prüfe praktisch. Lighthouse oder automatische Accessibility-Checks sind ein Hinweis, aber kein vollständiger Barrierefreiheitsnachweis. ```

Der letzte Satz ist wichtig: Automatische Werkzeuge erfassen nur einen Teil der Anforderungen. [S076] [S079]

Prompt für Sicherheitsprüfung

```text Führe eine defensive Sicherheitsprüfung des Projekts durch. Keine externen Angriffe und keine produktiven Daten verwenden.

Prüfe Authentifizierung, Autorisierung, Sitzungen, Eingaben, Ausgaben, Uploads, Secrets, Logging, Datenbankzugriffe, Abhängigkeiten, Fehlerausgaben, MCP/Tools, Deployment und Backup.

Für jeden Befund:

• Beleg im Projekt,
• Auswirkung,
• defensive Reproduktion,
• konkrete Abhilfe,
• verbleibendes Risiko.

Vermutungen ausdrücklich markieren. ```

Prompt-Antimuster

„Mach alles fertig“

Zu groß, ohne Verifikation.

„Mach es modern“

Keine messbare Anforderung.

„Benutze die beste Datenbank“

„Beste“ hängt vom Kontext ab.

„Frag nicht, entscheide selbst“

Bei Architektur, Daten oder Produktion gefährlich.

„Behebe alle Sicherheitslücken“

Ohne Scope, Beleg und Prüfung nicht seriös.

„Nutze immer die neueste Version“

Neueste Version kann inkompatibel oder ungetestet sein.

Kontextmanagement

FAKT: Kontext ist begrenzt. Lange Sitzungen, umfangreiche Toolausgaben und wiederholte Richtungswechsel können die Qualität verschlechtern. Anthropic empfiehlt gezielte Kontextführung, Aufgabentrennung und bei unabhängigen Themen neue beziehungsweise bereinigte Sitzungen. [S006] [S028]

EMPFEHLUNG:

``text Eine Aufgabe → Verifikation → Commit → Handover → neue Aufgabe ``

Nicht:

``text Eine Sitzung → Design → Datenbank → Marketingtext → Servermigration → neue Architektur → drei Tage Debugging ``

Quellen und Zitate in technischen Prompts

Wenn Claude eine aktuelle Installation, Sicherheitsoption oder Hostingfunktion empfiehlt:

``text Nutze ausschließlich aktuelle Primärquellen. Nenne Hersteller, Seitentitel, URL und Veröffentlichungs-/Abrufstand. Markiere versionsabhängige Angaben und rate nicht. ``

Dieser Zusatz verhindert keine Halluzination garantiert, erhöht aber die Prüfbarkeit.

\newpage

Lokale Entwicklung und localhost

Warum lokal beginnen

Lokal bedeutet:

• Dateien liegen auf dem eigenen Rechner,
• Entwicklungsserver läuft dort,
• Browser greift über localhost zu,
• keine öffentliche Domain erforderlich,
• Fehler treffen zunächst keine echten Benutzer.

Das ist der sicherste Lernraum.

Drei lokale Projekttypen

A. Statische Website

Dateien:

``text index.html styles.css script.js images/ ``

Einfachste Vorschau: Datei direkt im Browser öffnen. Besser ist ein lokaler HTTP-Server, weil Pfade und Browserregeln realistischer sind.

Mit Python, wenn installiert:

``bash python -m http.server 8000 ``

oder je nach System:

``bash python3 -m http.server 8000 ``

Danach:

``text http://localhost:8000 ``

FAKT: Pythons http.server ist für einfache lokale Zwecke geeignet, aber laut Dokumentation nicht für Produktion empfohlen. [S047]

B. Framework-Projekt

Typisch:

``bash npm install npm run dev ``

Die exakten Befehle stehen in package.json und Projektdokumentation.

C. Backend-/Datenbankprojekt

Zusätzlich erforderlich:

• Runtime,
• lokale Datenbank oder Container,
• .env,
• Migrationen,
• eventuell Seed-/Testdaten.

Lokaler Start als dokumentierter Vorgang

Ein Projekt ist erst vernünftig übergabefähig, wenn ein neuer Benutzer aus einer frischen Arbeitskopie nachvollziehen kann:

1. Voraussetzungen installieren.
2. Repository klonen.
3. lokale Konfiguration aus .env.example erstellen.
4. Abhängigkeiten installieren.
5. Datenbank vorbereiten.
6. Anwendung starten.
7. Tests ausführen.

Diese Schritte gehören in README oder einen Run-Skill.

Ports und Portkonflikte

Wenn zwei Dienste denselben Port verwenden, kann der zweite nicht normal binden.

Typische Meldung:

``text Address already in use ``

Lösung:

• bestehenden Prozess identifizieren,
• prüfen, ob er zum Projekt gehört,
• sauber beenden oder anderen Port konfigurieren.

Nicht empfehlenswert: alle Node-, Python- oder Docker-Prozesse pauschal beenden.

Zugriff aus dem Heimnetz

Ein Entwicklungsserver bindet häufig nur an localhost. Für Zugriff von einem zweiten Gerät muss er gegebenenfalls an eine LAN-Adresse beziehungsweise 0.0.0.0 gebunden und durch die lokale Firewall erreichbar gemacht werden.

WARNUNG: 0.0.0.0 bedeutet nicht „nur für mich“. Der Dienst kann in erreichbaren Netzwerken auf allen Interfaces lauschen. Das Projekt muss dafür geeignet und das Netzwerk vertrauenswürdig sein.

Lokale HTTPS-Frage

Für die meisten Anfängerprojekte genügt lokal HTTP. Bestimmte Browserfunktionen, OAuth-Flows oder Produktionsnähe können lokales HTTPS erfordern.

EMPFEHLUNG: Nicht versuchen, ein öffentliches Zertifikat für localhost wie für eine normale Domain zu behandeln. Je nach Bedarf lokale Entwicklungszertifikate, Frameworkfunktionen oder eine echte Testdomain verwenden.

Lokale Daten

Keine echten Kundendaten in die Entwicklungsumgebung kopieren, wenn Testdaten genügen.

Besser:

• synthetische Beispieldaten,
• anonymisierte Daten,
• getrennte Testkonten,
• eingeschränkte lokale Rechte.

Lokale E-Mail

Ein Kontaktformular sollte in der Entwicklung nicht versehentlich echte Kunden oder Mitarbeiter anschreiben.

Möglichkeiten:

• Mail-Catcher,
• Testanbieter,
• lokaler Dummy-Transport,
• klar getrennte Testadresse.

Lokale Prüfung

Mindestens:

• Start ohne Fehler,
• Browserzugriff,
• zentrale Navigation,
• Formulare und Fehlermeldungen,
• mobile Breite,
• Tests und Build,
• sauberes Stoppen und Neustarten.

Run-Skill

FAKT: Aktuelle Claude-Code-Versionen können mit gebündelten /run- und /verify-Skills Anwendungen starten und prüfen. Bei projektspezifischen Abläufen kann eine Run-Anleitung aufgezeichnet werden. [S012]

EMPFEHLUNG: Einmal einen sauberen Start aus frischer Umgebung herstellen und als Projekt-Skill dokumentieren. Dadurch muss Claude den Startweg nicht in jeder Sitzung neu erraten.

\newpage

Apache, PHP und klassische Websites

Was Apache tut

FAKT: Apache HTTP Server liefert statische und dynamisch erzeugte Webinhalte aus. DocumentRoot bezeichnet das Verzeichnis, aus dem Dateien für eine Website bereitgestellt werden. [S045]

``text Browser fordert /index.html an ↓ Apache prüft Virtual Host ↓ DocumentRoot ↓ Datei/Anwendung erzeugt Antwort ``

Wann Apache lokal sinnvoll ist

• klassische PHP-Anwendung,
• lokale Umgebung soll Produktivserver ähneln,
• mehrere lokale Virtual Hosts,
• Synology Web Station,
• bestehendes Apache-Projekt.

Nicht erforderlich für:

• einfache React-/Vite-Entwicklung,
• Frameworks mit eigenem Dev-Server,
• statische Einzelvorschau.

Apache auf Windows/macOS

Mögliche Wege:

• systemnah installieren,
• Paketstapel wie XAMPP/MAMP verwenden,
• Container nutzen,
• vorhandene Frameworkumgebung verwenden.

EMPFEHLUNG: Für das Dossier keinen einzelnen Drittanbieter-Stapel als zwingenden Standard ausgeben. Installationswege ändern sich; der gewählte Weg muss zur Zielproduktion passen.

DocumentRoot

Beispiel:

``apache DocumentRoot "/var/www/meine-seite/public" ``

Der öffentlich erreichbare Root sollte bei Frameworks häufig auf einen vorgesehenen public-Ordner zeigen, nicht auf das gesamte Repository mit .env, Quellcode und Backups.

Virtual Hosts

FAKT: Apache unterstützt namensbasierte Virtual Hosts. Mehrere Domains können auf derselben IP-Adresse unterschiedliche Websites ausliefern. [S046]

``apache <VirtualHost *:80> ServerName projekt.test DocumentRoot "/var/www/projekt/public" </VirtualHost> ``

Lokal muss der Name zusätzlich aufgelöst werden, beispielsweise über die Hosts-Datei. Öffentlich benötigt er DNS. Ein Virtual Host erstellt keinen DNS-Eintrag. [S046]

PHP-Anwendung

Typische Bestandteile:

``text Apache + PHP-Version und Module + Anwendungscode + Datenbank + .env/Serverkonfiguration + Schreibrechte für bestimmte Ordner ``

Fehler entstehen häufig durch:

• falsche PHP-Version,
• fehlende Erweiterung,
• falschen DocumentRoot,
• Dateirechte,
• nicht gesetzte Umgebungsvariablen,
• fehlende Datenbankmigration.

Dateirechte

Ein Webserverprozess benötigt nur die Rechte, die er tatsächlich braucht. Nicht jeder Projektordner muss global schreibbar sein.

EMPFEHLUNG: Schreibrechte auf Upload-, Cache- oder Logordner beschränken. Keine pauschalen chmod 777-Lösungen übernehmen.

Apache-Logs

Bei Fehlern zuerst:

• Access Log,
• Error Log,
• PHP-/Anwendungslog,
• Browser-Netzwerkfehler,
• Dateirechte.

Ein weißer Bildschirm ist kein ausreichender Diagnosehinweis.

Apache-Deployment

Für eine statische Website kann Deployment aus dem Kopieren einer definierten Version in den Webroot bestehen. Für PHP kommen hinzu:

• Abhängigkeiten,
• Konfiguration,
• Datenbankmigration,
• Cache,
• Dateirechte,
• Funktionstest.

EMPFEHLUNG: Nicht per SFTP beliebige Einzeldateien live überschreiben. Besser eine vollständige, versionierte Release-Einheit übertragen und kontrolliert aktivieren.

\newpage

Synology NAS als Lern-, Test- und Backup-System

Was eine Synology gut leisten kann

Je nach Modell, DSM-Version und installierten Paketen:

• Dateispeicher,
• Web Station,
• interne Webportale und Virtual Hosts,
• Container Manager,
• SSH-Zugang,
• Hyper Backup,
• Snapshot Replication. [S051–S058]

UNKLAR ohne Modell: Nicht jede Synology unterstützt Container Manager, Btrfs oder Snapshot Replication. Vor Anleitung Modell, CPU-Architektur, RAM, DSM-Version und Volume-Dateisystem prüfen.

Warum die NAS didaktisch sinnvoll ist

Sie macht Serverkonzepte greifbar:

``text Mac/Windows-PC │ ├─ bearbeitet Projekt mit Claude Code │ └─ überträgt definierte Version ↓ Synology im Heimnetz ├─ Web Station oder Container ├─ Daten/Volumes ├─ Snapshot └─ Backup auf externes Ziel ``

Der Benutzer erlebt den Unterschied zwischen:

• lokaler Datei,
• Netzwerkfreigabe,
• Webdienst,
• IP-Adresse,
• Backup.

Web Station

FAKT: Synology Web Station kann Webportale und virtuelle Hosts bereitstellen. Konfiguration und verfügbare Backendoptionen sind DSM- und paketabhängig. [S051] [S052]

Geeignet für:

• statische Websites,
• unterstützte PHP-Anwendungen,
• interne Demonstrationen,
• Lernprojekte.

Ein sicherer Lernaufbau

1. Projekt lokal entwickeln.
2. Git-Checkpoint erstellen.
3. NAS-Freigabe oder Deploymentziel anlegen.
4. Web Station konfigurieren.
5. nur notwendige Dateien übertragen.
6. aus einem zweiten Gerät im LAN testen.
7. Änderungen nicht direkt im Webroot entwickeln.

Container Manager

FAKT: Unterstützte Synology-Modelle können über Container Manager Projekte aus Compose-Konfigurationen verwalten. [S053]

Vorteile:

• Dienste getrennt vom DSM-System,
• reproduzierbare Konfiguration,
• Anwendung und Datenbank als definierte Services.

Nachteile:

• zusätzlicher Speicher- und RAM-Bedarf,
• Volumes und Netzwerke müssen verstanden werden,
• Backup der Containerdefinition allein sichert keine Volumedaten,
• Images und Compose-Dateien sind vertrauenswürdiger Code mit möglichem Hostzugriff. [S059–S065]

Synology ist keine generische Entwickler-Shell

FAKT: Synologys Entwicklerleitfaden empfiehlt für generische Entwicklung Containerumgebungen statt das NAS-Betriebssystem wie eine beliebige Linux-Entwicklungsmaschine zu behandeln. [S054]

EMPFEHLUNG: Claude Code auf dem eigenen Rechner ausführen. Für NAS-spezifische Änderungen:

• dokumentierte DSM-Funktionen,
• Container,
• minimale SSH-Rechte,
• vorheriger Snapshot/Backup,
• keine ungeprüften Systempakete.

SSH auf der Synology

FAKT: DSM kann SSH aktivieren. Synology warnt, dass unsachgemäße Kommandozeilenänderungen zu Fehlfunktionen oder Datenverlust führen können. [S058]

Sicherer Ansatz:

• SSH nur bei Bedarf aktiv,
• separater Benutzer,
• starke Authentifizierung,
• kein offener Internetzugriff ohne Schutzkonzept,
• Befehle dokumentieren,
• keine DSM-Systemdateien durch Claude „aufräumen“ lassen.

NAS öffentlich erreichbar machen?

Technisch möglich bedeutet nicht empfehlenswert. Eine direkt exponierte Heim-NAS bringt zusätzliche Risiken:

• Router- und Portfreigaben,
• dynamische öffentliche IP,
• Zertifikate,
• DSM- und Paketupdates,
• Brute-Force-Angriffe,
• private Daten und Backups auf demselben Gerät,
• Verfügbarkeit von Strom und Internetanschluss.

EMPFEHLUNG: Für öffentliche Kundenanwendungen Managed Hosting oder VPS prüfen. Die NAS bleibt internes Ziel, Backupziel oder über einen abgesicherten VPN-Zugang erreichbar.

RAID, Snapshot und Backup

RAID

Erhöht je nach Konfiguration Verfügbarkeit bei Laufwerksausfall. Es schützt nicht gegen versehentliches Löschen, Ransomware, Diebstahl, Brand oder fehlerhafte Synchronisation.

Snapshot

Point-in-Time-Zustand auf unterstütztem Dateisystem. Schnell für Rücksprünge, aber häufig auf demselben Gerät.

Backup

Unabhängige Kopie mit Aufbewahrung und Wiederherstellungsverfahren.

Offsite

Kopie außerhalb des Geräts oder Standorts.

FAKT: Synology empfiehlt 3-2-1: drei Kopien, zwei unterschiedliche Medien beziehungsweise Geräte, eine externe Kopie. Die deutsche Anleitung wurde am 08.05.2026 aktualisiert. [S055]

Hyper Backup

FAKT: Hyper Backup kann Daten, Anwendungen und Konfigurationen mehrversionig auf lokale, externe, NAS- oder Cloudziele sichern, abhängig von Ziel und Paketversion. [S056]

EMPFEHLUNG:

• Verschlüsselungsschlüssel getrennt sichern,
• Backupaufgabe überwachen,
• Benachrichtigungen aktivieren,
• regelmäßig Restore testen,
• nicht nur „Aufgabe erfolgreich“ als Nachweis akzeptieren.

Snapshot Replication

FAKT: Snapshot Replication setzt unterstützte Modelle und Btrfs-Konfiguration voraus. [S057]

Geeignet für:

• schnelle Rückkehr zu früheren Dateizuständen,
• Schutz vor versehentlichen Änderungen,
• zusätzliche lokale Resilienz.

Nicht ausreichend als einzige externe Sicherung.

Empfohlene NAS-Rolle

\newpage

VPS, Linux, SSH, SFTP und Serverbetrieb

Was ein VPS ist

Ein Virtual Private Server ist ein virtueller Rechner mit eigenem Betriebssystem und administrativer Verantwortung. Der Anbieter betreibt die physische Infrastruktur; der Kunde verwaltet in vielen Angeboten das Gastbetriebssystem.

Typischer Aufbau:

``text Internet ↓ 80/443 Firewall ↓ Reverse Proxy/Webserver ↓ Anwendung ↓ Datenbank/Dateispeicher ``

Zusätzlicher Verwaltungsweg:

``text Arbeitsrechner ↓ SSH, Port 22 oder angepasster Port Server-Shell ``

Was der Betreiber übernehmen muss

• Benutzer und Schlüssel,
• SSH-Konfiguration,
• Firewall,
• Sicherheitsupdates,
• Laufzeiten und Pakete,
• Webserver oder Container,
• Zertifikate,
• Logs und Monitoring,
• Backups und Restore,
• Reaktion auf Vorfälle.

FAKT: Ubuntu dokumentiert diese Bereiche getrennt, unter anderem OpenSSH, UFW, automatische Updates, AppArmor und Paketverwaltung. [S066–S071]

Erster Serverzugang

Typisch:

``bash ssh benutzer@server-ip ``

FAKT: OpenSSH stellt verschlüsselte Fernzugriffe bereit. GitHub und Ubuntu dokumentieren SSH-Schlüssel und Serverkonfiguration. [S036] [S066]

Schlüssel statt Passwort

Ein Schlüsselpaar:

``text Private Key → bleibt lokal Public Key → auf Zielserver ``

Der private Schlüssel sollte durch Dateirechte und gegebenenfalls Passphrase geschützt werden. Er gehört nicht ins Projekt.

Root und normaler Benutzer

EMPFEHLUNG: Anwendung nicht dauerhaft als root betreiben. Ein administrativer Benutzer nutzt erhöhte Rechte nur für notwendige Systemaufgaben; die Anwendung erhält einen eigenen Benutzer und minimale Zugriffe.

Claude sollte nicht automatisch:

• Root-Login aktivieren,
• Passwörter in Befehlen ausgeben,
• SSH-Schlüssel kopieren,
• Firewall komplett deaktivieren,
• Dateirechte pauschal öffnen.

Firewall mit UFW

FAKT: Ubuntu dokumentiert UFW als Frontend für Firewallregeln. Die Firewall ist in typischen Ubuntu-Installationen nicht zwangsläufig bereits aktiv und muss bewusst konfiguriert werden. [S068]

Minimalprinzip:

• SSH nur wie erforderlich,
• HTTP/HTTPS für Webbetrieb,
• Datenbankports nicht öffentlich, wenn nicht nötig,
• alle anderen Dienste geschlossen.

WARNUNG: Vor Aktivierung der Firewall sicherstellen, dass der eigene SSH-Zugang erlaubt bleibt. Sonst kann man sich aussperren.

Updates

FAKT: Ubuntu dokumentiert automatische Updates über unattended-upgrades; aktuelle Standardkonfigurationen prüfen regelmäßig auf Aktualisierungen. [S069]

Automatische Sicherheitsupdates reduzieren Risiko, ersetzen aber nicht:

• Neustartplanung,
• Anwendungskompatibilität,
• Container-/Runtime-Updates,
• Überwachung fehlgeschlagener Updates.

SFTP, SCP und FTP

SSH

Fernsteuerung der Shell.

SFTP

Dateiübertragung über das SSH-Protokoll.

SCP

Dateikopie über SSH.

FTP

Klassisches Dateiübertragungsprotokoll; ohne zusätzliche Absicherung nicht verschlüsselt.

FTPS

FTP mit TLS; nicht dasselbe wie SFTP.

FAKT: Ubuntu erläutert die Unterscheidung. [S067]

EMPFEHLUNG: Für neue einfache Serverzugriffe SFTP/SSH verwenden. Noch besser: versionierte Deployments statt manueller Einzeldateiübertragung.

VS Code Remote SSH

FAKT: VS Code kann über die Remote-SSH-Erweiterung auf einem entfernten Rechner arbeiten. [S048]

Das ist praktisch, erhöht aber die Gefahr, direkt in Produktion zu entwickeln.

EMPFEHLUNG: Remote SSH bevorzugt für Staging, Diagnose oder klar getrennte Entwicklungsserver. Produktion nicht als normalen Editor-Arbeitsordner verwenden.

Deploymentvarianten auf einem VPS

A. Datei-Release

Für statische Website oder PHP:

``text Build/Release → SFTP/rsync/Git-Pull-Mechanismus → neuer Release-Ordner → Symlink/Umschaltung ``

B. Git-basiert

Server holt einen freigegebenen Stand. Das Repository allein enthält aber keine Secrets oder Datenbankdaten.

C. Container

Image und Compose/Orchestrierung definieren Anwendung. Volumes und Secrets separat.

D. Plattform/CI/CD

Ein Dienst baut und veröffentlicht nach Push oder Tag. Auch hier müssen Secrets, Rollback und Logs geklärt sein.

Kein direktes git pull ohne Plan

Ein einfaches git pull im Live-Ordner kann:

• halbfertige Änderungen einspielen,
• Abhängigkeiten oder Buildschritte auslassen,
• Migrationen unkontrolliert starten,
• Rollback erschweren.

EMPFEHLUNG: Benannte Releases, getrennte Buildschritte und atomare Aktivierung bevorzugen.

Server-Logs

Mindestens unterscheiden:

• Systemlog,
• Webserver-/Proxylog,
• Anwendungslog,
• Datenbanklog,
• Deploymentlog.

Keine Secrets, Tokens oder personenbezogenen Vollinhalte unnötig protokollieren.

Server-Prompt für Claude

VORLAGE:

```text Analysiere diesen Serverzugang nur lesend. Verändere nichts.

Ermittle:

• Betriebssystem und Version,
• aktuellen Benutzer und Rechte,
• laufende Dienste und offene benötigte Ports,
• Webserver/Reverse Proxy,
• Anwendungsprozess oder Container,
• Speicherorte von Code, Konfiguration, Logs und persistenten Daten,
• Update- und Backupstatus,
• dokumentierten Deployment- und Rollbackweg.

Gib vor jedem Befehl Zweck und erwartete Ausgabe an. Keine Secrets ausgeben. Keine Firewall-, Benutzer-, Paket-, Dienst- oder Datenbankänderung ohne separaten Plan und ausdrückliche Bestätigung. ```

Wann ein Managed Hosting besser ist

Ein VPS ist nicht automatisch professioneller. Managed Hosting kann geeigneter sein, wenn:

• keine Person Serverpflege übernehmen kann,
• Standard-PHP/WordPress genügt,
• Backups und Updates als Dienst benötigt werden,
• hohe Verfügbarkeit wichtiger als vollständige Kontrolle ist.

UNKLAR: Die richtige Hostingklasse hängt vom Projekt und Anbieter ab. Preis allein ist keine ausreichende Entscheidung.

\newpage

Docker und reproduzierbare Umgebungen

Was Docker löst

Docker verpackt Anwendungen in Container. Ein Container nutzt ein Image als Ausgangspunkt und läuft mit definierten Abhängigkeiten, Netzwerken und Mounts. Docker Compose beschreibt mehrere zusammengehörige Dienste in einer YAML-Datei. [S059]

Beispiel:

``text Webanwendung + PostgreSQL + Redis + Reverse Proxy ``

statt vier Dienste manuell einzeln zu konfigurieren:

``yaml services: app: build: . db: image: postgres redis: image: redis ``

FAKT: Docker beschreibt Compose als Werkzeug zur Definition und Ausführung von Multi-Container-Anwendungen. Services, Netzwerke und Volumes werden in einer Konfiguration verwaltet. [S059]

Was Docker nicht löst

Docker löst nicht automatisch:

• fachliche Architektur,
• sichere Images,
• Geheimnisverwaltung,
• Datenbankbackup,
• Monitoring,
• Updates,
• HTTPS,
• Produktivfreigabe,
• Wiederherstellung.

Ein Container ist keine Sicherheitsgarantie und kein Backup.

Wann Docker sinnvoll wird

• mehrere Dienste müssen gemeinsam gestartet werden,
• lokale und produktive Umgebung sollen ähnlich sein,
• Abhängigkeiten sollen isoliert werden,
• NAS oder VPS soll dieselbe Compose-Datei verwenden,
• Teammitglieder benötigen reproduzierbaren Start.

Wann Docker zunächst unnötig ist

• eine statische Website,
• ein einzelnes HTML/CSS-Lernprojekt,
• Framework bringt stabilen lokalen Dev-Server mit,
• Benutzer versteht Volumes und Ports noch nicht,
• Hostingziel unterstützt die Anwendung ohne eigenen Containerbetrieb.

EMPFEHLUNG: Docker nicht als Eintrittskarte ins Vibe Coding darstellen. Erst einsetzen, wenn es ein konkretes Umgebungsproblem löst.

Images und Container

Image

Unveränderliche Vorlage mit Anwendung und Abhängigkeiten.

Container

Laufende Instanz eines Images.

Volume

Von Docker verwalteter persistenter Datenspeicher außerhalb des normalen Container-Lebenszyklus. [S060]

Bind Mount

Verbindet einen Hostordner direkt mit einem Container. Dadurch hängt die Anwendung stärker von Hostpfad und Betriebssystem ab. [S065]

Daten gehören nicht nur in die Container-Schreibschicht

FAKT: Docker-Volumes existieren außerhalb des Lebenszyklus eines einzelnen Containers. Wird ein Container entfernt, bleibt das Volume grundsätzlich bestehen, bis es separat entfernt wird. [S060]

Datenbanken und Uploads benötigen persistente Speicherziele:

```yaml services: db: image: postgres volumes:

• db-data:/var/lib/postgresql/data

volumes: db-data: ```

Doch auch ein Volume muss gesichert werden. Die Compose-Datei beschreibt nur, dass das Volume existiert; sie enthält nicht dessen laufende Daten.

Der gefährliche Befehl down -v

``bash docker compose down -v ``

FAKT: Die Option -v beziehungsweise --volumes entfernt die in der Compose-Datei deklarierten benannten Volumes sowie angehängte anonyme Volumes. [S064]

Das kann Datenbanken und Uploads löschen.

EMPFEHLUNG:

• nicht automatisch freigeben,
• vor Ausführung Volumes auflisten,
• Dateninhalt und Backupstatus prüfen,
• produktive Ausführung durch Hook oder Prozess blockieren,
• für reine Neustarts down -v nicht verwenden.

Compose-Dateien sind vertrauenswürdiger Code

Compose kann unter anderem:

• Hostordner mounten,
• Ports veröffentlichen,
• privilegierte Einstellungen verwenden,
• Umgebungsvariablen und Secrets referenzieren,
• Befehle im Container starten.

FAKT: Docker weist in Sicherheitsdokumentation darauf hin, Compose-Konfigurationen als vertrauenswürdigen Input zu behandeln. [S062]

EMPFEHLUNG: Fremde compose.yaml vor docker compose up lesen. Besonders prüfen:

• privileged,
• Zugriff auf Docker-Socket,
• Hostpfade,
• veröffentlichte Ports,
• network_mode: host,
• eingebettete Secrets,
• unklare Images und Tags.

Secrets in Compose

FAKT: Docker Compose unterstützt Secrets, die Diensten gezielt zur Verfügung gestellt werden können. Docker empfiehlt dies gegenüber dem direkten Einbetten sensibler Werte in Compose-Dateien oder Images. [S061]

Ein Secret gehört nicht:

• in Dockerfile,
• in Git,
• in öffentliches Image,
• in Build-Argumente, wenn es im Verlauf sichtbar werden kann,
• in Logausgaben.

Rootless Mode

FAKT: Docker bietet Rootless Mode, bei dem Daemon und Container ohne Rootrechte des Hosts betrieben werden können. Voraussetzungen und Einschränkungen sind systemabhängig. [S063]

EMPFEHLUNG: Für ernsthaften Serverbetrieb prüfen, ob Rootless oder andere Härtung zur Architektur passt. Es ist kein Ersatz für sichere Images, minimale Containerrechte und Updates.

Versionsangaben bei Images

Schwach:

``yaml image: postgres:latest ``

Stärker kontrollierbar:

``yaml image: postgres:18.1 ``

oder ein bewusst gepflegter kompatibler Tag.

EMPFEHLUNG: Versionen dokumentieren und Updates testen. Ein dauerhaft gepinnter alter Stand ist ebenfalls riskant; Reproduzierbarkeit und Aktualisierung müssen zusammen gedacht werden.

Docker-Betriebscheck

Vor Staging oder Produktion:

• Images und Herkunft geprüft,
• Ports minimiert,
• Secrets getrennt,
• Volumes inventarisiert,
• Datenbankbackup getestet,
• Healthchecks vorhanden,
• Logs begrenzt und auswertbar,
• Neustartverhalten definiert,
• Updateweg dokumentiert,
• Rollback möglich.

Docker-Prompt

VORLAGE:

``text Analysiere compose.yaml`, Dockerfiles und zugehörige Konfiguration. Führe noch nichts aus.

Erstelle eine Tabelle mit:

• Service,
• Image und Version,
• Ports,
• Netzwerken,
• Bind Mounts und Volumes,
• Secrets/Umgebungsvariablen,
• Benutzer/Rechten,
• persistierenden Daten,
• Backupbedarf,
• Sicherheitsrisiken.

Markiere besonders Hostzugriffe, Docker-Socket, privileged, öffentliche Datenbankports und unversionierte Images. Zeige danach den sichersten lokalen Startbefehl. Kein down -v, Prune oder Volume-Löschen. ```

\newpage

Datenbanken, Dateien und Secrets

Drei grundsätzlich verschiedene Datenarten

Quellcode

In Git versionierbar.

Konfiguration

Teilweise versionierbar, sofern keine Secrets. Umgebungsabhängige Werte getrennt.

Betriebsdaten

Datenbankeinträge, Uploads, Dateien, Protokolle. Benötigen eigenes Backup und Lebenszyklus.

Diese Trennung verhindert den Denkfehler, ein GitHub-Repository sichere die gesamte Anwendung.

Datenbankwahl

SQLite

Eine Datenbankdatei, einfacher Betrieb, geeignet für bestimmte kleine oder lokale Anwendungen. Gleichzeitigkeit und Produktionsanforderungen prüfen.

PostgreSQL

Vollwertiger Datenbankserver mit mehreren Backupverfahren und umfangreichen Funktionen.

MySQL/MariaDB

Ebenfalls verbreiteter Datenbankserver, häufig bei PHP- und CMS-Systemen.

EMPFEHLUNG: Nicht nach Beliebtheit entscheiden. Prüfen:

• gleichzeitige Nutzer,
• Transaktionen,
• Datenmenge,
• Hostingunterstützung,
• Backup/Restore,
• Teamkenntnis,
• Erweiterungen,
• Migrationsweg.

Datenbankmigrationen

Migrationen verändern Schema oder Daten:

``text Tabelle anlegen Spalte ergänzen Index hinzufügen Daten umformen ``

Risiken:

• lange Sperren,
• inkompatibler Anwendungscode,
• Datenverlust,
• nicht rückgängig machbare Transformation,
• unterschiedliche Stände zwischen lokal und Produktion.

EMPFEHLUNG: Vor produktiver Migration:

1. Migration im Testdatenbestand ausführen.
2. Dauer und Sperrverhalten prüfen.
3. Backup beziehungsweise Rückfallstand herstellen.
4. Kompatibilität der alten und neuen Anwendung bewerten.
5. exakte Version dokumentieren.
6. nach Migration Datenkonsistenz prüfen.

Datenbankbackups sind systemspezifisch

FAKT: PostgreSQL unterscheidet unter anderem SQL-Dumps, Dateisystem-/physische Backups und kontinuierliche Archivierung. [S072]

FAKT: MySQL dokumentiert logische und physische Backup- sowie Recovery-Verfahren. [S073]

FAKT: SQLite stellt eine Backup-API bereit; bloßes Kopieren einer aktiven Datenbankdatei muss hinsichtlich Konsistenz bewertet werden. [S074]

EMPFEHLUNG: Claude darf keinen generischen „Datenbankbackup erledigt“-Befehl erfinden. Datenbanktyp, Version, Größe, Betriebsmodus und Restore-Ziel müssen bekannt sein.

Uploads und Dateien

Viele Anwendungen speichern Dateien außerhalb der Datenbank:

• Produktbilder,
• Dokumente,
• Rechnungen,
• Avatare,
• generierte PDFs.

Das Backup muss Datenbank und Dateien zeitlich konsistent berücksichtigen. Sonst verweist die Datenbank nach Restore auf fehlende Dateien oder umgekehrt.

Was ein Secret ist

Secrets sind Werte, deren Offenlegung Zugriff oder Missbrauch ermöglicht:

• Passwörter,
• API-Tokens,
• private Schlüssel,
• Datenbankzugänge,
• Session-Schlüssel,
• OAuth-Client-Secrets,
• Signierschlüssel.

.env als Anfängerwerkzeug

Eine lokale .env ist praktisch:

``dotenv DATABASE_URL=postgresql://... MAIL_PASSWORD=... SESSION_SECRET=... ``

.gitignore:

``gitignore .env .env.local .env.production ``

Repository:

```dotenv

.env.example

DATABASE_URL= MAIL_PASSWORD= SESSION_SECRET= ```

EMPFEHLUNG: .env ist eine einfache lokale Konfigurationsmethode, aber kein vollständiges Enterprise-Secretsystem. Zugriff, Dateirechte, Backups und Prozessumgebung bleiben relevant.

Warum Umgebungsvariablen nicht automatisch geheim sind

FAKT: OWASP weist darauf hin, dass Secrets in Umgebungsvariablen unter Umständen über Prozesse, Logs, Dumps oder Fehlkonfiguration sichtbar werden können. Bevorzugt werden spezialisierte Secret-Management-Verfahren. [S083]

FAKT: Twelve-Factor empfiehlt, deployabhängige Konfiguration in der Umgebung statt im Code zu halten. Das ist eine Architekturregel, aber keine Garantie, dass jeder Umgebungswert vertraulich geschützt ist. [S094]

Secret Stores

Produktionsmöglichkeiten:

• Secret-Funktion der Hostingplattform,
• CI/CD-Secrets,
• Vault/KMS/Cloud Secret Manager,
• Docker/Orchestrator-Secrets,
• systemeigene geschützte Credential Stores.

GitHub Actions kann Secrets separat speichern und Workflows gezielt bereitstellen. [S040]

Secret in Git – Sofortmaßnahmen

1. Secret sperren oder rotieren.
2. Missbrauch und Logs prüfen.
3. aktuellen Repositorybestand bereinigen.
4. Historie bei Bedarf fachgerecht bereinigen.
5. alle Klone und Deployments berücksichtigen.
6. Schutzregeln ergänzen.

FAKT: GitHub dokumentiert das Entfernen sensibler Daten aus Repositories und weist auf Auswirkungen für Historie und Klone hin. [S041]

FAKT: Secret Scanning und Push Protection können bekannte Secretmuster erkennen und Pushes verhindern, abhängig von Produktverfügbarkeit und Konfiguration. [S038] [S039]

Passwörter in Logs

Claude darf beim Debugging nicht einfach:

``text Gib mir die komplette .env und alle Logs. ``

verlangen.

Besser:

• Variablennamen ohne Werte,
• redigierte Logs,
• Fehlerklasse und Zeitstempel,
• minimale reproduzierbare Testkonfiguration.

Verschlüsselung

FAKT: OWASP empfiehlt etablierte kryptografische Verfahren, sichere Schlüsselverwaltung und Trennung von Schlüssel und verschlüsselten Daten. Eigene Kryptografie sollte vermieden werden. [S095]

EMPFEHLUNG: Claude darf keine selbst erfundene Verschlüsselungsmethode implementieren. Standardbibliotheken und etablierte Protokolle verwenden; Schlüssel außerhalb des Codes verwalten.

Dateninventar

Vor Produktion eine Tabelle führen:

Secret-Prompt

VORLAGE:

```text Prüfe die Secret-Handhabung dieses Projekts defensiv. Gib keine gefundenen Secret-Werte aus.

Prüfe:

• versionierte Dateien,
• .gitignore,
• .env.example,
• Logs und Fehlermeldungen,
• Dockerfiles/Compose,
• CI/CD,
• Dokumentation,
• Testdaten,
• private Schlüssel und Zertifikate.

Melde nur Dateipfad, Secret-Art und Risiko, redigiere Werte vollständig. Verändere nichts. Falls ein Secret wahrscheinlich veröffentlicht wurde, nenne Rotation als ersten Schritt und danach Bereinigung der Historie. ```

\newpage

Deployment, Domain, DNS und HTTPS

Deployment ist ein kontrollierter Zustandswechsel

Deployment bedeutet:

Eine definierte, geprüfte Version wird reproduzierbar in eine Zielumgebung gebracht und anschließend verifiziert.

Nicht ausreichend:

„Ich habe ein paar Dateien per FTP hochgeladen.“

Drei einfache Deploymentmodelle

Statische Website

``text Quellcode → optional Build → HTML/CSS/JS/Assets → Webroot/Hosting → Smoke-Test ``

PHP-Anwendung

``text Release → Abhängigkeiten → Konfiguration → Webroot → Migration → Rechte/Cache → Smoke-Test ``

Container-Anwendung

``text Image/Compose → Registry oder Buildziel → Secrets/Volumes → Migration → Servicewechsel → Healthcheck ``

Staging und Produktion trennen

Staging sollte besitzen:

• eigene URL,
• eigene Datenbank beziehungsweise Testdaten,
• eigene Secrets,
• produktionsähnliche Runtime,
• Schutz vor Suchmaschinen oder unberechtigtem Zugriff,
• klaren Resetweg.

Produktion besitzt:

• echte Domain,
• echte Benutzer und Daten,
• striktere Rechte,
• Monitoring und Backup,
• verantwortliche Freigabe.

Release-Identität

Jedes Deployment muss auf einen identifizierbaren Stand verweisen:

• Git-Commit,
• Tag,
• Buildnummer,
• Container-Image-Digest.

Sonst ist später unklar, welcher Code tatsächlich läuft.

Domain registrieren

Eine Domain wird bei einem Registrar oder Hostinganbieter verwaltet. Dort werden Inhaber-, Abrechnungs- und DNS-Einstellungen geführt.

FAKT: Eine Domain ist ein hierarchischer Name; DNS ordnet Namen unter anderem IP-Adressen oder anderen Diensten zu. [S042] [S043]

Wichtige DNS-Einträge

A

Name zeigt auf eine IPv4-Adresse.

AAAA

Name zeigt auf eine IPv6-Adresse.

CNAME

Name zeigt als Alias auf einen anderen Namen.

MX

Mailserver für die Domain.

TXT

Textinformationen, häufig für Verifikation, SPF, DKIM oder andere Zwecke.

EMPFEHLUNG: DNS-Änderungen dokumentieren. Falsche MX-, SPF- oder DKIM-Änderungen können E-Mail-Zustellung beeinträchtigen.

DNS braucht Zeit

DNS-Antworten werden zwischengespeichert. Änderungen sind nicht überall sofort sichtbar. Die Dauer hängt unter anderem von TTL und Resolver-Caches ab.

EMPFEHLUNG: Nicht nach wenigen Minuten hektisch mehrere widersprüchliche Änderungen vornehmen. Vorherige Werte sichern und gezielt prüfen.

Webserver und DNS sind getrennt

Apache-Virtual-Host:

``apache ServerName www.beispiel.de ``

DNS:

``text www.beispiel.de → Server-IP ``

Beides muss zusammenpassen. Apache legt keinen DNS-Eintrag an. [S046]

HTTPS mit Let’s Encrypt

FAKT: Let’s Encrypt überprüft Domainkontrolle über Challenge-Verfahren. HTTP-01 verwendet typischerweise eine Datei beziehungsweise Antwort über Port 80 und unterstützt keine Wildcard-Zertifikate. DNS-01 nutzt DNS-TXT-Einträge und kann Wildcards ermöglichen. [S049]

Certbot kann je nach System und Webserver Zertifikate beziehen und Konfiguration unterstützen. Die konkreten Installationsanweisungen sind betriebssystem- und versionsabhängig. [S050]

Beispiel aus dokumentierten Apache-Anweisungen kann lauten:

``bash sudo certbot --apache ``

Test der Erneuerung:

``bash sudo certbot renew --dry-run ``

Refresh nötig: Immer den aktuellen Certbot-Assistenten für genaue Distribution und Webserver verwenden. Die in der Quellenliste referenzierte Ubuntu-Auswahl kann vor Buchveröffentlichung veraltet sein.

Zertifikat ist nicht gleich sichere Anwendung

HTTPS schützt den Transport. Es verhindert nicht:

• fehlerhafte Authentifizierung,
• SQL Injection,
• unsichere Datei-Uploads,
• kompromittierte Server,
• geleakte API-Schlüssel,
• falsche Benutzerrechte.

Rollback

Ein Rollback bringt die Anwendung auf einen vorherigen Softwarestand. Das ist nicht immer dasselbe wie ein Datenbank-Restore.

Problem:

``text neue Anwendung migriert Datenbank → alte Anwendung versteht neues Schema nicht ``

EMPFEHLUNG: Vor Release klären:

• Kann alter Code mit neuem Schema laufen?
• Gibt es reversible Migration?
• Ist Restore statt Rollback nötig?
• Wie lange würde er dauern?

Smoke-Test nach Deployment

Mindestens:

• Startseite lädt über HTTPS,
• zentrale API/Seite erreichbar,
• Login funktioniert,
• Lesen und Schreiben zentraler Daten,
• E-Mail-/externes System in kontrolliertem Test,
• Logs ohne neue kritische Fehler,
• richtige Version sichtbar.

Deployment-Protokoll

``text Datum/Uhrzeit: Umgebung: Commit/Tag/Image: Freigabe: Backupstatus: Migration: Deploymentweg: Smoke-Test: Probleme: Rollback nötig: ``

Produktions-Skill

VORLAGE:

```markdown

name: deploy-production description: Veröffentlicht eine freigegebene Version in Produktion. disable-model-invocation: true

Verlange exaktes Ziel, Commit/Tag, Backupstatus, Rollbackweg und Freigabe. Führe Tests und Build aus. Zeige Plan und exakte Befehle. Führe erst nach einer zweiten ausdrücklichen Bestätigung aus. Prüfe danach Healthcheck, Logs und zentrale Benutzerwege. ```

Klassisches FTP-Deployment

FTP/SFTP kann für kleine statische oder PHP-Projekte funktionieren. Nachteile manueller Einzeluploads:

• unklarer Versionsstand,
• vergessene Dateien,
• teilweise Veröffentlichung,
• kein automatischer Rollback,
• Live-Änderungen ohne Prüfung.

EMPFEHLUNG: Mindestens lokal ein Releasepaket erzeugen, Backup des Zielstands herstellen und alle Dateien als benannte Version übertragen. SFTP statt unverschlüsseltem FTP bevorzugen. [S067]

\newpage

Tests, Barrierefreiheit, Performance und Sicherheit

Warum „funktioniert bei mir“ nicht genügt

Eine Anwendung kann:

• starten, aber fachlich falsche Ergebnisse liefern,
• im Desktop funktionieren, mobil scheitern,
• positive Fälle bestehen, Fehlerfälle verlieren,
• schnell erscheinen, aber unter Last brechen,
• korrekt aussehen, aber nicht per Tastatur bedienbar sein,
• Tests bestehen und trotzdem unsicher sein.

Tests müssen deshalb mehrere Ebenen abdecken.

Testpyramide in einfacher Form

Unit Tests

Prüfen kleine Logikeinheiten.

Integrationstests

Prüfen Zusammenspiel von Komponenten, Datenbank oder APIs.

End-to-End-Tests

Prüfen einen echten Benutzerweg im Browser.

Manueller Abnahmetest

Prüft fachliche Richtigkeit, Darstellung und nicht automatisierte Anforderungen.

Akzeptanzkriterien

Schlecht:

``text Kontaktformular funktioniert. ``

Besser:

```text

• Pflichtfelder blockieren leere Übermittlung.
• Ungültige E-Mail-Adresse zeigt verständliche Meldung.
• Erfolgreiche Anfrage wird genau einmal gespeichert/gesendet.
• Mailfehler zeigt keinen falschen Erfolg.
• Formular ist per Tastatur bedienbar.
• personenbezogene Werte erscheinen nicht im Fehlerlog.

```

Playwright

FAKT: Playwright unterstützt Browserautomatisierung, Assertions und automatisches Warten auf erwartete Zustände. Die Best-Practice-Dokumentation empfiehlt benutzerorientierte Locators und isolierte Tests. [S077] [S078]

Geeignet für:

• Navigation,
• Formularabläufe,
• Login,
• mobile Viewports,
• visuelle und funktionale Browserprüfungen.

Nicht jeder Test muss Playwright verwenden. Für eine statische Mini-Seite kann manueller Browsercheck zunächst genügen.

Claude als Verifikationsagent

FAKT: Claude Code kann Tests, Build und gestartete Anwendung verwenden, um Ergebnisse zu überprüfen. Aktuelle gebündelte Skills /run und /verify unterstützen praktische Prüfung je nach Projekt. [S006] [S012]

EMPFEHLUNG: Claude soll Ergebnisse nicht nur anhand von Code beurteilen, sondern die Anwendung tatsächlich starten, wenn dies sicher und möglich ist.

Lighthouse

FAKT: Lighthouse analysiert unter anderem Performance, Accessibility, Best Practices und SEO und kann auch automatisiert eingesetzt werden. [S079]

Grenze:

• Score ist Momentaufnahme,
• Umgebung beeinflusst Messung,
• automatisierte Accessibility-Prüfung deckt nicht alle WCAG-Anforderungen ab,
• gute Punktzahl ist kein vollständiger Qualitätsnachweis.

WCAG 2.2

FAKT: WCAG 2.2 wurde am 05.10.2023 als W3C Recommendation veröffentlicht; die Übersichtsseite nennt einen Aktualisierungsstand 12.12.2024. [S076]

Wichtige praktische Prüfbereiche:

• Tastaturbedienung,
• sichtbarer Fokus,
• ausreichende Kontraste,
• Beschriftung von Feldern,
• verständliche Fehlermeldungen,
• semantische Struktur,
• Zoom und mobile Darstellung.

Performance

Prüfen:

• Bildgrößen,
• JavaScript-Bündel,
• Serverantwort,
• Datenbankabfragen,
• Caching,
• externe Skripte,
• langsame Mobilverbindung.

EMPFEHLUNG: Nicht nur lokale High-End-Hardware testen. Mobile Simulation und reale Endgeräte einbeziehen.

Sicherheitstests

Sicherheitsprüfung umfasst mindestens:

• Authentifizierung,
• Autorisierung,
• Eingabevalidierung,
• Ausgabekodierung,
• Sitzungen und Cookies,
• Uploads,
• Secret-Handhabung,
• Abhängigkeiten,
• Fehlermeldungen,
• Logging,
• Datenbankzugriffe.

FAKT: OWASP Top 10 und Secure Code Review bieten verbreitete Referenzen für Webrisiken und Reviewverfahren. [S080] [S084]

Generative-KI-spezifische Entwicklungssicherheit

FAKT: NIST SP 800-218A ergänzt sichere Softwareentwicklungspraktiken um Risiken generativer KI. [S085]

Praktische Konsequenzen:

• KI-generierten Code nicht anders behandeln als fremden Code,
• Herkunft und Lizenz von Abhängigkeiten prüfen,
• Tests und Review verlangen,
• Modell- und Toolzugriffe minimieren,
• Trainings-/Promptdaten nicht ungeprüft in Projekte übernehmen,
• sichere Entwicklungsumgebung aufrechterhalten.

Abhängigkeiten

Claude kann schnell neue Pakete hinzufügen. Jedes Paket erhöht:

• Lieferkettenrisiko,
• Updatebedarf,
• Lizenzfragen,
• Buildgröße,
• mögliche Inkompatibilität.

EMPFEHLUNG: Vor Installation:

• Ist Paket wirklich nötig?
• Gibt es Standardbibliothek?
• Wer pflegt es?
• Welche Version?
• Welche Lizenz?
• Gibt es bekannte Risiken?

Testnachweis

Am Ende eines Auftrags sollte Claude berichten:

```text Ausgeführt:

• npm test: bestanden, 42 Tests
• npm run build: bestanden
• Playwright: 6 Szenarien bestanden
• manueller Check: Desktop und mobile Navigation

Nicht ausgeführt:

• echter Mailversand
• Produktionsdatenbankmigration

Offene Risiken:

• Safari nicht praktisch getestet

```

Diese Form ist wertvoller als „Alles funktioniert jetzt“.

Code Review

Ein Review fragt:

• Entspricht Änderung der Spezifikation?
• Ist sie unnötig komplex?
• Sind Fehlerfälle behandelt?
• Sind Berechtigungen korrekt?
• Gibt es sensible Ausgaben?
• Sind Tests aussagekräftig?
• Ist Betrieb dokumentiert?

Claude kann reviewen. Bei kritischen Projekten sollte eine unabhängige menschliche oder zweite technische Prüfung hinzukommen.

Definition of Done

VORLAGE: Eine Funktion ist erst fertig, wenn:

• Akzeptanzkriterien erfüllt,
• Tests bestanden,
• zentrale UI praktisch geprüft,
• Sicherheitsauswirkungen bewertet,
• Dokumentation aktualisiert,
• keine Secrets enthalten,
• Git-Diff verstanden,
• Commit hergestellt,
• Deploymentweg bei Bedarf aktualisiert.

\newpage

Backup, Restore und Katastrophenfälle

Backup beginnt mit einem Inventar

Zu sichern sind möglicherweise:

• Git-Repository,
• Datenbank,
• Uploads und Dokumente,
• Docker-Volumes,
• Konfiguration,
• Secrets beziehungsweise deren Wiederbereitstellungsweg,
• Serverkonfiguration,
• DNS-Dokumentation,
• Zertifikats-/Schlüsselmaterial,
• externe Dienste und SaaS-Exporte.

Ohne Inventar ist die Aussage „Wir haben ein Backup“ unvollständig.

Git, Snapshot und Backup

3-2-1

FAKT: CISA und Synology empfehlen sinngemäß mehrere Kopien, unterschiedliche Medien beziehungsweise Ziele und eine externe Kopie. Synology formuliert die 3-2-1-Regel ausdrücklich. [S055] [S075]

Praktisches Beispiel:

```text

1. Produktionsdaten
2. lokale/NAS-Backupkopie
3. verschlüsselte externe Kopie

```

RPO und RTO

RPO – Recovery Point Objective

Wie viel Datenverlust ist höchstens akzeptabel?

Beispiel: maximal 24 Stunden.

RTO – Recovery Time Objective

Wie lange darf Wiederherstellung dauern?

Beispiel: maximal 4 Stunden.

EMPFEHLUNG: Auch kleine Projekte sollten eine einfache Aussage treffen. Ohne Ziel lässt sich keine sinnvolle Backupfrequenz bestimmen.

Backuphäufigkeit

Abhängig von Datenänderung:

• statische Website: bei Release,
• Kontaktanfragen: täglich oder häufiger,
• Shop/Portal: deutlich häufiger,
• Finanz-/Transaktionssystem: projektspezifisch, möglicherweise kontinuierlich.

Pauschale tägliche Sicherung ist nicht für jedes System ausreichend.

Mehrversionigkeit

Ein synchronisiertes Ziel kann Löschungen oder Verschlüsselung sofort mitübertragen. Mehrversionige Backups erlauben Rückkehr zu älteren Zuständen.

EMPFEHLUNG: Aufbewahrungsplan definieren, etwa mehrere tägliche, wöchentliche und monatliche Stände. Konkrete Zahlen hängen von Daten, Kosten und Pflichten ab.

Verschlüsselung und Schlüssel

Ein verschlüsseltes Backup ist nur wiederherstellbar, wenn Schlüssel oder Passwort verfügbar sind.

Sicherungsplan muss deshalb enthalten:

• wo Schlüssel verwahrt wird,
• wer Zugriff besitzt,
• wie Vertretung funktioniert,
• was bei Verlust geschieht.

Schlüssel nicht ausschließlich auf demselben Gerät wie das Backup speichern.

Restore-Test

Ein Backup gilt erst als belastbar, wenn es wiederhergestellt wurde.

Testablauf:

1. isolierte leere Zielumgebung,
2. konkreten Backupstand wählen,
3. Integrität prüfen,
4. Datenbank wiederherstellen,
5. Dateien/Volumes wiederherstellen,
6. Konfiguration und Secrets bereitstellen,
7. Anwendung starten,
8. Login, Lesen, Schreiben und zentrale Prozesse testen,
9. Dauer und Fehler dokumentieren.

Datenbank- und Dateikonsistenz

Wenn Datenbank um 02:00 Uhr und Uploads um 04:00 Uhr gesichert werden, können Verweise nicht zusammenpassen.

Möglichkeiten:

• anwendungskonsistente Sicherung,
• Wartungsfenster,
• Snapshots koordinierter Speicher,
• Transaktions-/WAL-Verfahren,
• Objektspeicher mit Versionierung.

Die richtige Methode ist systemspezifisch.

Docker-Backups

Zu sichern:

• Compose-/Deploymentdateien in Git,
• Images oder reproduzierbarer Buildweg,
• Datenbank logisch/physisch,
• Volumes/Bind-Mount-Daten,
• Secrets-Wiederbereitstellung,
• Reverse-Proxy- und Serverkonfiguration.

Nur docker compose config oder ein exportiertes Image sichert nicht automatisch persistente Volumes. [S060]

Synology-Backups

Mögliche Schichten:

• Snapshot Replication für schnelle lokale Zustände,
• Hyper Backup auf externes Laufwerk, zweites NAS oder Cloudziel,
• Repository-Remote,
• getrennte Datenbankdumps.

EMPFEHLUNG: Nicht alle Kopien auf derselben Synology und demselben Volume halten.

VPS-Backup

Anbieter-Snapshot ist nützlich, aber nicht zwangsläufig ausreichend:

• möglicherweise gleiches Anbieter-Risiko,
• ungeklärte Konsistenz aktiver Datenbanken,
• Abhängigkeit vom Konto,
• Restore nicht getestet.

Zusätzlich anwendungsbezogene Backups auf unabhängiges Ziel.

Katastrophenfälle

Secret wurde veröffentlicht

• sperren/rotieren,
• Zugriffe prüfen,
• Git/Logs bereinigen,
• Schutz ergänzen.

Datenbankmigration zerstört Daten

• Anwendung stoppen oder Schreibzugriff begrenzen,
• Schaden dokumentieren,
• Rückfall-/Restoreplan ausführen,
• keine weiteren unkontrollierten Migrationen.

docker compose down -v

• keine neuen Daten schreiben,
• vorhandene Backups/Volume-Snapshots prüfen,
• Restore in isolierter Umgebung,
• Ursache und Schutzregel dokumentieren.

NAS fällt aus

• externes Backup und Schlüssel beschaffen,
• Ersatzgerät/Ziel vorbereiten,
• Restore-Verfahren ausführen,
• DNS oder Dienstziel kontrolliert umstellen.

Server kompromittiert

• isolieren,
• Zugangsschlüssel rotieren,
• Forensik/Logs sichern,
• nicht einfach „bereinigen“ und weiterbetreiben,
• aus vertrauenswürdigem Stand neu aufbauen,
• Datenintegrität prüfen.

Backup-Check-Skill

```markdown

name: backup-check description: Prüft Backup- und Restore-Fähigkeit des Projekts. context: fork background: false

Inventarisiere Code, Datenbank, Uploads, Volumes, Konfiguration, Secrets und externe Dienste. Bewerte Methode, Häufigkeit, Aufbewahrung, externes Ziel und letzten Restore-Test. Verändere oder lösche nichts. ```

Restore-Skill

Ein Restore-Skill muss manuell sein:

``yaml disable-model-invocation: true ``

Er fordert:

• eindeutiges Ziel,
• eindeutigen Backupstand,
• zulässige Überschreibungen,
• Integritätsprüfung,
• Bestätigung vor jedem destruktiven Schritt.

Die wichtigste Backup-Regel

Nicht die grüne Meldung „Backup erfolgreich“ beweist die Sicherheit, sondern ein dokumentierter erfolgreicher Restore.

\newpage

Das vollständige Praxisprojekt

Ausgangssituation

Fiktives Unternehmen:

``text Musterbau Haustechnik GmbH Region: Ostwestfalen Leistungen: Heizung, Sanitär, Wärmepumpen, Wartung Ziel: qualifizierte Anfragen und verständliche Leistungsdarstellung ``

Der Geschäftsführer kann Websites bedienen, aber nicht programmieren. Er verwendet Windows oder macOS, Claude Code, Git und Browser. Eine Synology ist optional als internes Test- und Backupziel vorhanden. Die öffentliche Website soll später auf einem geeigneten Hosting oder VPS laufen.

Warum dieses Projekt geeignet ist

Es enthält:

• öffentliches Frontend,
• mehrere Inhaltsseiten,
• Bilder,
• Kontaktformular,
• personenbezogene Anfragewerte,
• E-Mail-Versand,
• mobile Darstellung,
• Domain und HTTPS,
• Backup und Wartung.

Gleichzeitig bleibt der Umfang überschaubar.

Phase 1: Idee im normalen Chat klären

Erste Diskussion:

``text Wir benötigen eine neue Website für einen regionalen Haustechnikbetrieb. Das Ziel sind qualifizierte Anfragen, nicht ein Onlineshop. Die Website soll seriös, schnell und auf Mobilgeräten verständlich sein. ``

Noch nicht fragen:

``text Schreib mir sofort den kompletten Code. ``

Stattdessen die offenen fachlichen Fragen sammeln:

• Welche Leistungen sind wirtschaftlich wichtig?
• Welche Orte werden bedient?
• Welche Einwände haben Kunden?
• Welche Nachweise, Zertifikate und Referenzen existieren?
• Welche Anfragearten sollen getrennt werden?
• Wer beantwortet Anfragen?

Das Ergebnis wird als Rohmaterial in das Projekt übertragen.

Phase 2: lokalen Projektordner anlegen

Windows PowerShell

``powershell mkdir C:\Projekte\musterbau-website cd C:\Projekte\musterbau-website ``

macOS

``bash mkdir -p ~/Projekte/musterbau-website cd ~/Projekte/musterbau-website ``

Danach prüfen:

``bash pwd git --version claude --version ``

Phase 3: Starterkit kopieren

Kopiert werden:

``text CLAUDE.md SPEC.md README.md .gitignore .env.example docs/ .claude/ prompts/ ``

EMPFEHLUNG: Die Vorlagen nicht als unveränderliche Norm behandeln. Unpassende Teile löschen, projektbezogene Befehle später ergänzen.

Phase 4: Git initialisieren

``bash git init git status ``

Vor erstem Commit kontrollieren:

• .env nicht vorhanden oder ignoriert,
• keine privaten Bilder oder Kundendaten,
• keine Zugangsdaten,
• keine unnötigen Binärdateien.

Erster Commit nach Prüfung:

``bash git add CLAUDE.md SPEC.md README.md .gitignore .env.example docs .claude prompts git commit -m "Projektgrundlage und Entwicklungsleitplanken anlegen" ``

Claude darf diesen Commit nach ausdrücklichem Auftrag vorbereiten.

Phase 5: Claude Code starten

``bash claude ``

Erster Auftrag:

``text Lies CLAUDE.md und die vorhandenen Vorlagen. Führe /project-spec aus. Implementiere noch nichts. ``

Phase 6: Projektinterview

Claude klärt beispielsweise:

Ziel

• mehr qualifizierte Wärmepumpen- und Wartungsanfragen,
• weniger allgemeine unpassende Anfragen,
• Vertrauen durch klare Leistungen und regionale Erreichbarkeit.

Benutzer

• Eigenheimbesitzer,
• Hausverwaltungen,
• Bestandskunden mit Wartungsbedarf.

Muss-Funktionen

• Startseite,
• Leistungsseiten,
• Über-uns-Seite,
• Kontaktmöglichkeiten,
• Anfrageformular,
• Impressum und Datenschutz,
• mobil nutzbar.

Daten

Formularfelder:

• Name,
• E-Mail,
• Telefon optional,
• Ort,
• Anliegen,
• Nachricht,
• Einwilligungs-/Hinweistext entsprechend rechtlicher Prüfung.

Hosting

• lokale Entwicklung,
• internes NAS-Staging optional,
• öffentliche Produktion auf Managed Hosting oder VPS.

Offene Entscheidungen

• PHP oder externer Formulardienst?
• Bilder vorhanden?
• Tracking überhaupt nötig?
• Cookie-Einwilligung abhängig von eingesetzten Diensten?
• Wartungsverantwortlicher?

Rechtliche Texte werden nicht erfunden. Sie benötigen gesonderte rechtliche Prüfung.

Phase 7: Architektur wählen

Drei Varianten:

Variante A: vollständig statisch, Kontakt per mailto:

Vorteil: sehr einfacher Betrieb. Nachteil: schlechte Nutzerführung, kein kontrollierter Versand.

Variante B: statische Seiten plus kleines PHP-Formular

Vorteil: klassisches Hosting und Apache/Synology gut geeignet. Nachteil: serverseitige Validierung, Mailkonfiguration, Spam-Schutz und Logs erforderlich.

Variante C: modernes Framework plus API

Vorteil: flexibel. Nachteil: für diesen Zweck möglicherweise unnötig komplex.

EMPFEHLUNG für das Beispiel: Variante B, sofern Hosting PHP unterstützt. Die Entscheidung wird als ADR dokumentiert.

``text ADR 0001: Statische Inhaltsseiten mit kleinem PHP-Formular ``

Phase 8: Projektstruktur

``text musterbau-website/ ├── public/ │ ├── index.html │ ├── leistungen/ │ ├── ueber-uns/ │ ├── kontakt/ │ ├── assets/ │ │ ├── css/ │ │ ├── js/ │ │ └── images/ │ └── kontakt-senden.php ├── src/ ├── tests/ ├── docs/ ├── CLAUDE.md ├── SPEC.md └── .claude/ ``

Die genaue Struktur hängt vom Buildweg ab. Bei reinem HTML kann public/ direkt der auszuliefernde Ordner sein.

Phase 9: Start- und Testweg festlegen

Lokal zunächst:

``bash python -m http.server 8000 --directory public ``

oder:

``bash python3 -m http.server 8000 --directory public ``

Die statischen Seiten sind dann unter:

``text http://localhost:8000 ``

sichtbar.

Grenze: Das PHP-Formular läuft damit nicht. Dafür ist eine PHP-fähige lokale Umgebung, Container, Apache oder ein separates Testziel nötig.

Diese Trennung wird dokumentiert:

• statische UI lokal über einfachen Server,
• Formularintegration in PHP-Testumgebung,
• kein echter Mailversand im UI-Prototyp.

Phase 10: Grundgerüst implementieren

Prompt:

```text Implementiere nur das statische Grundgerüst gemäß SPEC.md:

• semantische HTML-Struktur,
• responsive Navigation,
• Startseite,
• zentrale CSS-Basis,
• Platzhalter für echte, freigegebene Inhalte und Bilder.

Verwende keine erfundenen Auszeichnungen, Kundenstimmen, Zahlen oder Zertifikate. Markiere fehlende Inhalte sichtbar als TODO in der Dokumentation, nicht als Marketingbehauptung auf der öffentlichen Seite.

Starte die Website lokal und prüfe Desktop und mobile Breite. Kein Kontaktformular-Backend, kein Commit. ```

Dieser Punkt ist besonders wichtig: Claude darf keine Referenzen oder Leistungsversprechen erfinden.

Phase 11: Grundgerüst prüfen

Claude führt aus:

• lokaler Start,
• Linkprüfung,
• mobile Navigation,
• HTML-/Browserfehler,
• Lighthouse als Hinweis,
• Tastaturbedienung.

Der Benutzer prüft:

• wirkt die Seite glaubwürdig?
• stimmen Leistungen und Region?
• sind keine erfundenen Inhalte enthalten?
• ist die Sprache verständlich?

Danach Git:

``bash git status git diff ``

Commit:

``text Statisches responsives Website-Grundgerüst erstellen ``

Phase 12: echte Inhalte einarbeiten

Inhalte kommen aus:

• Unternehmensunterlagen,
• freigegebenen Leistungsbeschreibungen,
• echten Qualifikationen,
• echten Standorten,
• echten Kontaktdaten,
• rechtlich geprüften Pflichtangaben.

Prompt:

``text Überarbeite die folgenden freigegebenen Rohtexte für die Website. Erfinde keine Leistungen, Nachweise, Zahlen, Bewertungen oder Zertifikate. Kennzeichne jede inhaltliche Lücke als UNKLAR. Erhalte fachliche Bedeutung und regionale Zielsetzung. ``

Phase 13: Kontaktformular planen

Akzeptanzkriterien:

• serverseitige Validierung,
• Pflichtfelder,
• Begrenzung von Länge und Dateitypen, falls Upload,
• Spam-Schutz,
• verständliche Fehler- und Erfolgsmeldung,
• keine Geheimwerte im Browsercode,
• kein Logging vollständiger Nachrichten ohne Zweck,
• Mailfehler wird nicht als Erfolg dargestellt,
• Testmodus sendet nicht an echte Kunden.

Phase 14: Secrets vorbereiten

.env.example:

``dotenv MAIL_HOST= MAIL_PORT= MAIL_USER= MAIL_PASSWORD= MAIL_FROM= MAIL_TO= ``

Echte Werte:

• lokal in .env, wenn Framework/Implementierung dies unterstützt,
• auf Server über geschützte Konfiguration oder Secret Store,
• niemals in Git.

Phase 15: Formular implementieren

Prompt:

```text Implementiere das Kontaktformular entsprechend SPEC.md und ADR.

Untersuche zuerst vorhandene HTML-, PHP- und Konfigurationsdateien. Zeige Plan, Datenfluss und Sicherheitsrisiken.

Implementiere:

• serverseitige Validierung,
• sichere Ausgabe von Fehlermeldungen,
• CSRF-/Spam-Schutz entsprechend gewählter Architektur,
• getrennte Konfiguration ohne Secrets im Repository,
• Testmodus ohne echten Versand.

Erstelle Tests oder einen reproduzierbaren Testplan für Pflichtfelder, ungültige E-Mail, zu lange Eingaben, Spam-Szenario, Mailfehler und Erfolg. Kein produktiver Versand, Commit oder Deployment. ```

Phase 16: PHP lokal oder auf NAS testen

Möglichkeit A: lokaler Apache/PHP-Stapel

Projekt auf lokale PHP-Umgebung konfigurieren. DocumentRoot zeigt auf public/.

Möglichkeit B: Docker

Ein einfacher PHP/Apache-Container kann die Umgebung isolieren. Compose und Mounts müssen geprüft werden.

Möglichkeit C: Synology Web Station

• Webportal anlegen,
• PHP-Profil wählen,
• Projekt-Release in Webroot,
• nur im Heimnetz testen,
• Test-Mailtransport verwenden.

EMPFEHLUNG: Das NAS dient hier als Staging-Labor, nicht als improvisierter öffentlicher Produktionsserver.

Phase 17: Browser- und Fehlertests

Testmatrix:

Phase 18: Release-Prüfung

``text /project-audit /security-review /checkpoint ``

Ergebnis muss enthalten:

• Git-Diff,
• Tests,
• Build/Start,
• Secrets-Prüfung,
• offene rechtliche Inhalte,
• Backup- und Deploymentweg.

Phase 19: Remote-Repository

Optional GitHub oder eigener Remote:

``bash git remote add origin <REMOTE-URL> git push -u origin main ``

Push wird bestätigt. Vorher:

• Repository privat/öffentlich bewusst gewählt,
• keine Secrets,
• keine lizenzwidrigen Bilder,
• keine Kundendaten.

Phase 20: Staging-Deployment

Staging-Subdomain:

``text staging.musterbau.example ``

Schritte:

1. DNS auf Stagingziel.
2. Webserver/Hosting konfigurieren.
3. Secret-Werte setzen.
4. Release übertragen.
5. Datenbank oder Formularumgebung vorbereiten.
6. HTTPS aktivieren.
7. Passwort-/Zugriffsschutz prüfen.
8. Smoke-Test.
9. fachliche Abnahme.

Der Skill /deploy-staging fordert Ziel und Commit ausdrücklich an.

Phase 21: Backup vor Produktion

Für eine neue Website:

• Quellcode im Remote-Repository,
• aktuelles Releasepaket,
• Serverkonfiguration dokumentiert,
• eventuell vorhandene Datenbank gesichert,
• vorhandene Live-Website gesichert,
• DNS-Ausgangswerte dokumentiert,
• Restore-/Rollbackweg festgelegt.

Phase 22: Produktion

Vorbedingungen:

``text Commit: abc1234 Staging: abgenommen Tests: bestanden Backup: geprüft Rollback: dokumentiert Freigabe: Geschäftsführer ``

Dann /deploy-production manuell.

Der Skill zeigt:

• exakte Befehle,
• betroffene Dateien und Dienste,
• Migration,
• erwartete Unterbrechung,
• Rollback.

Erst nach zweiter Bestätigung wird ausgeführt.

Phase 23: DNS und HTTPS

• Domain zeigt auf Produktionsziel.
• Apache/Hosting kennt die Domain.
• Zertifikat wird ausgestellt.
• HTTP wird sinnvoll auf HTTPS umgeleitet.
• www und Hauptdomain werden bewusst behandelt.
• E-Mail-DNS wird nicht unbeabsichtigt verändert.

Phase 24: Nachkontrolle

Direkt nach Veröffentlichung:

• Startseite,
• alle Hauptseiten,
• mobile Navigation,
• Formular im kontrollierten echten Test,
• HTTPS und Zertifikatskette,
• Logs,
• richtige Umgebung/Version,
• keine Staging-Sperre auf Produktion,
• keine Suchmaschinenfreigabe auf Staging.

Phase 25: Betrieb dokumentieren

docs/deployment.md:

• Hostingzugang,
• ohne Secret-Werte,
• Releaseweg,
• Webroot,
• PHP-Version,
• Mailkonfiguration,
• Logs,
• Rollback.

docs/backup-restore.md:

• Quellcode,
• Formular-/Anfragedaten,
• Uploads,
• Serverkonfiguration,
• Frequenz,
• externes Ziel,
• Restore-Test.

Phase 26: spätere Änderung

Beispiel: neue Leistung „Badsanierung“.

```text

1. neues Issue/Ziel,
2. SPEC prüfen,
3. Branch anlegen,
4. Seite und Navigation ändern,
5. Tests/Links/mobile Ansicht,
6. Diff und Commit,
7. Staging,
8. Freigabe,
9. Produktion,
10. Nachkontrolle.

```

Der Prozess bleibt gleich. Genau darin liegt der Wert der Projektstruktur: Nicht nur die erste Erstellung, sondern jede spätere Änderung wird beherrschbar.

Was der Anfänger nach diesem Projekt beherrscht

Er muss nicht jedes PHP- oder CSS-Detail auswendig können. Er versteht jedoch:

• Projektordner,
• Claude-Code-Start,
• Spezifikation,
• Architekturentscheidung,
• Git und Commit,
• localhost,
• Apache/PHP-Test,
• NAS-Staging,
• Secrets,
• SFTP/SSH beziehungsweise Deployment,
• DNS und HTTPS,
• Backup und Restore,
• produktive Freigabe.

Das ist die angestrebte Zielperformance des Dossiers.

\newpage

Vor- und Nachteile – mit belastbarer Studienlage

Was sich sachlich als Vorteil begründen lässt

Schnelle Umsetzung klarer Teilaufgaben

Claude Code kann Projektdateien lesen, mehrere Dateien ändern, Befehle ausführen und Ergebnisse prüfen. Dadurch entfallen viele manuelle Zwischenschritte zwischen Gespräch, Editor und Terminal. [S001] [S005]

Zugang für fachliche Experten

Ein Fachanwender kann Regeln, Sonderfälle und Akzeptanzkriterien in natürlicher Sprache erklären. Anthropic fand in einer anbietereigenen Analyse von rund 400.000 Sitzungen, dass aufgabenspezifische Expertise stark mit besseren Sitzungsergebnissen zusammenhing und Berufsgruppen außerhalb klassischer Softwareentwicklung bei codeproduzierenden Sitzungen ähnliche lose Erfolgsraten erreichten. Die Auswertung basiert auf Klassifikatoren und Nutzungsdaten, nicht auf einer randomisierten Wirkungsstudie. [S025]

Projektweite Arbeit

Im Unterschied zu einem isolierten Codeblock kann Claude:

• Architektur untersuchen,
• Abhängigkeiten nachvollziehen,
• Tests und Dokumentation mitändern,
• Git-Diffs prüfen,
• lokale Anwendung starten.

Wiederverwendbare Standards

CLAUDE.md, Rules, Skills, Permissions, Hooks und Plugins erlauben, Projektwissen und Arbeitsabläufe dauerhaft zu strukturieren. [S007–S016]

Lernen am konkreten Projekt

Der Benutzer kann jede Datei, jeden Befehl und jede Architekturentscheidung erklären lassen. Das ersetzt keine Prüfung, senkt aber die Hürde, reale technische Zusammenhänge zu verstehen.

Höhere Reichweite einzelner Personen

Eine fachlich starke Person kann Prototypen, interne Werkzeuge oder standardisierte Websites umsetzen, für die vorher mehrere spezialisierte Einzelschritte nötig waren. Ob daraus wirtschaftlicher Nutzen entsteht, hängt von Qualität, Betrieb und tatsächlicher Nutzung ab.

Die realen Nachteile

Falsche Ergebnisse können ausführbar sein

Eine falsche Chatantwort ist ärgerlich. Ein falscher Shell-, Datenbank- oder Deploymentbefehl kann Daten löschen oder Dienste unterbrechen.

Plausibilität täuscht Sicherheit vor

Claude kann überzeugend erklären, obwohl eine Annahme falsch, veraltet oder ungetestet ist. Deshalb Quellen, Tests und tatsächliche Ausführung.

Der Anfänger erkennt Fehler schlechter

Wer das fachliche oder technische Ziel nicht versteht, kann falsche Ergebnisse schwerer korrigieren. Die Anthropic-Nutzungsanalyse berichtet bei als „novice“ eingestuften Sitzungen niedrigere verifizierte Erfolgsraten als ab mittlerem Expertisegrad; die Klassifikation ist aufgabenspezifisch und anbieterseitig. [S025]

Kontext kann verschmutzen

Lange Sitzungen mit vielen Richtungswechseln erhöhen das Risiko, dass frühere Bedingungen untergehen. [S006] [S028]

Abhängigkeiten und Komplexität wachsen schnell

Eine KI kann für kleine Probleme zusätzliche Frameworks, Pakete, Container und Dienste einführen. Das erzeugt langfristige Wartung.

Betrieb bleibt bestehen

Server, Zertifikate, Backups, Datenbanken und Sicherheitsupdates verschwinden nicht, nur weil Code schneller erzeugt wird.

Lieferketten- und Prompt-Injection-Risiken

Fremde Repositories, Pakete, Skills, Plugins und MCP-Server können schädlichen oder manipulativen Inhalt enthalten. [S081] [S082]

Kosten sind schwer vorherzusagen

Nutzung, Modell, Kontext und Iterationsschleifen bestimmen Kosten. Ein pauschaler ROI ist nicht belegbar. [S022]

Die Studienlage ist widersprüchlich – aus gutem Grund

Unterschiedliche Studien messen unterschiedliche Dinge:

METR 2025: Verlangsamung in engem Experten-Setting

FAKT: METR führte eine randomisierte Studie mit 16 erfahrenen Open-Source-Entwicklern und 246 realen Aufgaben in großen, vertrauten Repositories durch. Bei erlaubter Nutzung damaliger KI-Werkzeuge benötigten die Entwickler im Mittel 19 Prozent länger. Die Entwickler hatten zuvor eine Beschleunigung erwartet und schätzten auch nach dem Versuch die Wirkung positiver ein als gemessen. [S088]

WICHTIGE GRENZE: METR selbst warnt vor Verallgemeinerung. Untersucht wurden erfahrene Entwickler in eigenen großen Repositories, Aufgaben von ungefähr 20 Minuten bis vier Stunden und Werkzeuge des frühen Jahres 2025. Die Studie belegt nicht, dass KI die Mehrheit aller Entwickler oder Anfänger verlangsamt. [S088]

METR 2026: Messung wird durch Adoption schwieriger

FAKT: Im Februar 2026 erklärte METR, dass eine Folgestudie durch starke Selektion verzerrt sei. Entwickler mit hoher erwarteter KI-Wirkung wollten seltener Aufgaben ohne KI bearbeiten; einige wählten Aufgaben anders oder arbeiteten parallel mit mehreren Agenten. METR hielt eine stärkere Beschleunigung Anfang 2026 für wahrscheinlich, bezeichnete die Daten zur Größe aber als schwache Evidenz. [S089]

Die wichtige Schlussfolgerung lautet nicht „KI macht schneller“ oder „KI macht langsamer“, sondern:

Produktivitätswirkung verändert Aufgabenwahl und Arbeitsweise so stark, dass reine Zeitvergleiche schwieriger werden.

METR-Befragung 2026: hoher selbstberichteter Wert, aber unsicher

FAKT: METR befragte von Februar bis April 2026 insgesamt 349 technische Beschäftigte. Die Teilnehmer berichteten median eine 1,4- bis 2-fache Veränderung des Werts ihrer Arbeit durch KI und eine noch höhere subjektive Geschwindigkeitsveränderung. METR nennt ausdrücklich Gründe, die Größenordnung skeptisch zu betrachten, und verweist auf frühere Abweichungen zwischen Wahrnehmung und gemessener Wirkung. [S091]

Das ist nützliche Evidenz für wahrgenommenen Nutzen, aber kein kausaler Beweis für einen bestimmten ROI.

Anthropic 2026: Expertise und verifizierte Sitzungsergebnisse

FAKT: Anthropic analysierte datenschutzschonend rund 400.000 Claude-Code-Sitzungen von Oktober 2025 bis April 2026. Als „novice“ eingestufte Sitzungen erreichten in der strengsten Klassifikation 15 Prozent verifizierten Erfolg und 77 Prozent mindestens Teilerfolg. Ab „intermediate“ lagen die berichteten Werte bei 28 bis 33 Prozent verifiziertem und 91 bis 92 Prozent mindestens teilweisem Erfolg. [S025]

Einordnung:

• Anbieteranalyse des eigenen Produkts,
• Erfolg durch Klassifikatoren abgeleitet,
• keine zufällige Zuweisung,
• aufgabenspezifische Expertise, nicht Bildungsabschluss,
• wichtige frühe Nutzungsbeobachtung, aber kein universeller Leistungsnachweis.

GitHub-Copilot-Studie

FAKT: Eine häufig zitierte GitHub-/Microsoft-Studie untersuchte eine begrenzte Programmieraufgabe in einem kontrollierten Setting und berichtete deutlich schnellere Bearbeitung mit Copilot. Die Studie ist anbieternah und die Aufgabe nicht repräsentativ für vollständige Produktentwicklung, Serverbetrieb oder langfristige Wartung. [S090]

Sie belegt, dass KI bei bestimmten klaren Aufgaben erheblich helfen kann. Sie belegt keinen allgemeinen Faktor für jedes Softwareprojekt.

DORA 2025

FAKT: DORA untersuchte 2025 KI-unterstützte Softwareentwicklung im breiteren organisatorischen Kontext und veröffentlichte eine korrigierte Fassung sowie eine Errata-Seite. [S086] [S087]

EMPFEHLUNG: Ergebnisse zu AI-Produktivität nie isoliert von Entwicklungsqualität, Plattform, Review, Teamprozessen und organisatorischer Fähigkeit interpretieren. Schneller mehr Code zu erzeugen ist kein Wert, wenn Qualität, Freigabe und Betrieb nicht mithalten.

Ein belastbares eigenes Messmodell

Für ein Unternehmen nicht „Wie viel schneller ist Claude?“ fragen, sondern je Projekt messen:

Baseline

• bisherige Durchlaufzeit,
• externe Kosten,
• Fehler-/Nacharbeitszeit,
• Anzahl Übergaben,
• Betriebskosten.

Mit Claude Code

• menschliche Arbeitszeit,
• Modell-/Abo-Kosten,
• Prüf- und Korrekturzeit,
• Infrastruktur,
• Fehler und Rückläufe,
• zusätzlicher erzeugter Nutzen.

Ergebnis

```text Nutzen

• KI-Kosten
• Prüfkosten
• Betriebskosten
• Fehlerfolgekosten

= tatsächlicher Wert ```

Wann Claude Code wahrscheinlich besonders nützlich ist

• klar definierte interne Werkzeuge,
• wiederkehrende Websites,
• Datenaufbereitung und Skripte,
• vorhandene Tests,
• dokumentierte APIs,
• fachlich starker Auftraggeber,
• schnelle Prototypen mit klarer Kennzeichnung,
• Migration kleiner manueller Abläufe.

Wann Vorsicht besonders wichtig ist

• Zahlung, Buchhaltung und rechtlich relevante Entscheidungen,
• Gesundheits- oder Sicherheitsfunktionen,
• komplexe Rechte und Mandantentrennung,
• unersetzliche Daten,
• unbekannte Legacy-Systeme,
• ungeprüfte Produktionszugänge,
• Systeme ohne Tests und Backup.

Neutrales Fazit

Claude Code kann die Reichweite fachlich starker Menschen deutlich erhöhen. Die Forschung stützt jedoch keine pauschale Aussage wie „zehnmal schneller“ oder „ersetzt Entwickler“. Wirkung hängt von Aufgabe, Erfahrung, Codebasis, Verifikation, Organisation und Qualitätsanspruch ab.

Der wichtigste Produktivitätshebel dieses Dossiers ist nicht maximale Autonomie. Es ist kontrollierte Delegation mit überprüfbaren Ergebnissen.

\newpage

Typische Fehler und Fehlerdiagnose

Der Diagnosegrundsatz

Nicht sofort zehn Reparaturen ausführen. Zuerst:

``text Fehler reproduzieren → Ebene bestimmen → kleinsten Prüfschritt wählen → Ursache bestätigen → minimal korrigieren → erneut prüfen ``

Claude startet nicht

Prüfen:

``bash claude --version ``

Dann:

• richtige Shell?
• Terminal neu geöffnet?
• Installationspfad im PATH?
• Internetverbindung?
• Unternehmensproxy oder Sicherheitssoftware?
• aktueller offizieller Installationsweg?

Keine zufälligen Neuinstallationsskripte aus Foren verwenden.

Anmeldung funktioniert nicht

• unterstütztes Konto/Abonnement?
• Browseranmeldung abgeschlossen?
• Uhrzeit und Netzwerk korrekt?
• Unternehmensrichtlinie oder Proxy?
• aktuelle Anthropic-Status-/Supportinformation?

Claude sieht falsche Dateien

``bash pwd git rev-parse --show-toplevel git status ``

Möglicherweise wurde Claude eine Ebene zu hoch gestartet.

Maßnahme: Sitzung beenden, in den Projektordner wechseln und neu starten. Keine pauschale Dateifreigabe des gesamten Benutzerverzeichnisses.

CLAUDE.md wird scheinbar ignoriert

Prüfen:

• richtige Schreibweise und Position,
• Datei geladen?
• widersprüchliche Regeln anderer Ebenen?
• zu lang oder unklar?
• Regel gehört eigentlich in Permission/Hook?
• Sitzung nach Änderung neu beziehungsweise /memory geprüft?

FAKT: Anthropic empfiehlt konkrete, kurze Anweisungen und Zielgröße unter 200 Zeilen. [S007]

Settings werden nicht geladen

• JSON gültig?
• .claude/settings.json am richtigen Ort?
• /status zeigt Quelle?
• Feldname aktuell?
• JSON-Schema-Warnung wegen neuer CLI-Version?

FAKT: Claude Code zeigt geladene Settingsquellen über /status; ungültiges JSON kann dazu führen, dass eine Datei nicht als geladen erscheint. [S008]

Permission-Regel greift unerwartet

Deny hat Vorrang vor Ask und Allow. Eine breite Regel kann engere Freigaben blockieren. [S009]

Beispiel:

``json "deny": ["Bash(git *)"] ``

blockiert auch einen engeren Allow-Eintrag für git status.

Hook läuft nicht

Prüfen:

• /hooks,
• Ereignis und Matcher exakt,
• Skript ausführbar,
• absoluter beziehungsweise $CLAUDE_PROJECT_DIR-Pfad,
• Python/JQ installiert,
• JSON-Eingabe manuell testen,
• Exit-Code. [S013]

Beispieltest:

``bash echo '{"tool_name":"Bash","tool_input":{"command":"ls"}}' | ./hook.py echo $? ``

Lokaler Port ist belegt

Symptom:

``text Address already in use ``

Vorgehen:

1. Projektstartbefehl und Port prüfen.
2. bestehenden Prozess identifizieren.
3. Zugehörigkeit bestätigen.
4. sauber stoppen oder Port ändern.

Nicht alle Prozesse pauschal töten.

Seite lädt, aber CSS/Bilder fehlen

• relative Pfade falsch,
• Groß-/Kleinschreibung unterscheidet sich auf Linux,
• base-Pfad oder Buildkonfiguration,
• Dateien nicht deployed,
• Cache,
• falscher DocumentRoot.

Funktioniert unter Windows, nicht auf Linux

Häufig:

• Groß-/Kleinschreibung,
• Pfadtrenner,
• Zeilenenden,
• Shellbefehle,
• Dateirechte,
• native Abhängigkeiten,
• Umgebungsvariablen.

EMPFEHLUNG: Linux-Produktionsnähe über WSL2, Container oder Staging früh testen.

Git zeigt zu viele Dateien

• node_modules, Build oder Logs nicht ignoriert,
• .gitignore zu spät ergänzt,
• generierte Dateien bereits versioniert.

Vor Bereinigung prüfen, ob Dateien absichtlich versioniert sind.

Merge-Konflikt

Claude soll:

1. beide Varianten erklären,
2. fachliche Absicht bestimmen,
3. Konfliktdatei gezielt ändern,
4. Tests ausführen,
5. keinen fremden Stand pauschal überschreiben.

Secret committed

Sofort:

• Secret rotieren,
• Zugriff prüfen,
• Repository und Historie bereinigen,
• alle Deployments und Klone berücksichtigen,
• Push Protection/Scanning aktivieren, soweit verfügbar. [S038] [S039] [S041]

Docker startet nicht

Prüfen:

``bash docker compose config docker compose ps docker compose logs ``

Dann:

• Docker Engine läuft?
• Ports belegt?
• Image verfügbar?
• Umgebungsvariable fehlt?
• Volume-Rechte?
• Healthcheck?

Kein down -v als Standardreparatur.

Datenbankverbindung fehlschlägt

• Hostname im Container anders als lokal?
• Port intern/extern verwechselt?
• Secret gesetzt?
• Datenbank läuft?
• Benutzer und Datenbank vorhanden?
• TLS erforderlich?
• Firewall?
• Migration ausstehend?

Passwort nicht in Diagnoseausgabe kopieren.

Apache liefert 403

Mögliche Ursachen:

• Dateirechte,
• Verzeichnisrechte,
• Apache-Directory-Regeln,
• falscher Benutzer,
• falscher DocumentRoot,
• fehlende Indexdatei.

Apache liefert 404

• Virtual Host nicht aktiv,
• DNS/Hosts-Eintrag falsch,
• Pfad nicht unter DocumentRoot,
• Rewrite-Regel,
• Datei beim Deployment vergessen.

DNS zeigt noch auf altes Ziel

• Record falsch,
• www und Root-Domain getrennt,
• TTL/Cache,
• lokaler DNS-Cache,
• IPv6-AAAA noch alt,
• Nameserver nicht der erwartete Anbieter.

Nicht nur Browser prüfen; DNS gezielt auflösen.

Zertifikat kann nicht ausgestellt werden

• Domain zeigt nicht auf Server,
• Port 80 für HTTP-01 nicht erreichbar,
• Firewall,
• falscher Virtual Host,
• DNS-01-Eintrag oder API-Berechtigung,
• Rate Limits,
• falsche Systemzeit. [S049] [S050]

E-Mail kommt nicht an

• Mailserverdaten,
• Absenderregeln,
• SMTP-Port/TLS,
• Spamordner,
• SPF/DKIM/DMARC,
• Providerlimits,
• Anwendung meldet Erfolg trotz Fehler.

Serverlog prüfen, aber Zugangsdaten redigieren.

NAS-Seite nicht erreichbar

• Web Station/Portal aktiv?
• richtige IP/Port?
• LAN-Firewall?
• Webroot?
• Dateirechte?
• DSM-/Paketversion?
• Containerport veröffentlicht?
• Modell unterstützt Funktion? [S051–S053]

Backupjob grün, Restore scheitert

Mögliche Ursachen:

• Schlüssel fehlt,
• Backup unvollständig,
• Datenbank und Dateien inkonsistent,
• Zielversion inkompatibel,
• Berechtigungen,
• nie praktisch getestet.

Die Lösung ist nicht ein neuer grüner Backupjob, sondern ein dokumentierter Restore-Test.

Claude dreht sich im Kreis

Anzeichen:

• gleiche Korrektur mehrfach,
• neue Fehler nach jeder Änderung,
• immer mehr Dateien betroffen,
• Plan wechselt ohne neue Erkenntnis.

Vorgehen:

1. stoppen,
2. Git-Diff sichern,
3. auf letzten funktionierenden Commit zurückblicken,
4. Fehler und Hypothesen zusammenfassen,
5. neuen, engen Kontext starten,
6. erst reproduzieren, dann korrigieren.

Diagnoseprompt

```text Stoppe weitere Änderungen.

Fasse zusammen:

• aktuelles Ziel,
• beobachteter Fehler,
• letzte funktionierende Version,
• bisherige Hypothesen,
• ausgeführte Befehle und Ergebnisse,
• aktuell geänderte Dateien.

Bestimme die wahrscheinlich betroffene Ebene: Anwendung, Abhängigkeit, Runtime, Datenbank, Netzwerk, Webserver, DNS, Zertifikat, Rechte oder Konfiguration. Schlage nur den kleinsten nächsten Prüfschritt vor. ```

\newpage

Checklisten

Dieses Kapitel ist als Arbeitsinstrument gedacht. Die Checklisten ersetzen keine projektspezifische Prüfung. Sie verhindern vor allem, dass Claude Code technisch schon arbeitet, obwohl Ziel, Rücksprungpunkt oder Betriebsgrenze noch offen sind.

Der 15-Minuten-Projektstart

EMPFEHLUNG: Vor dem ersten produktiven Prompt müssen mindestens diese Punkte geklärt sein:

• [ ] Ein eigener Projektordner wurde angelegt.
• [ ] Das Terminal befindet sich nachweislich in diesem Ordner.
• [ ] git status funktioniert oder Git wird jetzt initialisiert.
• [ ] Der Zweck des Projekts ist in zwei bis fünf Sätzen beschrieben.
• [ ] Es ist geklärt, ob es sich um Demonstration, internes Werkzeug oder Produktivsystem handelt.
• [ ] Es ist geklärt, welche Daten verarbeitet werden.
• [ ] Es ist geklärt, ob Login, Rollen oder personenbezogene Daten vorkommen.
• [ ] Secrets werden nicht in den Prompt, CLAUDE.md oder das Repository kopiert.
• [ ] Claude soll zuerst untersuchen und planen, nicht sofort bauen.
• [ ] Ein erster Commit wird erstellt, sobald das Grundgerüst nachweislich funktioniert.

Minimaler Start:

``bash mkdir mein-projekt cd mein-projekt git init claude ``

Die tatsächlichen Befehle hängen vom Betriebssystem und vorhandenen Werkzeugen ab. Claude Code wird im gewählten Arbeitsverzeichnis gestartet; Git-Repositories werden mit git init angelegt. [S002] [S031]

Projektdefinition vor der Implementierung

• [ ] Wer benutzt das System?
• [ ] Welches konkrete Problem wird gelöst?
• [ ] Welche drei Funktionen sind zwingend?
• [ ] Welche Funktionen sind ausdrücklich nicht Bestandteil der ersten Version?
• [ ] Welche Daten werden gespeichert?
• [ ] Welche Daten dürfen nicht gespeichert werden?
• [ ] Welche Rollen existieren?
• [ ] Welche externen Dienste oder APIs sind notwendig?
• [ ] Wie sieht ein erfolgreicher Test aus?
• [ ] Wo läuft die erste Version: lokal, NAS, Staging oder Produktion?
• [ ] Wie wird gesichert?
• [ ] Wer darf veröffentlichen und wiederherstellen?

Abbruchkriterium: Sind Benutzer, Daten oder Betriebsort unklar, wird keine produktionsnahe Architektur festgelegt. Diese Punkte werden als UNKLAR in SPEC.md dokumentiert.

Vor jeder neuen Claude-Code-Aufgabe

• [ ] git status wurde geprüft.
• [ ] Unabhängige alte Änderungen sind committed, gesichert oder bewusst verworfen.
• [ ] Die Aufgabe betrifft genau ein nachvollziehbares Ziel.
• [ ] Akzeptanzkriterien stehen im Prompt.
• [ ] Relevante Dateien oder Dokumente sind benannt.
• [ ] Verbotene Bereiche sind benannt oder technisch gesperrt.
• [ ] Claude soll zunächst den Bestand lesen.
• [ ] Claude soll seinen Plan vor Änderungen zeigen, falls die Aufgabe groß oder riskant ist.
• [ ] Es ist definiert, wie das Ergebnis verifiziert wird.

EMPFEHLUNG: Eine Aufgabe ist zu groß, wenn sie mehrere unabhängige Ziele, eine neue Architektur und ein Deployment gleichzeitig verlangt. Dann zuerst in Teilaufgaben zerlegen.

Vor der Installation einer Abhängigkeit

• [ ] Wozu wird die Abhängigkeit benötigt?
• [ ] Gibt es bereits eine vorhandene Lösung im Projekt?
• [ ] Ist die Quelle das offizielle Paketregister oder eine überprüfte Herstellerquelle?
• [ ] Ist die konkrete Version dokumentiert oder wird ein Lockfile erzeugt?
• [ ] Welche Lizenz gilt?
• [ ] Welche transitive Abhängigkeit wird mitinstalliert?
• [ ] Läuft die Abhängigkeit nur bei der Entwicklung oder auch in Produktion?
• [ ] Erhält sie Dateisystem-, Netzwerk- oder Build-Zugriff?
• [ ] Wurde vor der Änderung ein sauberer Git-Zustand hergestellt?
• [ ] Werden Test und Build anschließend ausgeführt?

FAKT: Paketinstallation kann ausführbaren Code und weitere transitive Pakete in den Build- oder Laufzeitprozess aufnehmen. NIST empfiehlt für generative Entwicklungsverfahren weiterhin etablierte sichere Softwareentwicklungspraktiken, einschließlich Prüfung externer Komponenten. [S085]

Vor einem Commit

• [ ] Die Anwendung startet.
• [ ] Die relevanten Tests laufen erfolgreich.
• [ ] Fehlerausgaben wurden gelesen, nicht nur der Exit-Code.
• [ ] git diff wurde geprüft.
• [ ] Keine .env, Schlüssel, Passwörter oder Dumps sind enthalten.
• [ ] Keine zufälligen Builddateien oder großen Binärdateien sind enthalten.
• [ ] Dokumentation wurde aktualisiert, falls Bedienung oder Architektur geändert wurden.
• [ ] Der Commit enthält ein zusammengehöriges Thema.
• [ ] Die Commit-Nachricht beschreibt die Wirkung, nicht nur „Update“.
• [ ] Offene Risiken sind dokumentiert.

GitHub stellt Secret Scanning und Push Protection bereit, aber diese Mechanismen sind kein Grund, sensible Daten zunächst zu committen. Ein einmal veröffentlichter Schlüssel muss grundsätzlich als kompromittiert behandelt und ersetzt werden. [S038] [S039] [S041]

Vor einem Push

• [ ] Das Ziel-Remote wurde mit git remote -v geprüft.
• [ ] Der Branch ist korrekt.
• [ ] Das Repository ist privat oder öffentlich wie beabsichtigt.
• [ ] Der Diff enthält keine fremden oder vertraulichen Daten.
• [ ] Große Dateien und generierte Dateien sind ausgeschlossen.
• [ ] Branchschutz oder Reviewverfahren sind bei Teamprojekten eingerichtet.
• [ ] Der Push löst nicht unerwartet ein produktives Deployment aus.

EMPFEHLUNG: git push bleibt im Anfängerprofil bestätigungspflichtig. Ein Push kann nicht nur Code übertragen, sondern durch CI/CD weitere Aktionen auslösen.

Vor Staging

• [ ] Eine definierte Version oder ein Commit wird veröffentlicht.
• [ ] Staging besitzt eigene Konfiguration und eigene Secrets.
• [ ] Testdaten sind klar als Testdaten erkennbar.
• [ ] Produktive Kundendaten werden nicht unnötig kopiert.
• [ ] Datenbankmigrationen wurden auf einer geeigneten Kopie geprüft.
• [ ] Staging ist nicht ungewollt öffentlich indexierbar.
• [ ] HTTPS funktioniert.
• [ ] Logs enthalten keine Secrets.
• [ ] Rollback ist beschrieben.
• [ ] Die Abnahmekriterien aus SPEC.md werden ausgeführt.

Vor Produktion

• [ ] Verantwortliche Person hat die Veröffentlichung ausgelöst.
• [ ] Commit, Tag oder Build-Artefakt ist eindeutig identifizierbar.
• [ ] Tests und Build sind erfolgreich.
• [ ] Sicherheitsprüfung ist erfolgt.
• [ ] Backup vor Migration oder größerer Änderung ist erfolgreich.
• [ ] Restore dieses Sicherungsverfahrens ist grundsätzlich dokumentiert und getestet.
• [ ] Datenbankmigration besitzt einen Vorwärts- und einen Fehlerplan.
• [ ] Domain und DNS-Ziel sind geprüft.
• [ ] HTTPS und automatische Erneuerung sind geprüft.
• [ ] Firewall öffnet nur erforderliche Dienste.
• [ ] SSH arbeitet mit geeigneten Schlüsseln und eingeschränkten Benutzern.
• [ ] Standardpasswörter sind entfernt.
• [ ] Monitoring beziehungsweise mindestens Erreichbarkeits- und Logprüfung ist eingerichtet.
• [ ] Rollback ist möglich.
• [ ] Funktionstest nach Deployment ist festgelegt.

Ein produktives Deployment sollte als manueller Skill mit disable-model-invocation: true ausgeführt werden. Anthropic nennt Deployment ausdrücklich als Beispiel für eine Aktion, deren Auslösung beim Benutzer bleiben sollte. [S012]

Nach Produktion

• [ ] Startseite und kritische Funktionen sind erreichbar.
• [ ] Login, Formular oder Transaktion funktionieren.
• [ ] Fehlerlogs wurden kontrolliert.
• [ ] Version wurde dokumentiert.
• [ ] Datenbankmigration ist vollständig.
• [ ] Hintergrundjobs laufen.
• [ ] Zertifikat ist gültig.
• [ ] Keine Testdaten oder Debuganzeigen sind sichtbar.
• [ ] Backupjob läuft weiter.
• [ ] Bei Fehlern wird zurückgerollt, statt unkontrolliert weiterzuändern.

NAS-Checkliste

Vor Nutzung einer Synology als Test- oder interner Webserver:

• [ ] DSM-Version und NAS-Modell sind dokumentiert.
• [ ] Benötigte Pakete werden vom Modell unterstützt.
• [ ] Web Station oder Container Manager ist korrekt eingerichtet.
• [ ] Projekt und Daten liegen nicht in Systemverzeichnissen, die DSM selbst verwaltet.
• [ ] Technische Benutzer besitzen nur notwendige Rechte.
• [ ] SSH ist nur aktiviert, wenn es wirklich benötigt wird.
• [ ] Zugriff von außen ist nicht versehentlich freigegeben.
• [ ] Router-Portweiterleitungen wurden geprüft.
• [ ] Snapshots sind nur eine Ebene, kein vollständiges Offsite-Backup.
• [ ] Hyper Backup beziehungsweise ein alternatives Backupziel ist eingerichtet.
• [ ] Wiederherstellung wurde praktisch getestet.
• [ ] Container-Volumes und Datenbanken sind in der Sicherung enthalten.

Synology-Funktionen sind modell-, Dateisystem- und DSM-abhängig. Snapshot Replication setzt je nach Funktion unterstützte Modelle und Btrfs voraus; Hyper Backup und externe Ziele erfüllen andere Aufgaben. [S053] [S055–S057]

VPS-Checkliste

• [ ] Unterstützte Linux-Version gewählt.
• [ ] Nicht direkt dauerhaft als root arbeiten.
• [ ] Separater Benutzer mit erforderlichen Rechten angelegt.
• [ ] SSH-Schlüssel getestet.
• [ ] Passwortanmeldung nur nach bewusster Risikoentscheidung.
• [ ] Firewall aktiv; nur benötigte Ports offen.
• [ ] System- und Sicherheitsupdates eingerichtet.
• [ ] Webserver oder Reverse Proxy dokumentiert.
• [ ] Anwendung läuft als eigener Dienst oder Container.
• [ ] Daten liegen persistent und werden gesichert.
• [ ] Logs werden rotiert und kontrolliert.
• [ ] Domain und DNS sind dokumentiert.
• [ ] HTTPS-Erneuerung wurde getestet.
• [ ] Backup liegt außerhalb desselben VPS.
• [ ] Restore auf einer frischen Umgebung wurde zumindest einmal geprobt.

Canonical dokumentiert OpenSSH, ufw, automatische Updates und AppArmor als getrennte Bausteine des Ubuntu-Serverbetriebs. Keiner dieser Bausteine ersetzt die übrigen. [S066] [S068–S070]

Backup-Checkliste

• [ ] Welche Daten müssen gesichert werden?
• [ ] Welche Projektdateien sind bereits in Git?
• [ ] Welche Datenbank wird verwendet?
• [ ] Welche Uploads oder Dokumente existieren?
• [ ] Welche Konfigurationen werden außerhalb von Git benötigt?
• [ ] Wie werden Secrets nach einer Wiederherstellung bereitgestellt?
• [ ] Welche Container-Volumes existieren?
• [ ] Wie oft ändert sich der Datenbestand?
• [ ] Wie viel Datenverlust ist maximal tolerierbar?
• [ ] Wie lange darf eine Wiederherstellung dauern?
• [ ] Gibt es eine externe beziehungsweise Offsite-Kopie?
• [ ] Sind Backups verschlüsselt?
• [ ] Wo befindet sich der Schlüssel?
• [ ] Werden Fehler des Backupjobs gemeldet?
• [ ] Ist ein Restore-Test protokolliert?

FAKT: Datenbanksysteme besitzen eigene, systemspezifische Backupverfahren. PostgreSQL unterscheidet unter anderem SQL-Dumps, Dateisystem-Backups und kontinuierliche Archivierung; MySQL und SQLite besitzen eigene Verfahren. Eine bloße Kopie laufender Datenbankdateien ist nicht universell korrekt. [S072–S074]

Restore-Checkliste

• [ ] Ziel der Wiederherstellung ist definiert.
• [ ] Benötigte Softwareversionen sind bekannt.
• [ ] Backup und Prüfsumme sind verfügbar.
• [ ] Entschlüsselungsschlüssel ist verfügbar.
• [ ] Datenbank wird in eine kontrollierte Zielumgebung zurückgespielt.
• [ ] Dateien und Datenbank stammen aus einem konsistenten Zeitpunkt oder das Verfahren berücksichtigt die Differenz.
• [ ] Berechtigungen werden wiederhergestellt.
• [ ] Secrets werden neu bereitgestellt, nicht aus öffentlichem Git gezogen.
• [ ] Anwendung startet.
• [ ] Kritische Datensätze und Uploads werden stichprobenartig geprüft.
• [ ] Der Restore-Zeitpunkt und das Ergebnis werden dokumentiert.
• [ ] Bei Sicherheitsvorfall werden kompromittierte Schlüssel ersetzt.

Vor Aktivierung eines Hooks

• [ ] Hook-Code wurde selbst gelesen.
• [ ] Triggerereignis und Matcher sind korrekt.
• [ ] Verhalten bei Exit-Code 0, 2 und anderen Fehlern ist verstanden.
• [ ] Eingaben werden sicher geparst.
• [ ] Keine Secrets werden protokolliert.
• [ ] Hook führt keine unbeabsichtigten Seiteneffekte aus.
• [ ] Hook wurde in einem Testprojekt geprüft.
• [ ] Fehler im Hook blockieren nicht dauerhaft die gesamte Arbeit.
• [ ] Die Regel wird zusätzlich durch Betriebssystemrechte oder Permissions gestützt, falls sie sicherheitskritisch ist.

Hooks sind ausführbarer Code. PreToolUse kann Aktionen blockieren; die konkrete Sicherheit hängt dennoch von Hook-Implementierung, Matcher und Umgebung ab. [S013]

Vor Installation eines Skills, Plugins oder MCP-Servers

• [ ] Quelle und Herausgeber sind bekannt.
• [ ] Dateien und Konfiguration wurden geprüft.
• [ ] allowed-tools sind eng genug.
• [ ] Automatische Modellauslösung ist bei Seiteneffekten deaktiviert.
• [ ] MCP-Server erhält nur notwendige Berechtigungen.
• [ ] Netzwerkziele sind bekannt.
• [ ] Tokens und Secrets werden sicher bereitgestellt.
• [ ] Rückgabedaten werden als potenziell untrusted behandelt.
• [ ] Das Paket ist für das Projekt tatsächlich erforderlich.
• [ ] Deinstallation ist dokumentiert.

Skills können sich temporär Werkzeuge vorab genehmigen; Projekt-Skills werden nach Workspace-Vertrauen wirksam. Anthropic fordert deshalb ausdrücklich, Skills eines fremden Repositories vor dem Vertrauen zu prüfen. [S012]

Incident-Checkliste

Bei vermutetem Sicherheits- oder Datenvorfall:

1. Änderungen und automatische Deployments stoppen.
2. Betroffene Umgebung isolieren, ohne Beweise unnötig zu vernichten.
3. Zeitpunkt, Symptome und betroffene Systeme protokollieren.
4. Zugangsdaten und Tokens als potenziell kompromittiert behandeln.
5. Schlüssel über den jeweiligen Anbieter widerrufen und ersetzen.
6. Logs sichern und sensible Inhalte geschützt behandeln.
7. Letzten nachweislich guten Stand bestimmen.
8. Backup vor Restore auf Integrität prüfen.
9. Ursache beheben, nicht nur Symptome überdecken.
10. Wiederanlauf kontrolliert testen.
11. Dokumentation, Permissions, Hooks und Verfahren anpassen.

Die rechtliche Bewertung eines Vorfalls, insbesondere bei personenbezogenen Daten, ist nicht Gegenstand dieses technischen Dossiers und muss separat erfolgen.

Handover-Checkliste

Vor Ende einer längeren Sitzung oder Übergabe:

• [ ] Ziel und aktueller Stand sind dokumentiert.
• [ ] Letzter funktionierender Commit ist benannt.
• [ ] Uncommitted Changes sind erklärt.
• [ ] Ausgeführte Tests und Ergebnisse sind dokumentiert.
• [ ] Offene Fehler sind reproduzierbar beschrieben.
• [ ] Nächster kleinster Schritt ist festgelegt.
• [ ] Neue Architekturentscheidungen stehen in docs/architecture.md oder einem ADR.
• [ ] Deployment- und Backupdokumentation ist aktuell.
• [ ] Keine Secrets befinden sich in der Übergabe.

\newpage

Prompt- und Skill-Bibliothek

Grundsatz: Prompt, Projektwissen oder technische Regel?

Eine der wichtigsten Architekturentscheidungen ist die richtige Ablage einer Information.

Anthropic grenzt CLAUDE.md, Skills, Hooks, Permissions und Subagents funktional voneinander ab. Skills sind besonders für wiederkehrende Verfahren geeignet, während Hooks deterministisch ausgeführt werden. [S007] [S012–S016]

Promptformel für kontrollierte Aufgaben

VORLAGE: Ein belastbarer Arbeitsauftrag enthält sieben Teile:

```text

1. Ziel
2. Ausgangslage
3. relevante Quellen oder Dateien
4. Grenzen
5. gewünschtes Vorgehen
6. Akzeptanzkriterien
7. Verifikation und Bericht

```

Beispiel:

```text Ziel: Ergänze auf der bestehenden Website ein Kontaktformular.

Ausgangslage: Untersuche zuerst SPEC.md, CLAUDE.md und den vorhandenen Formularcode.

Grenzen: Keine neue Formularbibliothek installieren. Keine Änderungen am Deployment. Keine echten Zugangsdaten verwenden.

Vorgehen: Zeige zuerst einen kurzen Plan. Implementiere danach nur die notwendige Änderung.

Akzeptanzkriterien:

• Name, E-Mail und Nachricht
• serverseitige Validierung
• verständliche Fehlermeldungen
• Erfolgsmeldung
• mobile Bedienbarkeit

Verifikation: Führe vorhandene Tests aus, ergänze passende Tests und starte die Anwendung. Berichte zuletzt: geänderte Dateien, Testergebnisse, offene Risiken. ```

EMPFEHLUNG: Nicht mehr Text schreiben als notwendig. Präzision entsteht durch konkrete Akzeptanzkriterien und überprüfbare Ergebnisse, nicht durch einen künstlich langen Rollenprompt. Anthropic empfiehlt explizite Ziel- und Verifikationsbedingungen sowie einen Arbeitszyklus aus Erkundung, Planung, Implementierung und Prüfung. [S005] [S006] [S026] [S027]

Prompt 1 – vollständiges Projektinterview

VORLAGE:

```text Ich möchte folgendes Projekt entwickeln:

[PROJEKTIDEE]

Implementiere noch nichts. Führe zuerst ein strukturiertes Projektinterview durch.

Kläre mindestens:

• Ziel und Zielgruppe
• Problem und gewünschtes Ergebnis
• Muss-, Soll- und Nicht-Funktionen
• Benutzerrollen und Rechte
• Daten und Datenquellen
• personenbezogene oder vertrauliche Daten
• Login und Authentifizierung
• externe APIs und Dienste
• gewünschte Geräte und Browser
• lokale Entwicklungsumgebung
• Hostingziel: Rechner, NAS, Staging oder VPS
• Datenbank und Dateispeicher
• Backup und Restore
• Tests und Abnahmekriterien
• Betrieb, Updates und Verantwortlichkeiten

Frage in sinnvollen Blöcken. Rate nicht. Markiere unbeantwortete technische Entscheidungen als UNKLAR.

Erstelle anschließend:

1. SPEC.md,
2. Liste offener Entscheidungen,
3. Architekturvarianten mit Vor- und Nachteilen,
4. Risikoliste,
5. Vorschlag für den kleinsten umsetzbaren ersten Meilenstein.

Noch keinen produktiven Code erzeugen. ```

Prompt 2 – bestehendes Projekt verstehen

```text Untersuche dieses Projekt, ohne Dateien zu verändern.

Lies zuerst:

• CLAUDE.md
• SPEC.md
• README.md
• Paket- und Builddateien
• Testkonfiguration
• Deployment- und Backupdokumentation

Ermittle:

• Zweck und Hauptfunktionen
• verwendete Technik
• Start-, Test- und Buildbefehle
• Architektur und Datenfluss
• externe Dienste
• Secrets-Schnittstellen, ohne Secretwerte auszugeben
• aktuellen Git-Status
• erkennbare Risiken und Dokumentationslücken

Trenne in deinem Bericht: FAKT aus Dateien, ABLEITUNG, UNKLAR.

Führe keine Installation, Migration, Änderung oder Netzwerkaktion aus. ```

Prompt 3 – Architekturentscheidung

```text Bewerte für [ZIEL] mindestens zwei realistische Architekturvarianten.

Berücksichtige:

• vorhandene Technik
• Zielgruppe und Last
• Daten und Rechte
• lokale Entwicklung
• Hosting
• Backup und Restore
• Wartungsaufwand
• Sicherheitsfläche
• Kostenfaktoren, ohne unbelegte Preise zu erfinden
• spätere Erweiterbarkeit

Erstelle eine Entscheidungsmatrix. Nenne Annahmen ausdrücklich. Markiere nicht belegbare Punkte als UNKLAR. Empfiehl eine Variante und begründe, welche Nachteile bewusst akzeptiert werden. Noch nichts implementieren. ```

Prompt 4 – Feature implementieren

```text Implementiere folgendes Feature:

[FEATURE]

Arbeite in dieser Reihenfolge:

1. Relevante Anforderungen und Dateien lesen.
2. Bestehenden Datenfluss erklären.
3. Kleinen Plan erstellen.
4. Nur notwendige Dateien verändern.
5. Tests ergänzen oder aktualisieren.
6. Test, Linter und Build ausführen, soweit im Projekt vorhanden.
7. Anwendung gegen die Akzeptanzkriterien prüfen.

Grenzen: [GRENZEN]

Akzeptanzkriterien: [KRITERIEN]

Keine neuen Abhängigkeiten ohne Begründung und Zustimmung. Kein Commit, Push oder Deployment ohne ausdrücklichen Auftrag. Berichte zuletzt:

• geänderte Dateien,
• tatsächliche Testergebnisse,
• nicht geprüfte Punkte,
• offene Risiken.

```

Prompt 5 – Fehler systematisch beheben

```text Behebe noch nichts. Reproduziere zuerst folgenden Fehler:

[FEHLERBESCHREIBUNG]

Arbeite hypothesengetrieben:

1. erwartetes Verhalten,
2. tatsächliches Verhalten,
3. reproduzierbare Schritte,
4. wahrscheinlich betroffene Ebene,
5. kleinster diagnostischer Test.

Ändere erst Code, wenn die Ursache ausreichend eingegrenzt ist. Erstelle anschließend die kleinste Korrektur. Füge einen Regressionstest hinzu, sofern sinnvoll. Führe relevante Tests aus.

Berichte getrennt:

• Ursache,
• Beleg,
• Änderung,
• Testergebnis,
• verbleibende Unsicherheit.

```

Prompt 6 – Sicherheitsprüfung

```text Führe eine defensive Sicherheitsprüfung dieses Projekts durch. Keine Angriffe gegen fremde Systeme und keine produktiven Daten verändern.

Prüfe mindestens:

• Secrets im Repository und in Logs
• Authentifizierung und Sitzungen
• Autorisierung und Objektzugriffe
• Eingabevalidierung
• Datei-Uploads
• Datenbankzugriffe
• Abhängigkeiten und Buildskripte
• externe HTTP-Aufrufe
• Fehlerausgaben
• CORS und Security Header, soweit relevant
• Deploymentrechte
• Backup- und Restore-Zugriffe
• Claude-Code-Permissions, Skills, Hooks und MCP-Konfiguration

Ordne Befunde nach: KRITISCH, HOCH, MITTEL, NIEDRIG, INFORMATION.

Für jeden Befund:

• betroffene Datei/Komponente,
• konkretes Risiko,
• nachvollziehbarer Beleg,
• empfohlene Korrektur,
• Test der Korrektur.

Erfinde keine Schwachstelle, wenn sie nicht belegt ist. ```

OWASP Top 10, Secrets-Management-Leitfäden und NIST SSDF können als Prüfkatalog dienen. Eine solche Prüfung ist dennoch kein formales Penetrationstest-Zertifikat. [S080] [S083–S085]

Prompt 7 – Release-Review

```text Bereite ein Release-Review vor. Noch nicht deployen.

Prüfe:

• Git-Status und Diff seit [REFERENZ]
• erfolgreiche Tests und Build
• offene TODO/FIXME mit Release-Relevanz
• neue oder geänderte Abhängigkeiten
• Datenbankmigrationen
• Konfigurationsänderungen
• Secrets-Anforderungen
• Deploymentanleitung
• Backup vor Release
• Rollback
• Funktionsprüfung nach Release
• Dokumentation und Changelog

Erstelle eine Go/No-Go-Tabelle. Ein unbekannter kritischer Punkt ist NO-GO, nicht automatisch GO. ```

Prompt 8 – Deploymentplan, noch ohne Ausführung

```text Erstelle für dieses Projekt einen reproduzierbaren Deploymentplan nach [ZIELUMGEBUNG]. Führe ihn noch nicht aus.

Der Plan muss enthalten:

• Voraussetzungen
• Zielpfade und Dienste
• Build-Artefakt oder Commit
• Konfiguration und Secret-Bereitstellung
• Datenbankmigration
• Backup
• Reihenfolge der Schritte
• Funktionstest
• Logs
• Rollback
• Verantwortliche Freigabe

Trenne:

• ungefährliche Vorprüfung,
• verändernde Aktion,
• irreversible oder riskante Aktion.

Markiere alle unbekannten Zugangsdaten, Hostnamen und Pfade als Platzhalter. Keine Werte erfinden. ```

Prompt 9 – Backup- und Restore-Test

```text Analysiere das aktuelle Backupkonzept. Noch keine Daten löschen oder überschreiben.

Ermittle:

• welche Datenquellen existieren,
• welche davon gesichert werden,
• Ziel und Aufbewahrung,
• Verschlüsselung und Schlüsselverwaltung,
• RPO und RTO, soweit definiert,
• Abhängigkeit von demselben Gerät oder Anbieter,
• letzter erfolgreicher Restore-Test.

Erstelle danach einen sicheren Restore-Test in einer getrennten Zielumgebung. Der Test muss Prüfkriterien, Protokoll und Abbruchbedingungen enthalten. Markiere fehlende Informationen als UNKLAR. ```

Prompt 10 – Sitzung sauber übergeben

```text Beende die technische Arbeit und erstelle eine Übergabe.

Dokumentiere:

• Ziel der Sitzung,
• erreichten Stand,
• geänderte Dateien,
• Git-Status,
• letzten funktionierenden Commit,
• ausgeführte Tests mit Ergebnis,
• offene Fehler,
• nicht geprüfte Annahmen,
• nächste drei sinnvolle Schritte,
• Befehle zum lokalen Start.

Aktualisiere vorhandene Projektdokumentation nur dort, wo Fakten geändert wurden. Keine Secrets ausgeben. Kein Commit ohne ausdrücklichen Auftrag. ```

Skill-Aufbau

FAKT: Ein Claude-Code-Skill befindet sich typischerweise in einem Verzeichnis unter .claude/skills/<name>/ und enthält eine SKILL.md. Unterstützende Skripte, Vorlagen und Referenzen können daneben liegen. Skill-Beschreibungen werden zur Auswahl geladen; der vollständige Inhalt wird bei Verwendung in den Kontext aufgenommen. [S012]

Beispiel:

``text .claude/skills/project-audit/ ├── SKILL.md ├── references/ └── scripts/ ``

Minimalbeispiel:

```markdown

name: project-audit description: Analysiert ein bestehendes Projekt ohne Änderungen. allowed-tools: Read Grep Glob

Untersuche Projektziel, Architektur, Startbefehle, Tests, Deployment, Backup und erkennbare Risiken. Trenne FAKT, ABLEITUNG und UNKLAR. Verändere keine Dateien. ```

allowed-tools genehmigt die angegebenen Werkzeuge für den aufrufenden Turn vorab. Es begrenzt nicht automatisch alle anderen Werkzeuge; die allgemeinen Permission-Regeln gelten weiterhin. [S012]

Skill-Matrix des Starterkits

VORLAGE: Die Skills im beigefügten Starterkit sind Ausgangspunkte. Befehle, Pfade und Deploymentziele sind bewusst nicht fest verdrahtet.

Produktions-Skill

```markdown

name: deploy-production description: Führt nach ausdrücklicher Benutzerfreigabe das dokumentierte Produktionsdeployment aus. disable-model-invocation: true

1. Lies SPEC.md, CLAUDE.md und docs/deployment.md.
2. Prüfe Git-Status, Tests, Build, Backup und Rollback.
3. Zeige einen Go/No-Go-Bericht.
4. Führe keine Aktion aus, solange kritische Angaben UNKLAR sind.
5. Verlange die explizite Auswahl des dokumentierten Zielsystems.
6. Führe nur die freigegebenen Schritte aus.
7. Prüfe das Ergebnis und dokumentiere Version und Status.

```

FAKT: disable-model-invocation: true verhindert die automatische Auslösung durch Claude und ist laut Anthropic gerade für Deployments, Commits oder Nachrichten mit Seiteneffekt vorgesehen. [S012]

Restore-Skill

```markdown

name: restore-backup description: Plant und führt eine kontrollierte Wiederherstellung aus. disable-model-invocation: true

1. Bestimme Ziel, Backupstand und erwarteten Datenstand.
2. Prüfe Integrität, Schlüssel und Softwareversionen.
3. Erstelle einen nicht destruktiven Testplan.
4. Stelle bevorzugt in eine getrennte Zielumgebung wieder her.
5. Überschreibe Produktion nur nach ausdrücklicher Freigabe.
6. Prüfe Anwendung, Datenbank, Uploads und Berechtigungen.
7. Protokolliere Ergebnis und Abweichungen.

```

Vorsichtige Settings-Vorlage

``json { "$schema": "https://json.schemastore.org/claude-code-settings.json", "permissions": { "defaultMode": "default", "disableBypassPermissionsMode": "disable", "disableAutoMode": "disable", "deny": [ "Read(./.env)", "Read(./.env.local)", "Read(./.env.production)", "Read(./secrets/)", "Read(.//*.pem)", "Read(./**/*.key)" ], "ask": [ "Bash(git commit *)", "Bash(git push *)", "Bash(git tag *)", "Bash(ssh *)", "Bash(scp *)", "Bash(sftp *)", "Bash(docker compose down *)" ] } } ``

VORLAGE: Diese Datei reduziert automatische Seiteneffekte, ist aber keine universelle Sicherheitskonfiguration. Die Syntax ist versionsabhängig. Die tatsächliche Konfiguration muss mit /status, /permissions, /config und dem aktuellen Schema kontrolliert werden. [S008] [S009]

AKTUELLER REFRESH-HINWEIS: Anthropic kündigt für den 14. August 2026 an, Auto Mode bei neuen Sitzungen bestimmter Pläne als Standard anzubieten. Ein selbst oder organisatorisch gesetzter Modus bleibt nach Herstellerangabe bestehen, sofern die einmalige Umstellung nicht akzeptiert wird. Auto Mode reduziert Nachfragen, garantiert aber laut Hersteller keine Sicherheit. Das Starterkit deaktiviert Auto Mode deshalb konservativ. [S096]

Hook-Beispiel: geschützte Dateien

VORLAGE: Ein PreToolUse-Hook kann Änderungen an definierten Dateien blockieren. Das Starterkit enthält ein inaktives Python-Beispiel. Aktivierung erst nach Prüfung.

Prinzip:

``text Toolaufruf Edit/Write ↓ PreToolUse-Hook ↓ Pfad geschützt? ja → Exit 2, blockieren nein → fortfahren ``

FAKT: Ein blockierender PreToolUse-Hook kann mit Exit-Code 2 die Aktion verhindern und über Standardfehler eine Rückmeldung liefern. [S013]

Gebündelte Skills /run, /verify und /code-review

FAKT: Claude Code enthält im Stand August 2026 gebündelte Skills. Die Dokumentation nennt unter anderem /run, /verify, /debug und /code-review. /run und /verify können eine Anwendung starten und gegen die laufende Anwendung prüfen; bei Projekten mit Datenbank, .env, grafischer Sitzung oder mehrstufigem Start kann die automatische Erkennung unzuverlässig sein. [S012]

EMPFEHLUNG: Diese Funktionen zuerst in einem lokalen Testprojekt nutzen. Für produktionsnahe Projekte Start- und Prüfverfahren explizit in README.md, CLAUDE.md oder einem projektspezifischen Skill dokumentieren.

Wann ein Subagent sinnvoll ist

Ein Subagent ist nützlich, wenn eine Aufgabe:

• einen eigenen, begrenzten Kontext braucht,
• nur bestimmte Werkzeuge erhalten soll,
• parallel zu einer anderen Analyse laufen kann,
• ein spezialisiertes Prüfprofil benötigt.

Beispiele:

• reine Sicherheitsprüfung,
• Testanalyse,
• Dokumentationsprüfung,
• Recherche in einem großen Repository.

Nicht jede Aufgabe braucht einen Subagent. Zusätzliche Agenten erhöhen Koordinations- und Kontextaufwand. Anthropic empfiehlt einfache Workflows, solange sie ausreichen. [S015] [S029]

Wann MCP sinnvoll ist

MCP kann Claude Code mit externen Werkzeugen oder Datenquellen verbinden. Dadurch kann ein Agent beispielsweise Informationen aus Issue-Systemen, Datenbanken oder internen Diensten erhalten. [S016]

EMPFEHLUNG: MCP erst hinzufügen, wenn der konkrete Nutzen benannt ist. Jeder Server erweitert:

• Datenzugriff,
• Berechtigungsfläche,
• externe Abhängigkeiten,
• mögliche Prompt-Injection-Quellen,
• Secret-Verwaltung.

OWASP veröffentlichte am 4. August 2026 eine eigene MCP-Risikoliste. Diese Quelle ist sehr neu und schnell veraltend; sie bestätigt vor allem, dass MCP-Verbindungen wie andere privilegierte Integrationen risikobasiert geprüft werden müssen. [S082]

Wann ein Plugin sinnvoll ist

Plugins bündeln Skills, Agents, Hooks oder MCP-Konfiguration. Sie eignen sich für standardisierte Teamwerkzeuge. [S008] [S014]

EMPFEHLUNG: Für den ersten eigenen Workflow sind lokale Projektdateien transparenter. Ein Plugin lohnt sich, wenn mehrere Projekte dieselbe geprüfte Funktion benötigen und Versionierung, Verteilung sowie Aktualisierung organisiert werden sollen.

Projektstart-Skill: gewünschtes Verhalten

Der Skill /project-init sollte:

1. Arbeitsverzeichnis prüfen,
2. vorhandene Dateien respektieren,
3. Git-Status prüfen,
4. fehlende Standarddateien nur nach Bedarf anlegen,
5. /init beziehungsweise vorhandene CLAUDE.md berücksichtigen,
6. .gitignore und .env.example anlegen,
7. keine echten Secrets erzeugen,
8. Test- und Startbefehle nicht erfinden,
9. offene Punkte als UNKLAR markieren,
10. ersten Commit nur vorbereiten, nicht ungefragt ausführen.

Der Skill soll nicht ungefragt Framework, Datenbank, Hosting oder Cloudanbieter auswählen. Das sind Projektentscheidungen.

Qualitätsprüfung eines eigenen Skills

• Ist der Name eindeutig?
• Beschreibt die description, wann der Skill eingesetzt wird?
• Ist der Inhalt kürzer als ein universeller Leitfaden und auf den Ablauf fokussiert?
• Sind Seiteneffekte manuell geschützt?
• Sind allowed-tools minimal?
• Sind Argumente definiert?
• Enthält der Skill keine Secrets?
• Funktioniert er in einem Testprojekt?
• Meldet er UNKLAR, statt Werte zu erfinden?
• Dokumentiert er Ergebnis und Fehler?

Anthropic weist darauf hin, dass der geladene Skill-Inhalt im Sitzungskontext verbleibt. Auch Skills sollten deshalb knapp und auf den konkreten Ablauf konzentriert bleiben. [S012]

\newpage

Quellen, Methodik und Refresh-Liste

Recherchemethodik

Dieses Dossier wurde mit folgendem Quellenprinzip erstellt:

1. Primärdokumentation zuerst: Anthropic, Git, GitHub, Apache, Docker, Synology, Ubuntu, PostgreSQL, MySQL, SQLite, W3C, NIST, CISA und OWASP.
2. Aktueller Stand: Recherche- und Abrufstand 8. August 2026.
3. Herstellerangaben gekennzeichnet: Funktions- und Nutzungsangaben zu Claude Code stammen überwiegend von Anthropic. Sie belegen die dokumentierte Funktion, nicht automatisch unabhängige Wirksamkeit.
4. Studien nicht verallgemeinert: Produktivitätsergebnisse werden mit Setting, Stichprobe und Messart dargestellt.
5. Vorlagen klar getrennt: Prompts, Projektstruktur, Skills und Settings des Starterkits sind abgeleitete Vorlagen, keine offiziellen Anthropic-Standards.
6. Ungeklärtes nicht erraten: Modell, DSM-Paket, Betriebssystemversion, Hostinganbieter, Runtime, Preis und Rechtslage müssen im konkreten Projekt geprüft werden.

Grenzen des Dossiers

Dieses Dossier kann kein individuelles Sicherheitskonzept, keine Rechtsberatung und keine Abnahme eines konkreten Produktivsystems ersetzen. Besonders folgende Entscheidungen bleiben ohne Projektkontext UNKLAR:

• geeigneter Tech-Stack,
• notwendige Servergröße,
• konkrete Kosten,
• geeignetes Synology-Modell,
• öffentliches Hosting auf einer NAS,
• Datenschutz- und Vertragsanforderungen,
• zulässige Aufbewahrungsdauer,
• notwendige Hochverfügbarkeit,
• konkrete RPO-/RTO-Werte,
• erforderliche Zertifizierungen,
• ausreichender Umfang eines Penetrationstests.

Schnell veraltend – vor Nutzung erneut prüfen

Claude Code

• Installationsbefehle und unterstützte Betriebssysteme,
• aktuelle Version und Changelog,
• Shell-Unterstützung unter Windows,
• Permission-Modi und Auto Mode,
• Syntax und Auswertungsregeln der Permissions,
• Sandbox-Unterstützung,
• Hook-Ereignisse und Rückgabeschema,
• Checkpoint-Grenzen,
• Skill-Frontmatter und gebündelte Skills,
• Plugins, Subagents und MCP,
• Tarife, Limits, Kosten und Datenverwendung.

Besonders akut: Die Herstellerdokumentation kündigt für den 14. August 2026 eine Änderung des Standardverhaltens von Auto Mode für neue Sitzungen bestimmter Pläne an. [S096]

Synology

• DSM-Version,
• Web Station,
• Container Manager,
• Paketverfügbarkeit je Modell,
• Btrfs- und Snapshot-Unterstützung,
• Hyper-Backup-Ziele,
• Zertifikats- und Reverse-Proxy-Verfahren.

Server und Deployment

• unterstützte Ubuntu-Version,
• Paketnamen und Installationswege,
• Docker- und Compose-Version,
• Certbot-Installationsweg,
• TLS-Challenges,
• Datenbankversionen,
• Hostingoberflächen und DNS-Verfahren.

Sicherheitsquellen

• OWASP Top 10,
• OWASP GenAI- und MCP-Risikolisten,
• NIST-Leitfäden,
• GitHub Secret Scanning und Push Protection,
• Hersteller-Sicherheitsmitteilungen.

Zeitlose Grundsätze

Weniger schnell ändern sich diese Grundregeln:

• Projekte trennen.
• Anforderungen vor der Implementierung klären.
• Zugriff nach Minimalprinzip vergeben.
• Secrets nicht in Git speichern.
• Verifikation in jeden Arbeitsauftrag einbauen.
• Git für nachvollziehbare Codezustände verwenden.
• Datenbank, Uploads und Konfiguration separat sichern.
• Backups durch Restore testen.
• Staging und Produktion trennen.
• Produktive Seiteneffekte bewusst freigeben.
• Externe Inhalte nicht als vertrauenswürdige Anweisung behandeln.
• Betrieb und Wartung als Teil des Produkts verstehen.

Quellenverzeichnis

S001 - Anthropic: *Claude Code Overview*. https://code.claude.com/docs/en/overview - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S002 - Anthropic: *Claude Code Quickstart*. https://code.claude.com/docs/en/quickstart - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S003 - Anthropic: *Claude Code Advanced setup*. https://code.claude.com/docs/en/setup - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S004 - Anthropic: *Terminal guide for Claude Code*. https://code.claude.com/docs/en/terminal-guide - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S005 - Anthropic: *How Claude Code works*. https://code.claude.com/docs/en/how-claude-code-works - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S006 - Anthropic: *Best practices for Claude Code*. https://code.claude.com/docs/en/best-practices - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S007 - Anthropic: *How Claude remembers your project*. https://code.claude.com/docs/en/memory - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S008 - Anthropic: *Claude Code settings*. https://code.claude.com/docs/en/settings - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S009 - Anthropic: *Configure permissions*. https://code.claude.com/docs/en/permissions - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S010 - Anthropic: *Configure the sandboxed Bash tool*. https://code.claude.com/docs/en/sandboxing - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S011 - Anthropic: *Checkpointing*. https://code.claude.com/docs/en/checkpointing - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S012 - Anthropic: *Extend Claude with skills*. https://code.claude.com/docs/en/skills - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S013 - Anthropic: *Automate actions with hooks*. https://code.claude.com/docs/en/hooks-guide - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S014 - Anthropic: *Extend Claude Code: feature overview*. https://code.claude.com/docs/en/features-overview - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S015 - Anthropic: *Create custom subagents*. https://code.claude.com/docs/en/sub-agents - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S016 - Anthropic: *Connect Claude Code to tools via MCP*. https://code.claude.com/docs/en/mcp - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S017 - Anthropic: *Use Claude Code in VS Code*. https://code.claude.com/docs/en/vs-code - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S018 - Anthropic: *Development containers*. https://code.claude.com/docs/en/devcontainer - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S019 - Anthropic: *Claude Code changelog*. https://code.claude.com/docs/en/changelog - Version 2.1.226, 08.08.2026. Hinweis: Schnell veraltend.

S020 - Anthropic: *Claude Pro plan*. https://support.claude.com/en/articles/8325606-what-is-the-pro-plan - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S021 - Anthropic: *Claude Max plan*. https://support.claude.com/en/articles/11049741-what-is-the-max-plan - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S022 - Anthropic: *Manage costs effectively*. https://code.claude.com/docs/en/costs - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend; Anbieterangabe.

S023 - Anthropic: *Data usage for consumer Claude accounts*. https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training - Aktualisierungsstand laut Seite; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S024 - Anthropic: *How long do you store my data?*. https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-data - Aktualisierungsstand laut Seite; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S025 - Anthropic: *How Claude Code is used in practice*. https://www.anthropic.com/research/claude-code-expertise - 16.06.2026. Hinweis: Studie des Anbieters; Methodik beachten.

S026 - Anthropic: *Claude Code: Best practices for agentic coding*. https://www.anthropic.com/engineering/claude-code-best-practices - 18.04.2025. Hinweis: Anbieterleitfaden.

S027 - Anthropic: *Prompting best practices*. https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices - Datum nicht ausgewiesen; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S028 - Anthropic: *Effective context engineering for AI agents*. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents - 29.09.2025. Hinweis: Anbieterleitfaden.

S029 - Anthropic: *Building effective agents*. https://www.anthropic.com/engineering/building-effective-agents - 19.12.2024. Hinweis: Anbieterleitfaden.

S030 - Git: *Installing Git*. https://git-scm.com/book/en/v2/Getting-Started-Installing-Git - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S031 - Git: *git-init documentation*. https://git-scm.com/docs/git-init - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S032 - Git: *gitignore documentation*. https://git-scm.com/docs/gitignore - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S033 - Git: *Working with remotes*. https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S034 - Git: *git-worktree documentation*. https://git-scm.com/docs/git-worktree - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S035 - GitHub: *Backing up a repository*. https://docs.github.com/en/repositories/archiving-a-github-repository/backing-up-a-repository - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S036 - GitHub: *Connecting to GitHub with SSH*. https://docs.github.com/en/authentication/connecting-to-github-with-ssh - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S037 - GitHub: *About rulesets*. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S038 - GitHub: *Secret scanning*. https://docs.github.com/en/code-security/concepts/secret-security/secret-scanning - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S039 - GitHub: *Push protection*. https://docs.github.com/en/code-security/concepts/secret-security/push-protection - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S040 - GitHub: *Using secrets in GitHub Actions*. https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S041 - GitHub: *Removing sensitive data from a repository*. https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S042 - MDN Web Docs: *How the web works*. https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Web_standards/How_the_web_works - 20.07.2026. Hinweis: Langsam veraltend.

S043 - MDN Web Docs: *What is a domain name?*. https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_domain_name - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S044 - MDN Web Docs: *An overview of HTTP*. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S045 - Apache Software Foundation: *Apache Core Features: DocumentRoot*. https://httpd.apache.org/docs/current/mod/core.html#documentroot - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S046 - Apache Software Foundation: *Apache Virtual Host documentation*. https://httpd.apache.org/docs/current/vhosts/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S047 - Python Software Foundation: *http.server documentation*. https://docs.python.org/3/library/http.server.html - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S048 - Microsoft: *Remote Development using SSH in Visual Studio Code*. https://code.visualstudio.com/docs/remote/ssh - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S049 - Internet Security Research Group / Let’s Encrypt: *Challenge Types*. https://letsencrypt.org/docs/challenge-types/ - 12.02.2026. Hinweis: Schnell veraltend.

S050 - Electronic Frontier Foundation / Certbot: *Certbot instructions for Apache on Ubuntu*. https://certbot.eff.org/instructions?ws=apache&os=ubuntufocal - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S051 - Synology: *Web Station - Web portal and virtual host*. https://kb.synology.com/en-global/DSM/help/WebStation/application_webserv_virtualhost?version=7 - Laufende DSM-Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend; modell-/versionsabhängig.

S052 - Synology: *How to host a website using Web Station*. https://kb.synology.com/en-global/DSM/tutorial/How_to_host_a_website_using_Web_Station - Laufende DSM-Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend; modell-/versionsabhängig.

S053 - Synology: *Container Manager - Projects*. https://kb.synology.com/en-global/DSM/help/ContainerManager/docker_project?version=7 - Laufende DSM-Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend; modellabhängig.

S054 - Synology: *Synology DSM Developer Guide*. https://help.synology.com/developer-guide/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S055 - Synology: *How to back up your Synology NAS*. https://kb.synology.com/de-de/DSM/tutorial/How_to_back_up_your_Synology_NAS - 08.05.2026. Hinweis: Schnell veraltend; DSM-/Paketabhängig.

S056 - Synology: *Hyper Backup*. https://kb.synology.com/en-global/DSM/help/HyperBackup/data_backup_create?version=7 - Laufende DSM-Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S057 - Synology: *Snapshot Replication - data protection*. https://kb.synology.com/en-global/DSM/help/SnapshotReplication/data_protection_mgr?version=7 - Laufende DSM-Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend; Btrfs-/modellabhängig.

S058 - Synology: *Terminal and SNMP - Enable SSH*. https://kb.synology.com/en-global/DSM/help/DSM/AdminCenter/system_terminal?version=7 - Laufende DSM-Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S059 - Docker: *Docker Compose overview*. https://docs.docker.com/compose/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S060 - Docker: *Volumes*. https://docs.docker.com/engine/storage/volumes/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S061 - Docker: *Compose secrets*. https://docs.docker.com/compose/how-tos/use-secrets/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S062 - Docker: *Compose file security considerations*. https://docs.docker.com/compose/security/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S063 - Docker: *Rootless mode*. https://docs.docker.com/engine/security/rootless/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S064 - Docker: *docker compose down*. https://docs.docker.com/reference/cli/docker/compose/down/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S065 - Docker: *Bind mounts*. https://docs.docker.com/engine/storage/bind-mounts/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S066 - Canonical / Ubuntu: *OpenSSH server*. https://ubuntu.com/server/docs/how-to/security/openssh-server/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S067 - Canonical / Ubuntu: *Set up an FTP server; SFTP and FTPS distinction*. https://ubuntu.com/server/docs/how-to/networking/ftp/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S068 - Canonical / Ubuntu: *Firewall (ufw)*. https://ubuntu.com/server/docs/how-to/security/firewalls/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S069 - Canonical / Ubuntu: *Automatic updates*. https://ubuntu.com/server/docs/how-to/software/automatic-updates/ - 13.03.2025. Hinweis: Schnell veraltend.

S070 - Canonical / Ubuntu: *AppArmor*. https://ubuntu.com/server/docs/how-to/security/apparmor/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S071 - Canonical / Ubuntu: *Package management*. https://ubuntu.com/server/docs/how-to/software/package-management/ - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S072 - PostgreSQL Global Development Group: *PostgreSQL Backup and Restore*. https://www.postgresql.org/docs/current/backup.html - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Versionsabhängig.

S073 - Oracle: *MySQL Backup and Recovery*. https://dev.mysql.com/doc/refman/8.4/en/backup-and-recovery.html - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Versionsabhängig.

S074 - SQLite Consortium: *SQLite Backup API*. https://www.sqlite.org/backup.html - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S075 - CISA: *Back Up Business Data*. https://www.cisa.gov/secure-our-world/back-up-business-data - Laufende Behördeninformation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S076 - W3C Web Accessibility Initiative: *WCAG 2 Overview*. https://www.w3.org/WAI/standards-guidelines/wcag/ - WCAG 2.2: 05.10.2023; Update 12.12.2024. Hinweis: Langsam veraltend.

S077 - Microsoft: *Playwright Test assertions*. https://playwright.dev/docs/test-assertions - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S078 - Microsoft: *Playwright best practices*. https://playwright.dev/docs/best-practices - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S079 - Google Chrome for Developers: *Introduction to Lighthouse*. https://developer.chrome.com/docs/lighthouse/overview - 02.06.2025. Hinweis: Schnell veraltend.

S080 - OWASP Foundation: *OWASP Top 10:2025*. https://owasp.org/Top10/2025/ - 2025. Hinweis: Langsam veraltend.

S081 - OWASP GenAI Security Project: *LLM01:2025 Prompt Injection*. https://genai.owasp.org/llmrisk/llm01-prompt-injection/ - 2025. Hinweis: Schnell veraltend.

S082 - OWASP GenAI Security Project: *OWASP MCP Top 10*. https://genai.owasp.org/resource/owasp-mcp-top-10/ - 04.08.2026. Hinweis: Sehr schnell veraltend.

S083 - OWASP Cheat Sheet Series: *Secrets Management Cheat Sheet*. https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Schnell veraltend.

S084 - OWASP Cheat Sheet Series: *Secure Code Review Cheat Sheet*. https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S085 - NIST: *SP 800-218A: Secure Software Development Practices for Generative AI*. https://csrc.nist.gov/pubs/sp/800/218/a/final - 26.07.2024. Hinweis: Langsam veraltend.

S086 - DORA / Google Cloud: *DORA Research: 2025 - State of AI-assisted Software Development*. https://dora.dev/research/2025/ - 2025; aktuelle Fassung v2025.2. Hinweis: Studie; Kontext und Methodik beachten.

S087 - DORA / Google Cloud: *DORA Research 2025 Errata*. https://dora.dev/research/2025/errata/ - 24.11.2025. Hinweis: Korrekturliste.

S088 - METR: *Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity*. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ - 10.07.2025. Hinweis: RCT; enges Setting, nicht verallgemeinern.

S089 - METR: *We are changing our developer productivity experiment*. https://metr.org/blog/2026-02-24-uplift-update/ - 24.02.2026. Hinweis: Forschungsupdate; Selektionsprobleme.

S090 - GitHub / Microsoft Research: *The Impact of AI on Developer Productivity: Evidence from GitHub Copilot*. https://arxiv.org/abs/2302.06590 - 13.02.2023. Hinweis: Anbieternahe Studie; enger Labortask.

S091 - METR: *Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity*. https://metr.org/blog/2026-05-11-ai-usage-survey/ - 11.05.2026. Hinweis: Selbstauskunft; nicht kausal.

S092 - Simon Willison: *Not all AI-assisted programming is vibe coding*. https://simonwillison.net/2025/Mar/19/vibe-coding/ - 19.03.2025. Hinweis: Begriffsanalyse; Sekundärquelle mit Originalzitat.

S093 - Y. Zhang et al.: *Vibe coding: programming through conversation with artificial intelligence*. https://arxiv.org/abs/2506.23253 - 29.06.2025. Hinweis: Preprint.

S094 - The Twelve-Factor App: *III. Config*. https://12factor.net/config - Ursprünglich 2011; laufende Website, Abruf 08.08.2026. Hinweis: Zeitlose Grundregel; keine Norm.

S095 - OWASP Cheat Sheet Series: *Cryptographic Storage Cheat Sheet*. https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html - Laufende Dokumentation; Abruf 08.08.2026. Hinweis: Langsam veraltend.

S096 - Anthropic: *Choose a permission mode*. https://code.claude.com/docs/en/permission-modes - Ankündigung für 14.08.2026; Abruf 08.08.2026. Hinweis: Sehr schnell veraltend; Auto-Mode-Standardänderung.

Schlussfolgerung

Claude Code senkt die Hürde, reale Softwareprojekte zu erstellen. Es beseitigt aber nicht die Notwendigkeit, ein Projekt zu führen. Je mehr technische Ausführung an einen Agenten delegiert wird, desto wichtiger werden klare Anforderungen, minimale Rechte, überprüfbare Ergebnisse, Versionierung, Backup und kontrollierte Veröffentlichung.

Die belastbare Arbeitsform lautet deshalb:

``text Idee → Projektinterview → SPEC.md → Projektordner und Git → CLAUDE.md, Rules und Skills → kontrollierte Permissions → lokale Entwicklung → Tests und Verifikation → Commit → Staging → Backup und Rollback → manuell freigegebenes Deployment → Betrieb, Updates und Restore-Tests ``

Nicht der längste Prompt erzeugt die höchste Qualität. Die höchste Zielperformance entsteht aus einem geschlossenen System, in dem Claude die technische Arbeit ausführen kann, der Mensch aber Ziel, Grenzen, Belege und Freigaben kontrolliert.