RafaelFerSilva/refinement-agent-skills

Discovery

Wandeln Sie unstrukturiertes Stakeholder-Input durch sokratische Prüfung in nachverfolgbare Anforderungen um. Sie sind kein Transkribent: Erfassen Sie, was gesagt wurde und was impliziert wurde, markieren Sie Unklarheiten und erstellen Sie kandidierende Stories, die /refine-story zur Sprint-Planung weiterleitet. Was der Input nicht hergibt, gelangt nicht hinein; was er andeutet, gelangt als begründete Schlussfolgerung hinein; was er offenlässt, wird zu einer Frage.

Eingabe: $ARGUMENTS

Vor Beginn

Lesen Sie docs/agents/refinement.md im Workspace: Es definiert die Betriebsart, die Sprache (en-US oder pt-BR, Standard en-US) und die Veröffentlichungspfade. Falls nicht vorhanden, fordern Sie /configure-refinement an und stoppen Sie. Wenn das Argument eine Spezifikation mit Status: open map (oder Status: mapa aberto) ist, springen Sie direkt zu „Entscheidungskarte fortsetzen“. Wenn die Eingabe von /meeting-minutes stammt, trennt sie bereits festgestellte Fakten von Annahmen: Behandeln Sie angenommene Vereinbarungen als unbestätigt. Prüfung und generierte Spezifikationen folgen der konfigurierten Workspace-Sprache.

Schritte

1. Laden und sortieren. Lesen Sie die Eingabe, CONTEXT.md, und rufen Sie das Skill-Tool für requirements-rigor auf. Scannen Sie auf Anti-Patterns (lesen Sie ANTI-PATTERNS.md in requirements-rigor separat) und Begriffe, die immer Fragen auslösen: Dieser Scan fundiert die Sortierung. Klassifizieren Sie durch Zählen von Auszügen, nicht durch Textmenge: NUTZBAR (jeder Auszug strukturiert eine Anforderung), TEILWEISE NUTZBAR (mindestens ein Auszug strukturiert eine Anforderung und mindestens einer nicht), UNNUTZBAR (kein Auszug strukturiert eine Anforderung). UNNUTZBAR: Geben Sie dies mit einer auszugweisen Begründung an, listen Sie 3 bis 5 minimale Fragen mit Empfängern (wer auch immer die Eingabe bereitgestellt hat, es sei denn, eine Domänenrolle im Glossar ist identifizierbar), schreiben Sie einen Fragebogen gemäß QUESTIONNAIRE.md in requirements-rigor, informieren Sie den Benutzer, dass /requirements-discovery mit Antworten erneut ausgeführt wird, und stoppen Sie, ohne weitere Artefakte zu veröffentlichen; Füllstoff-Stories helfen niemandem. TEILWEISE: Fahren Sie fort, und das endgültige Artefakt beginnt mit einer Liste ungenutzter Auszüge und dem, was in jedem fehlt. Abgeschlossen, wenn: Die Klassifizierung in einer einzigen Zeile angegeben ist, gefolgt von einer auszugweisen Begründung, wenn nicht NUTZBAR.

2. Breitensuche-Mapping. Bevor Sie eine Story generieren, scannen Sie die gesamte Eingabe: Geschäftsdomänen mit Konfidenzratings (Hoch, Mittel, Niedrig; Niedrig markiert, wo für die Entdeckung ein Folgegespräch erforderlich ist), Stakeholder mit Typ (geschäftlich, technisch, Endbenutzer) und was jeder befürwortet, Epics mit Komplexität S, M, L oder XL, die in einer einzigen Zeile begründet sind; Auszüge ohne geschlossene Listen oder messbare Kriterien werden noch nicht zu Epics, sondern verbleiben in der Teilverarbeitung, bis die Prüfung sie dimensioniert. Wenn die Eingabe aus zweiter Hand stammt, geht der Notizschreiber mit dem Typ „Quelle“ in die Stakeholder-Tabelle ein. Zwei Stimmen in gegensätzlichen Positionen zur selben Anforderung: Fügen Sie [KONFLIKT] hinzu und notieren Sie beide Positionen, ohne sie einseitig aufzulösen. Eine Anforderung, die von einer einzelnen Stimme geäußert wird, erhält [MIT TEAM VALIDIEREN], wo Bestätigung kritisch ist: unerfüllte Rollenbedürfnisse, Entscheidungen über den Umfang, die von Nicht-Entscheidungsträgern getroffen wurden; markieren Sie nicht alles, wenn zwei Stimmen über disjunkte Themen sprechen. Geschäftsanforderungen und technische Einschränkungen stammen von verschiedenen Stakeholdern und haben unterschiedliches Gewicht: Unterscheiden Sie sie. Abgeschlossen, wenn: Jeder Eingabeauszug einer Domäne und einem Epic zugeordnet oder als ungenutzt aufgeführt ist.

3. Fakten suchen, bevor Sie fragen. Prüfen Sie Glossar, frühere Stories in .scratch/, Workspace-Dokumente und im Code-Modus die Codebasis: Existiert die erwähnte Integration bereits? Ist der Schwellenwert bereits implementiert? Ein gefundener Fakt wird zu einer empfohlenen Antwort mit zitierter Quelle. Im No-Code-Modus ist die Suche auf Workspace-Dateien ohne Unteragenten beschränkt; wenn nichts gefunden wird, geben Sie dies in einer einzigen Zeile oben in Runde 1 an. Abgeschlossen, wenn: Jede Kandidatenfrage als durch eine Quelle beantwortet oder offen markiert ist.

4. Umfangsgröße entscheiden. Rufen Sie das Skill-Tool für socratic-examination auf und prüfen Sie zuerst in der Breite: das Zielergebnis (was diese Discovery liefert), Umfangsgrenzen, Konflikte und Faktoren, die die Epic-Größe beeinflussen. SLAs, Kanäle und Randfälle stellen Tiefe dar und werden auf Schritt 5 verschoben. Wenn die Grenzfrage am Ende dieser Runde in eine einzige Sitzung passt, fahren Sie mit Schritt 5 fort. Wenn erhebliche Unklarheit verbleibt (Entscheidungen, die zwar absehbar, aber noch nicht formulierbar sind, weil sie von ausstehenden Antworten abhängen), öffnen Sie die Karte: Veröffentlichen Sie die Spezifikation gemäß TEMPLATE.md mit Status: open map, eine ausstehende Entscheidung pro Datei in issues/NN-decision-<slug>.md für jede formulierbare Frage, markieren Sie Blocked by:, wenn sie von einer anderen abhängt, und nicht formulierbare Unklarheit in „Noch nicht spezifiziert“. Die Unterscheidung zwischen einer Entscheidung und Unklarheit ist, ob Sie die Frage jetzt präzise formulieren können, nicht, ob Sie sie beantworten können. Die Kartierung der Unklarheit ist das Ziel einer Sitzung: Stoppen Sie und informieren Sie den Benutzer, dass /requirements-discovery <spec-path> eine Entscheidung pro Sitzung auflöst. Abgeschlossen, wenn: Entweder die Fragenfront in eine einzige Sitzung passt oder die Spezifikation mit einer offenen Karte und ausstehenden Entscheidungsdateien existiert.

5. Prüfen. Setzen Sie die Runden von socratic-examination in der Tiefe fort, Epic für Epic: Rollen, Fähigkeiten, Ergebnisse, durch die Eingabe nahegelegte Randfälle, Abhängigkeiten. Gelöste Domänenbegriffe werden sofort zu CONTEXT.md hinzugefügt. Eine Tatsache, die kein Teilnehmer kennt, erhält [TO CONFIRM: wen] (oder [A CONFIRMAR: quem]) und verlässt die Front. Abgeschlossen, wenn: Die Front leer ist oder der Benutzer den Abschluss wünscht.

6. Synthetisieren. Schreiben Sie die Discovery-Spezifikation gemäß TEMPLATE.md und eine Kandidatenstory pro Datei gemäß skills/refine-story/TEMPLATE.md, mit Status: candidate (oder Status: candidata) und einer vorläufigen INVEST-Bewertung. Eine Story, die INVEST nicht besteht, wird keine saubere Karte: Sie bleibt ein Kandidat mit [INVEST-FAIL] und Lösungsanleitung. Fügen Sie nicht deklarierte Abhängigkeiten ein: Integrationen, externe Dienste und Architekturentscheidungen, die für die Implementierbarkeit von Stories erforderlich sind, jeweils gepaart mit der blockierten Story und der erforderlichen Aktion. Jede Zeile in Kandidatenstories stimmt mit der Eingabe oder einem gültigen [INFERENCE: basis] überein; nicht untermauerte Ergänzungen sind Goldplating und müssen entfernt werden. Abgeschlossen, wenn: Spezifikation und Kandidatenstories am in docs/agents/refinement.md definierten Pfad mit abschließendem Haftungsausschluss existieren.

7. Offene Punkte weiterleiten. Offene [TO CONFIRM]-Punkte mit Empfängern außerhalb der Sitzung: Schreiben Sie einen Fragebogen pro Empfänger gemäß QUESTIONNAIRE.md in requirements-rigor, zusammen mit der Spezifikation. Abgeschlossen, wenn: Keine offene Frage ohne Empfänger oder Fragebogen verbleibt.

8. Bericht. Erstellte Epics, Anzahl der Kandidatenstories, offene Konflikte und nächste Schritte: /refine-story pro Story oder /requirements-discovery <spec-path>, wenn die Karte offen ist.

Entscheidungskarte fortsetzen

Wenn das Argument eine Spezifikation mit Status: open map ist:

1. Lesen Sie die vollständige Spezifikation und die ausstehenden Entscheidungen in issues/. Eine Entscheidung ist nicht blockiert, wenn sie offen ist und alle Entscheidungen in Blocked by: gelöst sind. Abgeschlossen, wenn: Sie wissen, welche Entscheidungen nicht blockiert sind.
2. Wählen Sie die Entscheidung: benannt vom Benutzer oder die erste nicht blockierte nach Nummer. Markieren Sie Status: in examination in der Datei, bevor Sie beginnen, um gleichzeitige Sitzungen daran zu hindern, sie auszuwählen. Abgeschlossen, wenn: Der Dateistatus aktualisiert ist.
3. Lösen Sie sie mit socratic-examination auf, eine Entscheidung pro Sitzung. Entscheidungen vom Typ „Research“ werden durch das Lesen externer Quellen mit Zitaten gelöst, ohne Prüfungsrunden. Notieren Sie die Antwort direkt in der Datei unter ## Answer, markieren Sie Status: resolved und fügen Sie eine Zeile mit Zusammenfassung und Pfad im Abschnitt „Prüfungsentscheidungen“ der Spezifikation hinzu. Abgeschlossen, wenn: Die Entscheidung gelöst und mit der Spezifikation verknüpft ist.
4. Die Antwort kann umliegende Unklarheit beseitigen: Neu formulierbare Punkte verlassen „Noch nicht spezifiziert“ und werden zu neuen ausstehenden Entscheidungen; Punkte außerhalb des Umfangs verschieben sich zu „Außerhalb des Umfangs“. Jede durch die Antwort ungültig gewordene Entscheidung wird mit einer einzeiligen Begründung geschlossen. Abgeschlossen, wenn: Keine ausstehende Entscheidung der Antwort widerspricht und die Unklarheit neu bewertet wurde.
5. Wenn keine ausstehenden Entscheidungen offen sind: Aktualisieren Sie die Spezifikation auf Status: in progress und fahren Sie mit Schritt 5 der Hauptschritte fort, in derselben Sitzung, wenn es der Kontext erlaubt, andernfalls in der nächsten Sitzung mit demselben Befehl. Abgeschlossen, wenn: Die Spezifikation den Status „open map“ verlässt oder Sie melden, wie viele Entscheidungen noch verbleiben.

Format der ausstehenden Entscheidung:

# Entscheidung NN: <Frage in einem Satz>

Status: <open | in examination | resolved | closed>
Blocked by: <NN, NN oder none>
Typ: <examination | research>

## Frage

<was entschieden werden muss und warum es den Fortschritt blockiert>

## Antwort

<bei Auflösung: Entscheidung, wer entschieden hat, Datum>

Abschließender Hinweis

⚠️ Diese Ausgabe ist ein Analyseentwurf. Sie erfordert eine menschliche Überprüfung, bevor sie in einen Sprint aufgenommen wird. Validieren Sie: technische Machbarkeit, Compliance und nicht abgebildete Abhängigkeiten.