Erste Schritte mit CodeCourier

Dies ist der Guide, den wir jedem frühen Beta-Nutzer in die Hand gedrückt hätten. Er führt Sie auf dem direkten Weg von einem frischen CodeCourier-Account zu einem echten Pull Request, den ein KI-Agent erstellt hat - in Ihrem Repo, mit grünen Tests, bereit zum Mergen. Kein Hand-Waving, keine "und dann passiert Magie"-Schritte. Zwanzig Minuten, von Anfang bis Ende.

1. Workspace erstellen

Melden Sie sich mit GitHub bei CodeCourier an. Beim ersten Login wird ein Workspace nach Ihrem Account-Namen angelegt. Ein Workspace ist gleichzeitig Abrechnungs-, Zugriffs- und Kontext-Grenze - jede Issue Session, jede Persona und jede Sprint Chain lebt darin.

Falls Sie CodeCourier für ein Team evaluieren, nutzen Sie Ihren beruflichen GitHub-Account, nicht den privaten. Den Workspace können Sie später umbenennen, aber der richtige Account von Anfang an erspart Ihnen erneute OAuth-Flows.

2. Erstes Repository verbinden

Klicken Sie im Dashboard auf Connect repo. Wählen Sie ein Repo klein genug, dass Sie die Arbeit des Agenten ohne Aufwand prüfen können - ein privates Projekt, ein internes Tool oder ein gehärtetes Sandbox-Repo eignen sich. Vermeiden Sie Ihr Produktions-Monorepo für den ersten Durchlauf.

CodeCourier verlangt standardmäßig Read- und Pull-Request-Create-Scopes. Es erhält niemals Push-Zugriff auf main. Jede Änderung läuft über einen Pull Request, den Sie selbst mergen.

Das Prinzip ist einfach: Agenten dürfen alles vorschlagen, gemerged wird von Menschen. Ihre Branch-Protection-Regeln behalten die Kontrolle.

3. Starter-Persona wählen

Personas sind versionierte Agenten-Konfigurationen - Modellwahl, Thinking-Budget, Tools, Skills und Hausstil in einem benannten Profil. Wählen Sie für Ihren ersten Lauf die Starter Engineer-Persona aus der Bibliothek. Sie ist der sicherste Default: ausgewogenes Modell, moderates Budget und konservative Review-Haltung.

Personas lassen sich später anpassen. Der Guide "Design a frontend persona" führt das im Detail durch.

4. Erste Issue Session starten

Klicken Sie auf New Issue Sessionin Ihrem verbundenen Repo. Sie sehen ein kleines Formular mit drei Feldern: Titel, Beschreibung und Persona. Für einen Vertrauen aufbauenden ersten Lauf nehmen Sie ein echtes kleines Ticket aus Ihrem Tracker - etwas wie "das README verweist noch auf das alte CLI-Flag" passt perfekt.

title:       Veraltetes CLI-Flag im README korrigieren
description: README erwähnt noch --legacy-mode, das in v2.0 entfernt wurde.
             Alle Verweise auf --strict aktualisieren.
persona:     Starter Engineer

Klicken Sie auf Launch. Eine Sandbox startet in unter einer Sekunde mit geklontem Repo, installierten Dependencies und geladener Persona. Sie sehen einen Live-Event-Stream - der Agent liest Dateien, entwirft einen Plan, schlägt Änderungen vor, lässt Tests laufen und iteriert, bis alles grün ist.

5. Pull Request prüfen

Wenn der Agent zufrieden ist, öffnet er einen Pull Request in Ihrem Repo. Klicken Sie sich nach GitHub durch. Sie sehen ein sauberes Diff, eine strukturierte Beschreibung von Was und Warum und die CI-Ergebnisse Ihrer bestehenden Checks.

Lesen Sie das Diff wie bei jedem ersten PR eines Junior-Engineers. Hinterlassen Sie Kommentare, wenn etwas nicht passt - der Agent liest sie und pusht einen Fixup-Commit. Mergen Sie, wenn Sie zufrieden sind.

6. Nächste Schritte

Das ist die Baseline. Die naheliegenden nächsten Schritte:

• Bauen Sie mit dem Guide Build a multi-step workflow eine Pipeline aus Planner, Coder, Reviewer und Shipper.
• Verkabeln Sie die GitHub Issue-Integration, damit neue Tickets automatisch zu Issue Sessions werden.
• Lesen Sie das Handbuch Operate CodeCourier in production, bevor Sie Agenten auf Ihr echtes Backlog ansetzen.

Sie haben jetzt das Muskelgedächtnis für jeden anderen Guide in diesem Hub. Der Rest ist Komposition.