Neue Aufgaben „Neue Aufgaben“ ist der Hauptweg, um Arbeit in Coroid einzubringen. Sie beschreiben die Arbeit einmal und leiten sie anschließend als Aufgabe, phasenweisen Plan, Bericht oder wiederkehrenden Zeitplan weiter.
Routung – zuerst das gewünschte Ergebnis auswählen
Die Routung entscheiden Sie selbst – nicht Coroid. Wählen Sie sie zuerst aus; das Formular zeigt dann nur die für dieses Ergebnis relevanten Optionen an.
| Option | Erzeugt |
|---|---|
| Eine ausführbare Aufgabe | Eine einzelne Aufgabe, die in einem pull request endet. |
| Phasenweiser Arbeitsplan | Ein phasenweiser Plan, den Sie vor dem Schreiben des Codes genehmigen. |
| Bericht | Ein generierter Bericht |
| Zeitplan | Ein wiederkehrender Monitor |
Wählen Sie eine ausführbare Aufgabe aus, wenn die Arbeit eine einzelne Änderung darstellt, die ein Reviewer in einem Rutsch lesen kann. Wählen Sie phasenweisen Arbeitsplan aus, wenn mehrere Änderungen in einer bestimmten Reihenfolge nötig sind oder wenn Sie den gesamten Ansatz vor der Umsetzung sehen möchten.
Zwei Schnellzugriffe befinden sich neben dem Formular: Issue-Import holt die Arbeit aus einem Tracker herein, und Fragen Sie Coroid überträgt dieselbe Aufgabe an den Chat-Assistenten.
Projekte
Wählen Sie das Projekt aus, zu dem diese Arbeit gehört. Sie können weitere Projekte hinzufügen aus, wenn die Arbeit mehrere abhängige Projekte umfasst – so wird Arbeit über Projektgrenzen hinweg ausgedrückt.
Die Arbeit beschreiben
Zwei Felder mit unterschiedlichen Funktionen.
Arbeitstitel – ein kurzer Name. Diesen werden Sie später in Listen suchen.
Beschreibung – der Inhalt: Ergebnis, Kontext, Einschränkungen, Quellmaterial und was Coroid liefern soll. Formulieren Sie das gewünschte Ergebnis statt der Umsetzungsdetails; Coroid wandelt es in eine prüfbare Spezifikation um, bevor die Arbeit anhand dieser Vorgaben überprüft wird.
Add rate limiting to the public API.
100 requests per minute per API key. Exceeding it returns 429 with a
Retry-After header. Limits are per key, not per IP.
Internal service-to-service calls are exempt — they authenticate with
service tokens, not API keys.
Do not change the existing auth middleware's public interface.Diese letzte Zeile übernimmt eine wichtige Aufgabe: Die Definitionsgrenzen machen den Unterschied zwischen einer gezielten Änderung und einer umfangreichen Ausweitung aus.
Erweiterte Einstellungen
Optional und normalerweise vor Beginn der Planung festgelegt.
Den SDLC-Workflow nutzen
Standardmäßig deaktiviert. Aktivieren Sie ihn, um einen Ansatz und eine Spezifikation vor Beginn der Planung zu überprüfen. Ohne Aktivierung startet die Planung direkt mit Ihrer Beschreibung.
Aktivieren Sie diesen Modus, wenn die Arbeit so bedeutsam ist, dass Sie vor dem Entwurf eines Ansatzes einen Kontrollpunkt benötigen. Deaktivieren Sie ihn bei Arbeiten, bei denen die Beschreibung bereits eindeutig ist.
Ziel
Was der Plan erreichen soll jenseits der Beschreibung. Nutzen Sie ihn für das hinter der Anfrage stehende Ziel – die Beschreibung sagt, was gebaut werden soll; das Ziel definiert den Zweck.
AI-Profil
Welche Modelle diese Arbeit ausführen. Siehe AI-Profile.
Qualitätskontrollen
Welche Qualitätsrichtlinie gilt. Standardmäßig wird die Qualitätskontroll-Richtlinie der Organisation verwendet, und die festgelegte Richtlinie ist zum Zeitpunkt der Ausführung festgelegt – eine spätere Änderung der Organisationsrichtlinie wirkt sich nicht rückwirkend auf bereits laufende Aufgaben aus.
Siehe Qualitätsrichtlinien und Prüfschritte.
Priorität
P0 auf P3, standardmäßig auf P2. Die Priorität ordnet die Warteschlange, wenn mehr Aufgaben vorliegen als Agenten-Slots zur Verfügung stehen. Sie erhöht die Kapazität nicht – siehe
Kapazität und Agenten-Slots.
Token-Budget pro generierter Aufgabe
Die Obergrenze für den Kontextumfang jeder generierten Aufgabe. Erhöhen Sie sie bei Arbeiten, die einen großen Codebestand umfassend auswerten müssen; senken Sie sie, um bei Routineaufgaben die Kosten zu begrenzen.
Einschränkungen
Planungsbeschränkungen, Nicht-Ziele, Abhängigkeiten und Auslieferungsregeln. Hier gehören explizite Nicht-Ziele hin – das effektivste Feld zur Verhinderung von Umfangserweiterungen.
Von / In Pull-Request einbinden
Aus welchem Branch die Arbeit beginnt und in welchen Branch pull request die Änderungen einbringt. Gleiches wie „Von“ ist standardmäßig aktiviert, sodass beide Einstellungen übereinstimmen.
main → new Coroid branch → PR into mainCoroid erstellt immer den Arbeitszweig. Diese Felder ändern lediglich den Zweigpunkt und den Ort, an dem der pull request landet – sie können Coroid nicht dazu bringen, direkt in einen bestehenden Zweig zu committen.
Verwenden Sie diese Einstellungen, wenn Sie in einen anderen als den Standardzweig zusammenführen, beispielsweise in einen
develop Zweig oder ein Release-Train.
Unterstützenden Kontext hinzufügen
Optionale Dateien und eine strukturierte Spezifikation. Fügen Sie Material hinzu, das speziell zu dieser Aufgabe gehört – ein Ticket, ein Entwurfsdokument, ein Stack-Trace.
Für Informationen, die für das gesamte Projekt dauerhaft gültig sind, verwenden Sie Projektkontext stattdessen, damit die Angaben für alles gelten und nicht jedes Mal neu angehängt werden müssen.
Starten der Aufgabe
Plan erstellen und starten erstellt den Plan aus Ihrer Beschreibung und beginnt umgehend mit der Planung.