Mit einem Coding-Agenten bauen

Schritt-für-Schritt für Einsteiger

Voraussetzungen: Lesen Sie die beiden Einsteigeranleitungen unten, schließen Sie die lokale Web-Einrichtung ab und öffnen Sie dieses Repository im Stammverzeichnis in Ihrem Editor. Ein Coding-Agent ist ein KI-Werkzeug — Cursor, Claude Code, Devin oder ein ähnlicher Assistent — das Ihr Projekt liest, Dateien bearbeitet und Befehle ausführt. Alles auf dieser Seite gilt für jedes dieser Werkzeuge.

Kurze Begriffe: Ein Prompt ist der Anweisungstext, den Sie in den Agenten einfügen. Ein Diff ist die Liste der Dateiänderungen, die er vorschlägt. Das Repository-Stammverzeichnis ist der oberste Ordner mit der package.json — der Agent sollte immer dort starten.

1. Öffnen Sie den Ordner prompts/ im Repository-Stamm und kopieren Sie den Prompt, der Ihrer Aufgabe am nächsten kommt. new-landing-page.md ist ein guter erster Versuch.

2. Fügen Sie ihn in Ihren Agenten ein und füllen Sie die <placeholders> aus: die gewünschte Route, was die Seite oder der Bildschirm tun soll, wer sie nutzen darf und wie Erfolg aussieht. Fügen Sie dann eine Zeile hinzu: Lies llms.txt, dann AGENTS.md, dann .ai/PROJECT_CONTEXT.md, bevor du Code anfasst.

3. Lassen Sie den Agenten die Dateien auflisten, die er ändern wird, und die Prüfungen, die er vor der Bearbeitung ausführt. Wenn er fertig ist, prüfen Sie den Diff — Sie genehmigen echte Änderungen an Ihrem Produkt.

4. Veröffentlichen, Deployen und kostenpflichtige Anbieteraufrufe gehören nie in einen Aufgaben-Prompt. Behalten Sie sie als separate Schritte bei, die Sie ausdrücklich genehmigen.

• Bevor Sie beginnen
• Terminal-Grundlagen
• Lokale Web-Einrichtung

Die Dateien, die Ihr Agent liest

Das Repository liefert einen kleinen Stapel Dateien mit, die für Agenten geschrieben sind, nicht nur für Menschen. Sie fügen diesen Kontext nie von Hand ein — verweisen Sie den Agenten auf llms.txt, und er liest den Rest selbst.

Die Lesereihenfolge zählt: llms.txt ist die Karte, AGENTS.md setzt die Grenzen, und .ai/PROJECT_CONTEXT.md trägt, was frühere Sitzungen gelernt haben. Ein Agent, der die Grenzen überspringt, produziert Code, den Sie nicht ausliefern können.

Die Prompt-Bibliothek

prompts/README.md ist das Verzeichnis. Jede Datei ist ein vollständiges Briefing: Einfügen, die <placeholders> ausfüllen, und die Regeln des Kits — Design-Tokens statt hartcodierter Farben, Kit-Blöcke statt erfundener Muster — reisen mit.

Für den Weg von null auf laufend fügen Sie stattdessen prompts/agent-setup.md ein — er steuert die als Nächstes beschriebene unbeaufsichtigte Einrichtung.

• Die Einrichtung vom Agenten ausführen lassen

• agent-setup.md — das Kit mit einem Agenten aufsetzen und deployen
• pick-a-style.md — einen Designstil auf das gesamte Produkt anwenden
• new-landing-page.md — eine Marketingseite aus Kit-Blöcken aufbauen
• new-app-screen.md — einen Bildschirm innerhalb der Workspace-App-Hülle hinzufügen
• restyle-product.md — eine bestehende Seite auf Kit-Tokens umstylen
• ui-audit.md — das visuelle und Barrierefreiheits-Audit auf einer Route ausführen

Den Agenten installieren und deployen lassen

Das Kit kann sich weitgehend selbst einrichten. Das Einfügen von prompts/agent-setup.md lässt den Agenten docs/agent-setup.md — das mitgelieferte Runbook — Phase für Phase ausführen: Vorabprüfungen, Umgebungsdateien, Installation, Datenbankstart, Migrationen, App-Start und optional ein VPS-Deployment. Nach jeder Phase läuft deren Verifizierungspunkt, und er berichtet echte Ausgaben statt Behauptungen.

Zwei Helfer halten das sicher. scripts/setup-env.mjs erstellt die Env-Dateien aus .env.example: Es legt nur fehlende Dateien an, generiert nur fehlende oder Platzhalter-Geheimnisse, und sein Modus --check validiert ohne zu schreiben. docker-compose.dev.yml ist eine vollständig containerisierte Entwicklungsumgebung — Postgres plus ein Node-22-Dev-Container —, sodass der Agent kein installiertes Node.js auf Ihrem Computer braucht.

Welches Repository Sie erhalten haben, ist hier wichtig. Das Web-Repository und das All-Platforms-Monorepo liefern das Runbook, die Compose-Dateien, scripts/setup-env.mjs und prompts/. Die eigenständigen Mobile- und Desktop-Repositorys liefern eine eingegrenzte llms.txt, AGENTS.md, die .ai/-Spiegel-Dokumente und kuratierte Dokumente einschließlich docs/agent-security.md — aber nicht das Einrichtungs-Runbook oder die Compose-Dateien, weil das Backend, mit dem diese Apps sprechen, im Web-Repository liegt.

• Die agentengesteuerte Einrichtung durchgehen

Wie sich der Agent zwischen Sitzungen erinnert

Agenten haben kein Gedächtnis zwischen Sitzungen — der Ordner .ai/ ist das Gedächtnis. .ai/PROJECT_CONTEXT.md hält fest, was sich zuletzt geändert hat und warum. Daneben erklärt ein Spiegel-Dokument wie .ai/apps/web/src/reports.md die Entscheidungen hinter apps/web/src/reports.ts, die der Code allein nicht zeigt.

Der Vertrag ist einfach: Lesen Sie den Spiegel einer Datei, bevor Sie sie bearbeiten, und aktualisieren Sie den Spiegel, wenn die Änderung übernommen wird. Open-Threads-Einträge halten unfertige Arbeit fest, damit die nächste Sitzung weitermacht statt von vorn zu beginnen. Ein veralteter Spiegel ist schlimmer als keiner — wenn Sie den Diff des Agenten prüfen, kontrollieren Sie, dass die Spiegel geänderter Dateien mitgewandert sind.

Die eigene Agenten-Oberfläche der laufenden App

Ihr deploytes Produkt antwortet ebenfalls Agenten — diese Endpunkte existieren auf der laufenden App, nicht nur im Repository.

• GET /llms.txt — die App liefert ihren eigenen llmstxt.org-Index aus: die Anleitungen, öffentlichen Seiten und öffentlichen Endpunkte, mit absoluten URLs.
• POST /api/mcp — ein zustandsloser MCP-Endpunkt, der die Werkzeuge der App bereitstellt. Er akzeptiert sk_-API-Schlüssel nur als Bearer-Token — Browser-Cookie-Sitzungen gelten nie. Erstellen Sie Schlüssel unter Einstellungen → Entwickler.
• GET /api/v1/openapi — die OpenAPI-Spezifikation der öffentlichen REST-API, für Client-Generatoren und Agentenwerkzeuge.
• GET /api/health — die Liveness- und Abhängigkeitsprobe, die Load-Balancer und Verfügbarkeitsprüfungen aufrufen; sie meldet die Arten der Anbieterkonfiguration, niemals Geheimnisse.
• /status — eine menschenlesbare Seite, die den Zustand jedes Subsystems meldet.

Die Arbeit des Agenten ehrlich prüfen

Eine fertige Aufgabe ist ein Beleg, keine Zusammenfassung. Bevor Sie die Arbeit des Agenten übernehmen, prüfen Sie sie so, wie docs/agent-security.md ein Deployment prüft:

Wenn etwas nicht stimmt, schicken Sie den Diff zurück — der Agent korrigiert seine eigene Arbeit am schnellsten, wenn Sie die fehlschlagende Prüfung benennen. Für alles, was er nie allein hätte versuchen dürfen, sagen Sie es einmal ausdrücklich; die Grenze gilt für den Rest der Sitzung.

• Verifizierungstore und die Testsuite

• Er hat die Tests ausgeführt, die er behauptet — fragen Sie nach dem Befehl und seiner Ausgabe, nicht nach einer Schlussfolgerung.
• Geheimnisse blieben serverseitig — nichts Neues trägt ein NEXT_PUBLIC_- oder EXPO_PUBLIC_-Präfix, und kein Schlüssel wurde in einen Bericht oder Commit geschrieben.
• Jeder benutzereigene Lese- und Schreibzugriff blieb nach workspaceId abgegrenzt — keine Abfrage vertraut einer ID aus dem Browser.
• Der .ai/-Spiegel jeder geänderten Datei ist mit dem Code mitgewandert.
• Veröffentlichen, Deployen und kostenpflichtige Anbieteraufrufe blieben separate, von Ihnen genehmigte Schritte — der Agent hat nie selbstständig gemergt, gepusht oder deployt.
• Wenn ein Schritt zweimal fehlschlug, hat er gestoppt und den fehlschlagenden Befehl gemeldet, statt darum herum zu improvisieren.