Eine Mission ist das Ziel, das du Coder in Alltagssprache gibst. Sie ist die Eingabe, aus der ein Run wird.
Von der Mission zum Run
1. Du beschreibst das Ziel — zum Beispiel "füge der Orders-API Pagination hinzu und decke sie mit Tests ab".
2. Coder speichert die Mission als dauerhaftes Run-Record*, nicht als vergängliche Chat-Nachricht.
3. Die Planung erweitert die Mission zu einer überprüfbaren Task-Queue.
4. Die Ausführung führt die Queue in isolierten Workspaces aus.
5. Das Record schließt mit Logs, Freigaben, Status und Audit-Trail zusammen.
Eine gute Mission schreiben
- Nenne das Ergebnis, nicht nur die Schritte.
- Erwähne den Repository-Bereich oder das Modul.
- Nenne Constraints (Frameworks, Tests, Freigaben).
- Halte den Umfang klein genug, um ihn zu verifizieren.
Mission statt Chat
Weil eine Mission ein Run-Record ist, kannst du später dorthin zurückkehren, sehen was sich geändert hat, wer was freigegeben hat, und die Queue wiederverwenden. Sie ist zum Review gebaut, nicht für ein einmaliges Gespräch.
Requirement-Clarification-Chat
Wenn du New Build → Chat Intake* öffnest, gibt Coder deinen Text nicht einfach zurück. Er normalisiert deine Anfrage zu einer abgegrenzten Mission* und stellt nur die Fragen, die den Build tatsächlich verändern — zum Beispiel welches Repository, Authentifizierung, Datenbank, Sprache, User-Rollen, Deployment-Ziel oder Akzeptanzkriterien zutreffen. Jede Frage bietet sinnvolle Defaults als One-Click-Optionen.
Während du antwortest, aktualisiert sich die Mission-Karte: Intent, Komplexität, Build-Modus und ein Confidence-Score. Wenn nichts Build-relevantes fehlt, wechselt die Karte zu "Mission ist klar und abgegrenzt. Ready to build."* mit zwei Wahlmöglichkeiten:
- Review technical plan* — öffnet einen strukturierten Plan (Scope, Architektur, APIs, UI, Auth, Tests, Risiken, Akzeptanzkriterien), den du vor dem Build akzeptieren kannst.
- Start build* — startet den Run direkt aus dem erfassten Ziel.
Deine Antworten bleiben über Turns erhalten; eine Korrektur an einer früheren Antwort renormalisiert einfach die Mission. Das Gespräch endet immer in einem plan-fertigen Requirements-Vertrag, nicht in einem endlosen Chat.
Technischer Vertrag, Endpoint-Referenz, Beispiele, Migration und Troubleshooting: [Requirement clarification chat](/docs/coder-requirement-clarification-chat).
Verwandt
- Siehe, wie Missionen zu einer [Task-Queue](/docs/coder-task-queues) werden.
- Wähle einen [Modus](/docs/coder-modes) für die Ausführung.
War dieser Artikel hilfreich?