G-KI/Agenten-Fähigkeiten

Spike-Aufgabe

Beantworte eine Frage gut genug, um eine Entscheidung zu treffen – innerhalb des Zeitfensters des Spikes. Das Ergebnis ist ein Entscheidungsnachweis, kein zusammengeführter Code.

Eingabe

$ARGUMENTS

• Ticket, erforderlich: ein Trackerschlüssel (z. B. ENG-130) oder eine lokale ID (z. B. T-03) eines Tickets mit dem Typ spike. Falls es sich nicht um einen Spike handelt, brich ab und verweise auf /implement-task.
• --tasks <datei>: die lokale Aufgabendatei. Wenn nicht angegeben, suche die *.tasks.md-Datei, die das Ticket enthält, im lokalen, git-ignorierten RFC-Ordner des Projekts (z. B. .rfcs/), dann in docs/rfcs/.
• --branch <name>: Branchname für einen Prototypen, falls einer benötigt wird. Andernfalls <benutzername>/<projekt-slug>/spike-<aufgaben-branch>, nach derselben Namensregel wie bei /implement-task.
• --unattended: von einem Orchestrator gestartet; niemand kann Fragen beantworten. Frage niemals; wenn du fragen würdest, brich ab und erkläre es im Bericht. Arbeite in deinem eigenen Worktree.

Lies das Ticket aus dem Tracker, wenn es veröffentlicht ist (der Tracker ist die Quelle der Wahrheit für seinen Inhalt), andernfalls aus der Aufgabendatei. Lokale RFC- und Aufgabendateien befinden sich nur im Hauptprojektordner: Wenn du dich in einem Worktree befindest, finde ihn mit git worktree list (erster Eintrag) und lies sie dort mit absolutem Pfad. Bearbeite niemals Dateien oder führe Git-Befehle im Hauptordner aus, außer zum Schreiben des Entscheidungsnachweises wie unten beschrieben.

1. Frage eingrenzen

Bevor du etwas sammelst, schreibe auf:

• Die Frage, als einen Satz mit einer Antwort („Kann Postgres LISTEN/NOTIFY 2k Ereignisse/s auf unserer Instanzgröße verarbeiten?“, nicht „Eventing untersuchen“).
• Die Entscheidung, die sie ermöglicht, und welche Tickets davon abhängen.
• Die Optionen, zwischen denen entschieden wird, einschließlich „nichts tun“ oder der einfachsten Option, wenn sie plausibel ist.
• Entscheidungskriterien, möglichst aus dem DRIVE-Abschnitt des RFC (Einschränkungen, Werte, wesentliche Ergebnisse), damit Belege anhand dessen bewertet werden, was das Team bereits als wichtig vereinbart hat.
• Das Zeitfenster aus dem Ticket (Standard: etwa ein Arbeitstag). Erledigt bedeutet, dass die Frage beantwortet ist oder das Zeitfenster abgelaufen ist, je nachdem, was zuerst eintritt.

Wenn das Ticket zu vage ist, um eine Frage zu formulieren, brich ab und melde blocked mit den Fragen, die beantwortet werden müssen.

2. Belege sammeln, günstigste zuerst

Höre auf, sobald die Belege die Frage klären; forsche nicht um der Vollständigkeit willen.

1. Die Codebasis: bestehende Muster, Einschränkungen, frühere Versuche, Kommentare und Historie rund um das Gebiet (git log auf relevanten Pfaden).
2. Primärquellen: offizielle Dokumentationen, Changelogs, Versionshinweise, Issue-Tracker der beteiligten Bibliotheken oder Dienste. Bevorzuge diese gegenüber Blogbeiträgen. Wenn eine deep-research-Fähigkeit verfügbar ist und die Frage breite externe Recherche erfordert, nutze sie.
3. Messen: Wenn Lesen die Frage nicht klären kann (Leistung, Kompatibilität, „verhält sich diese API wirklich so“), baue den kleinstmöglichen Prototyp oder Benchmark, der die Frage beantwortet, auf dem Spike-Branch, ausgehend vom aktuellen Main. Er existiert, um Belege zu liefern: keine Tests über das Nötigste hinaus, keine Verschönerung, und er wird niemals zusammengeführt. Pushe den Branch, damit die Belege reproduzierbar sind, aber eröffne keinen PR.

Halte fest, woher du jedes Wissen hast: gemessen (du hast es ausgeführt), dokumentiert (eine Primärquelle sagt es) oder angenommen (Schlussfolgerung). Zitiere Links und Dateipfade.

3. Entscheiden, was zu empfehlen ist

• Bewerte jede Option anhand der Entscheidungskriterien mithilfe der Belege.
• Empfehle eine Option mit einer Konfidenz: hoch (gemessen oder gut dokumentiert), mittel (dokumentiert, aber nicht in unserem Kontext getestet), niedrig (hauptsächlich Schlussfolgerung).
• Bei niedriger Konfidenz bevorzuge die Option, die am günstigsten rückgängig zu machen ist, und sage, welches Signal dich umstimmen würde.
• Wenn das Zeitfenster abgelaufen ist, bevor die Frage beantwortet wurde, sage es klar: berichte, was bekannt ist, und empfehle den kleinstmöglichen nächsten Schritt (einen engeren Folgespike oder eine reversible Standardentscheidung, um fortzufahren).

4. Backlog-Änderungen vorschlagen

Die Entscheidung ändert normalerweise den Plan. Schlage vor, wende nicht an:

• Tickets zum Hinzufügen, im gleichen Format wie die Aufgabendatei (Titel, Umfang, Dateien, Abnahmekriterien, Abhängigkeiten), jeweils 1 Story-Point.
• Tickets zum Ändern (Umfang, Kriterien oder Abhängigkeiten) und Tickets zum Entfernen, jeweils mit Grund.
• RFC-Abschnitte, die aktualisiert werden müssen.

5. Nachweis erstellen und Bericht

1. Schreibe den Entscheidungsnachweis mit templates/decision.md als <rfc-name>.<ticket-id>.decision.md neben der Aufgabendatei im Hauptprojektordner (die einzige Datei, die du dort schreibst). Es ist eine lokale, nicht versionierte Datei wie das RFC.
2. Wenn das Ticket veröffentlicht ist, poste eine kurze Zusammenfassung im Tracker-Issue: die Frage, die Empfehlung und Konfidenz sowie die wichtigsten Belege in drei bis fünf Zeilen, deutlich gekennzeichnet als vorgeschlagen, ausstehende Genehmigung.
3. Wenn du direkt mit dem Benutzer arbeitest, setze den Ticketstatus in der Aufgabendatei auf decision-proposed, gehe die Empfehlung mit ihm durch und bitte ihn, sie zu genehmigen, eine andere Option zu wählen oder den Spike zu verlängern. Im unbeaufsichtigten Modus überlasse die Status dem Orchestrator.
4. Schließe mit dem Bericht ab:

ERGEBNIS: decision-proposed | inconclusive | blocked
TICKET: <lokale ID> / <Trackerschlüssel oder "unpublished">
NACHWEIS: <absoluter Pfad zum Entscheidungsnachweis>
EMPFEHLUNG: <eine Zeile> (Konfidenz: hoch | mittel | niedrig)
PROTOTYP: <Branch oder "none">
HINWEISE: <Backlog-Änderungen in einer Zeile: +N Tickets, ~N geändert, -N entfernt; oder warum blocked>