EvolveHQ/docflow

brainstorm

Verwandle ein vages Problem in eine strukturierte Menge von Kandidaten-ADRs und Planungselementen. Dieses Skill ist generativ und nur lese-/vorschlagend – es schreibt niemals ADRs oder Planungsdateien direkt. Nach Genehmigung übergibt es jeden Kandidaten an die Skills new-adr und new-plan.

Schritt 0 – Voraussetzungen und Kontext

1. Bestätige, dass das Repository initialisiert ist (oder vermerke, dass die Ausgabe einen frischen Durchlauf des bootstrap-Skills anstoßen kann).
2. Lies CONVENTIONS.md für ADR-Form und Lebenszyklus und überfliege INDEX.md + bestehende ADRs, damit Kandidaten nichts bereits Vorhandenes duplizieren oder widersprechen, und damit Abhängigkeiten auf reale ADRs verweisen.

Schritt 0.5 – Bewertung (zuerst ausführen)

Führe das gemeinsame Bewertungsprotokoll aus, bevor du zerlegst:

• Verwende zuerst bereits gelieferte Antworten. Behandle anwendbare Entscheidungen, die bereits in der Anfrage oder dieser Sitzung geliefert wurden, einschließlich der Tiefe, als beantwortet. Fasse sie zusammen, ohne erneut zu fragen; Standardwerte ersetzen niemals explizite Entscheidungen. Wenn jede wesentliche Entscheidung geliefert wurde, fahre fort. Frage nur nach einer wesentlichen fehlenden oder widersprüchlichen Entscheidung. Eine Repository-Präferenz allein ist keine aktuelle Antwort oder Ausführungsgenehmigung.

• Tiefenauswahl für ungelöste Entscheidungen. Wenn die Tiefe nicht geliefert wurde und Entscheidungen offen bleiben, frage, wie tief diese Bewertung gehen soll: express – jede Entscheidung nimmt ihre empfohlene Voreinstellung; nur Fragen ohne ableitbare Voreinstellung (die freitextlichen Essentials) werden noch gestellt; guided – nur die unten als besonders wichtig markierten Fragen plus die freitextlichen Essentials; full – jede unten stehende Frage. Wenn die CONVENTIONS.md des Repositorys eine Bewertungstiefe: dokumentiert, wähle sie als empfohlene Option vor, wenn du fragst; eine dokumentierte Tiefe wird niemals stillschweigend angewendet. Andernfalls empfehle full, wenn die Anfrage mit wenig oder keinem Kontext eintrifft, und express, wenn sie bereits vollständig spezifiziert ist. Bei jeder Frage kann der Bediener mit „Voreinstellungen ab hier“ oder „gehe tiefer“ antworten; ehre die Umschaltung sofort.

• Stelle die folgenden Fragen einzeln, jede mit einer empfohlenen Option und einer einzeiligen Begründung; warte auf jede Antwort.

• Verwende strukturierte Auswahl (einfach- oder mehrfachauswahl). Wenn der Host ein strukturiertes Einzelfach-/Mehrfachauswahl-Fragewerkzeug bereitstellt, verwende es und markiere die empfohlene Option; andernfalls liste Optionen A/B/C im Klartext auf und nenne die empfohlene. Verwende Freitext nur dort, wo eine aufzählbare Menge unmöglich ist (z. B. die Zielsetzung).

• Der Bediener entscheidet. Gehe niemals an einer Frage vorbei ohne Antwort und rate niemals den Umfang, wenn der Aufruf ohne Kontext erfolgt.

Fragen (überspringe alle, die die Anfrage bereits beantwortet):

1. Ziel / Problem – Freitext (die unvermeidliche offene Antwort; wird bei jeder Tiefe gestellt), falls nicht bereits gegeben.
2. Ausgabe – nur Kandidaten-ADRs oder ADRs + Planungselemente. Empfohlen: ADRs + Planungselemente.
3. Zerlegungstiefe – schnell (Top-Kandidaten) oder gründlich (vollständige Zerlegung). Empfohlen: zuerst schnell, auf Anfrage erweitern.

Hier ist keine Frage als besonders wichtig markiert – ein geführter Durchlauf verhält sich wie express für dieses Skill.

Dieses Skill schreibt nichts, bis du die Gliederung genehmigst.

Schritt 1 – Verstehe das Problem

Frage nach dem Ziel/Feature/Problem, falls nicht gegeben. Erkunde Umfangsgrenzen, Einschränkungen und die regulatorischen/qualitätsrelevanten Anliegen, die für dieses Repository wichtig sind. Beginne nicht mit der Zerlegung, bis das Ziel klar ist.

Schritt 2 – Zerlege

Erstelle eine Kandidatenliste. Für jeden Kandidaten-ADR:

• Vorgeschlagene Nummer (nächste verfügbare, fortlaufend), Arbeitstitel, Form (Fähigkeit vs. Technologie, wenn das Repository dies unterscheidet).
• Einzeiliger Umfang – die einzelne Entscheidung, die er erfasst.
• Abhängigkeiten von anderen Kandidaten oder bestehenden ADRs.

Eine Entscheidung pro ADR. Wenn ein Kandidat mehrere Entscheidungen bündelt, teile ihn auf und erkläre warum. Wenn ein Kandidat eigentlich ein bestehender ADR ist, der überarbeitet werden muss, sage das, anstatt eine neue Nummer vorzuschlagen.

Schritt 3 – Ordne die Arbeit

Schlage eine Planreihenfolge vor (welche plan/todo/-Elemente in welcher Reihenfolge), die die Abhängigkeitskanten respektiert. Vermerke, wo Arbeit parallelisiert werden kann (nützlicher Input für das agent-wave-Skill).

Schritt 4 – Überprüfung und Übergabe

Präsentiere den vollständigen Satz als überprüfbare Gliederung (Kandidaten + Abhängigkeiten + Reihenfolge). Nimm Änderungen an. Schreibe noch nichts. Sobald der Benutzer genehmigt, erstelle sie, indem du das new-adr-Skill pro Kandidat und das new-plan-Skill pro geplantem Element aufrufst – oder übergib die genehmigte Gliederung an diese Skills.

Schutzmaßnahme: Wenn das Problem zu vage ist, um es zu zerlegen, ohne Anforderungen zu erfinden, sage das und bitte um mehr, anstatt spekulative ADRs zu erstellen.

Nenne vereinbarte Optionen und verbleibende Entscheidungen; Diskussion allein erzeugt keine Artefakte.

Abschlussbericht

Beende jeden Durchlauf, einschließlich blockierter, fehlgeschlagener und gestoppter Durchläufe, mit einem Abschnitt, der genau mit Status auf einen Blick überschrieben ist, der diese drei Bezeichnungen enthält:

• Dieser Durchlauf: nur tatsächlich versuchte Aktionen und ihre Ergebnisse; zitiere die genaue Ausgabe und den Exit-Code jedes Verifikations-Tores, einschließlich Timeouts oder Unterbrechungen.
• Gesamt: implementiert, teilweise verifiziert, verifiziert, blockiert, fehlgeschlagen oder unbekannt. Ein bestandener Unterschritt ist kein Gesamtbestehen; unvollständige oder fehlende Beweise werden niemals zum Erfolg.
• Noch zu tun: jede verbleibende Aktion, ungelöste Feststellung, Verifikation, Bereinigung oder erforderliche Eingabe. Schreibe „Keine“ nur, wenn die gesamte Aufgabe nachweislich abgeschlossen ist; unterlasse niemals Arbeit, weil ein Budget zu Ende gegangen ist.

Routine-Fortschrittsmeldungen benötigen keinen Block. Halte die endgültigen Ergebnisse kurz und unterscheide Arbeit, die auf einem PR vorbereitet wurde, von Arbeit, die als ausgeliefert bestätigt wurde.