Zum Inhalt springen

Erste Schritte

Der schnellste Weg, SprintLoop zu verstehen, ist, eine kleine Änderung hindurchzuschieben. Diese Seite bringt dich von einem kalten Workspace zu einem gemergten Pull Request, der von einem Agent in einer Lane geschrieben wurde, die du abgenommen hast. Plane fünfzehn Minuten ein; budgetiere dreißig, wenn deine CI langsam ist.

Du brauchst: ein GitHub-Repo, in das du pushen kannst, eine Workstation mit git und einen Anthropic-, OpenAI- oder Google-AI-API-Key für die Harness, die du als Erstes racen willst. Alle drei gleichzeitig mitzubringen ist okay — die Racing-Oberfläche wird mit zwei oder mehr interessanter.

1. Anmelden und einen Workspace erstellen

Öffne https://app.sprintloop.ai/signup und melde dich mit Google, Microsoft oder per E-Mail an. Die erste Anmeldung erzeugt einen persönlichen Workspace mit einem Seat — du kannst später ohne History-Verlust auf einen Org-Workspace upgraden.

Einmal drin, drücke Cmd+K, um die Command Palette zu öffnen, und führe Workspace settings → Identity aus. Setze ein Workspace-Handle (kleinbuchstaben, alphanumerisch, z. B. acme) — das ist, was in Lane-Titeln, Audit-Exports und Federation-Receipts auftaucht. Den menschenlesbaren Display-Namen kannst du frei umbenennen; das Handle ist unveränderlich, damit der Audit-Trail stabil bleibt.

2. Ein Repo verbinden

Settings → Integrations → GitHub → Install the GitHub App. Wähle die Org oder das persönliche Konto, das die Repos besitzt, und gewähre Zugriff auf die spezifischen Repos, gegen die SprintLoop Lanes dispatchen soll. Die App braucht contents: write, pull_requests: write, checks: read und members: read. Sie fordert keinen Zugriff auf Secrets, Packages oder Admin-Endpoints an.

Wenn die Installation abgeschlossen ist, bist du wieder in SprintLoop mit einer grünen Status-Zeile für jedes verbundene Repo. Such dir eins aus und klicke Open lane. Der Workspace bereitet eine leere Lane vor, deren Scope auf den main-Branch des Repos zeigt, und wartet auf einen Brief.

Nimm für den Rest dieses Walkthroughs ein Sandbox-Repo oder einen Feature-Branch. Die Lane wird ein echtes PR öffnen.

3. Einen Modell-Key mitbringen

Settings → Models → Add provider. Füge einen Anthropic-, OpenAI-, Google- oder Mistral-Key ein. Keys werden verschlüsselt at-rest gespeichert und nie geloggt. Der Workspace verifiziert den Key mit einem One-Token-Request, bevor er ihn speichert — das kostet einen Bruchteil eines Cents und fängt offensichtliche Fehler (widerrufene Keys, falsche Region) ab, bevor du eine echte Lane dispatchst.

Du kannst mehrere Provider hinzufügen. Der Harness-Picker auf dem Dispatch-Screen zeigt nur Harnesses, deren Keys vorhanden sind.

4. Deine erste Lane dispatchen

Drücke Cmd+N, um den Dispatch-Dialog zu öffnen, oder klicke + Lane in der linken Sidebar. Wähle das verbundene Repo, gib der Lane einen Titel ("Add a /healthz endpoint that returns commit SHA" ist eine gute erste Aufgabe) und wähle eine Harness — Claude Code, Codex, Cursor Compose, Aider oder Devin. Wenn du mehrere Keys hast, ist Race aktiviert: Wähle zwei oder drei Harnesses, und SprintLoop läuft denselben Brief parallel durch jede und vergleicht die Diffs.

Bevor du Dispatch klickst, lege den Scope der Lane fest: Welche Pfade im Repo darf der Agent anfassen? Default ist das ganze Repo, aber für eine erste Lane lohnt es sich, einzuschränken — apps/api/healthz/** und package.json reichen für einen Healthz-Endpoint. Der Agent wird auf der Storage-Ebene abgelehnt, wenn er versucht außerhalb des Scopes zu schreiben.

Klick Dispatch. Du bist innerhalb einer Sekunde auf der Lane-Seite.

5. Die Lane beim Laufen beobachten

Die Lane-Seite zeigt drei Streams:

  • Tool log — jeder Read, Write, Shell-Command und Modell-Call, den die Harness macht. Jeder Eintrag wird signiert, bevor er angehängt wird; die Seite zeigt die Signatur-Heads beim Hochzählen.
  • Live diff — was der Agent im Working Tree geändert hat, alle paar Sekunden aktualisiert.
  • Sign-off — der Slot unten, in dem du (oder ein Approver) die Lane akzeptierst oder ablehnst.

Eine erste Healthz-Lane ist üblicherweise in 60–90 Sekunden fertig. Wenn die Harness „fertig” signalisiert, rendert das Review Committee (Architect, Security, QA) Verdicts in die rechte Rail. Sie sagen entweder Looks good, Has questions oder Block. Block heißt, dass mindestens ein Reviewer etwas Ernsthaftes gefunden hat, sodass der Merge-Button deaktiviert ist, bis du übersteuerst.

6. Abnehmen und mergen

Klicke Approve im Sign-off-Slot. Der Workspace fragt nach einer Inline-Bestätigung (du attestierst, dass du den Diff reviewed hast). Bei Approve macht SprintLoop:

  1. Pushed den Branch mit der signierten Commit-Message der Lane in dein GitHub-Remote.
  2. Öffnet ein Pull Request und füllt den Body mit dem Brief, der verwendeten Harness, den aufgerufenen Modell-Versionen und einem Link auf die Audit-Seite der Lane.
  3. Stempelt den Chain-Head der Lane in den Federation-Root und schreibt das Receipt in den evidence/-Bucket deines Workspaces.
  4. Schließt die Lane.

GitHub schickt das PR durch deine normale CI. Wenn CI grün ist, merge wie jedes andere PR. Wenn deine Branch Protection Approvals verlangt, ist SprintLoops Sign-off kein Ersatz für einen menschlichen Reviewer auf der GitHub-Seite — es ist eine interne Attestation, kein GitHub-Review.

Was gerade passiert ist

Du hast einen Agent in einen begrenzten Ausführungskontext mit kryptografischer Provenance dispatched. Jede Aktion wurde geloggt und signiert. Ein Panel aus Reviewer-Agents hat den Diff vor dir gelesen. Der Merge hat ein PR erzeugt, das dein Team in sechs Monaten auditieren kann.

Das ist die ganze Loop. Alles andere in den Docs — Racing, Context Engine, MCP, das Tuning des Review Committee — macht diese Loop enger.

Wohin als Nächstes

  • Lanes — die Primitive, die du gerade benutzt hast. Zehn Minuten wert.
  • Harness Racing — wie du denselben Brief gleichzeitig an zwei oder drei Harnesses dispatchst.
  • API-Referenz — wenn du Lane-Dispatch aus deinen eigenen Systemen scripten willst.

Wenn etwas nicht geklappt hat: Der häufigste Erste-Lane-Stolperer ist ein falscher Scope-Claim (Agent versucht, eine Datei außerhalb seines Scopes anzufassen, und bleibt hängen). Weite den Scope und dispatch neu — der Workspace merkt sich deinen vorigen Brief.