Eine Aufgabe vorbereiten, bevor Sie sie an einen Cloud-Coding-Agenten übergeben

Warum eine Cloud-Aufgabe mehr braucht als einen Prompt

In einer interaktiven Sitzung bemerkt ein Engineer einen Irrweg und korrigiert ihn. Ein Cloud-Agent arbeitet allein in einer entfernten Umgebung, deshalb wird jede offene Frage durch eine Vermutung beantwortet, und diese Vermutung kommt später als fertiger Pull Request an. GitHubs Leitfaden für seinen Cloud Agent sagt es deutlich: Betrachten Sie das zugewiesene Issue als den Prompt und geben Sie ihm eine klare Beschreibung, vollständige Abnahmekriterien und Hinweise, welche Dateien zu ändern sind.

Anthropics Leitfaden zur Evaluierung von Agenten liefert einen Test, der sich gut übertragen lässt: Eine gute Aufgabe ist eine, bei der zwei Fachleute unabhängig voneinander zum selben Urteil bestanden oder nicht bestanden kommen, und alles, was die Prüfungen verifizieren, steht in der Aufgabe. Eine Vorlage, die diese Hürde nimmt, kann auch ein Reviewer prüfen, ohne die Sitzung nachzuvollziehen.

Eine Vorlage in acht Teilen

Diese Vorlage funktioniert für jeden Cloud-Agenten, der ein Issue oder einen Prompt liest. Das ausgefüllte Beispiel ist hypothetisch.

## Goal
GET /v1/invoices returns CSV when the client sends Accept: text/csv.

## Context
- Read src/api/invoices/list.ts and its tests first
- Column order is defined in docs/exports.md

## Scope
- CSV output for this endpoint, with the same filters as JSON

## Non-goals
- Other endpoints, streaming, spreadsheet formats, UI changes

## Acceptance checks
- pnpm test:unit passes, with new tests for CSV output
- Accept: text/csv returns the documented columns in order
- Existing JSON tests pass unchanged

## Environment
- Tests use fixtures in test/fixtures/invoices; no database, no secrets

## Stop and ask before
- Adding a dependency, changing the shared serializer, editing CI

## Hand back
- Pull request: what changed, commands run with results,
  anything not verified, open questions

Nicht-Ziele und die Stoppliste verdienen die meiste Sorgfalt. Sie benennen die naheliegende Zusatzarbeit, die ein Agent sonst übernehmen könnte, und die Änderungen, über die eine Person entscheiden muss.

Drei Fragen vor dem Delegieren

• Könnte ein Reviewer, der die Vorlage nicht geschrieben hat, beurteilen, ob das Ergebnis fertig ist?
• Kann die Umgebung des Agenten die Abnahmeprüfungen ohne eine Person ausführen, inklusive Diensten und Testdaten?
• Kommt die Aufgabe ohne Produktionsdaten, Zugangsdaten und unumkehrbare Aktionen aus?

Ein Nein bei einer davon bedeutet interaktive Arbeit oder eine kleinere Aufgabe. GitHubs eigene Liste von Aufgaben, die besser bei Menschen bleiben, passt dazu: breite Refactorings, die Wissen über mehrere Repositories verlangen, tiefe Fachlogik, produktionskritische Probleme, Arbeit an Sicherheit, personenbezogenen Daten oder Authentifizierung, Incident Response und alles mit unklaren Anforderungen.

Große Vorhaben können trotzdem in Phasen an einen Agenten gehen. OpenAIs Cookbook-Rezept zum iterativen Arbeiten mit Codex beschreibt Phasendateien, jede klein genug, um unabhängig umgesetzt und geprüft zu werden, mit beobachtbaren Abnahmekriterien, einem Freigabepunkt und einer ausdrücklichen Abbruchbedingung.

Festlegen, wo der Agent anhält

Die Stoppliste in einer Vorlage ist eine Anweisung, und der Agent kann sie missverstehen. Dasselbe Cookbook-Rezept stellt Commits, Pushes, Deployments, Zugangsdaten und externe Schreibvorgänge hinter eine eigene ausdrückliche Freigabe. OpenAIs Artikel über Codex als Plattform beschreibt dieselbe Trennung von der Systemseite: Die umgebende Anwendung entscheidet, wo der Agent läuft, welche Tools er nutzen darf, welche Aktionen eine Freigabe brauchen und wie Ergebnisse in das führende System zurückkommen.

Praktisch heißt das: Die Vorlage sagt, wann angehalten wird, und die Umgebung sorgt dafür, dass es so ist, mit auf die Aufgabe begrenzten Zugangsdaten, Pushes nur auf den eigenen Branch des Agenten und Branch-Schutz, der Merges bei Menschen hält.

Was zurückkommt und wer es übernimmt

Der Engineer, der die Aufgabe delegiert hat, verantwortet das Ergebnis und liest es zuerst. Ein Pull Request, der sagt, was sich geändert hat, welche Befehle mit welchem Ergebnis liefen, was nicht geprüft wurde und was offen ist, lässt diesen Engineer schnell entscheiden, ob er ihn ins Review gibt, zurückschickt oder von Hand fertigstellt. Die Freigabe im Review übernimmt jemand anderes.

Verfehlt ein Ergebnis die Vorlage, klären Sie zuerst, was die Vorlage offen gelassen hat. Entscheiden Sie dann zwischen einigen gezielten Review-Kommentaren und einem neuen Lauf mit einer schärferen Vorlage, und übernehmen Sie das Fehlende in die Vorlage, damit sie zum Muster für die nächste ähnliche Aufgabe wird. Auf GitHub lässt das Bündeln von Kommentaren zu einem Review Copilot alle auf einmal bearbeiten statt Kommentar für Kommentar.

Leitfaden zu Spec-Driven DevelopmentBranch-Schutz für Agenten-Pull-Requests