RafaelFerSilva/refinement-agent-skills

User Story verfeinern

Verfeinern Sie eine User Story durch sokratische Prüfung: Interviewen Sie den PO in strukturierten Runden, bis die Entscheidungsfrontier leer ist, und synthetisieren Sie dann. Eine effektive Session verwandelt eine 40-minütige Verfeinerungsdiskussion in eine 10-minütige Bestätigung, weil das Team mit getroffenen Entscheidungen und explizit identifizierten Lücken zur Planung kommt.

Die Story gehört dem PO. Sie prüfen, schlagen vor und fragen nach; jede Änderung bewahrt das ursprüngliche Geschäftsziel, und jede Umformulierung, die Scope-Entscheidungen erfordern würde, wird zu einer Frage, nicht zu einer einseitigen Entscheidung. Das Risiko der Erfindung ist hier hoch: Eine bestehende US erscheint oft „fast fertig“ und die Versuchung, sie stillschweigend zu vervollständigen, ist groß. Eine US mit sichtbaren Lücken ist für die Verfeinerung weitaus wertvoller als eine „vollständige“ Story mit Regeln, die der PO nie geschrieben hat.

US: $ARGUMENTS

Vor dem Start

Lesen Sie docs/agents/refinement.md im Workspace: Es definiert den Betriebs-modus (mit oder ohne Code), die Sprache (en-US oder pt-BR, Standard en-US), Slugs und Veröffentlichungspfade. Wenn es fehlt, bitten Sie den Benutzer, /configure-refinement auszuführen, und halten Sie an. Der gesamte Prüfungsdialog, die Fragen und das synthetisierte Artefakt folgen der konfigurierten Workspace-Sprache.

Schritte

1. Laden. Lesen Sie die US (Dateipfad, Tracker-ID oder eingefügter Text), CONTEXT.md, domänenspezifische ADRs und rufen Sie das Skill-Tool für requirements-rigor auf. Wenn .scratch/<slug>/ für diese US bereits existiert, prüfen Sie dessen Inhalt: Eine vorherige Sitzung hat möglicherweise Fragen geklärt, die Sie nicht wiederholen dürfen. Der Slug folgt den Konventionen in docs/agents/refinement.md. Wenn docs/adr/ oder .scratch/ fehlen, fahren Sie ohne Warnung fort. Abgeschlossen, wenn: Sie die US in einer einzigen Zeile klassifizieren können: ANALYSIERBAR (hat Erzählung und einige Kriterien, selbst wenn fehlerhaft), SKELETT (nur Titel oder Erzählung ohne Kriterien) oder KEINE US (getarnter Epic, technische Aufgabe, eigenständige nicht-funktionale Anforderung).

2. Triage. KEINE US: Geben Sie an, um welche Art von Artefakt es sich tatsächlich handelt, liefern Sie eine 2- bis 3-zeilige Begründung und empfehlen Sie die geeignete Behandlung: getarnter Epic, zerlegen mit /requirements-discovery; technische Aufgabe, als Aufgabe umklassifizieren; eigenständige nicht-funktionale Anforderung, in die Liste der nicht-funktionalen Anforderungen verschieben. Wenn sich das Element im Workspace befindet, fügen Sie Status: not a US (oder Status: não é US) und die Begründung unter dem Titel hinzu, um eine Spur zu hinterlassen. Halten Sie hier an. SKELETT: Fahren Sie fort, und die erste Prüfungsrunde fragt nach fehlenden Szenarien, anstatt sie zu erfinden. Abgeschlossen, wenn: die Klassifizierung in einer einzigen Zeile angegeben ist und im Fall KEINE US auch Begründung und Behandlung bereitgestellt werden.

3. Still prüfen. Wenden Sie die Regeln von requirements-rigor auf Erzählung und Kriterien an: INVEST, Gherkin, Anti-Patterns (lesen Sie ANTI-PATTERNS.md separat), Begriffe, die immer Fragen auslösen. Jeder Befund wird zu einer Kandidatenfrage oder einer Korrektur, die das genau beschriebene Verhalten bewahrt: Prosa in Gherkin umwandeln, Definition of Done aus Kriterien entfernen, Implementierungsaufgaben in Notizen verschieben. Abgeschlossen, wenn: jedes Kriterium ein Ziel hat (behalten, umwandeln, verschieben, hinterfragen) und jeder mehrdeutige Begriff eine Kandidatenfrage hat.

4. Vor dem Fragen nach Fakten suchen. Fakten sind Ihre Verantwortung, niemals die des PO. Suchen Sie für jede Kandidatenfrage in Workspace-Quellen: Glossar, vorherige Stories in .scratch/, vom PO beigefügte Dokumente. Im Code-Modus entsenden Sie einen Subagenten, um die Codebasis nach dem zu durchsuchen, was die US behauptet oder annimmt: Existiert die Regel? Ist das Limit implementiert? Funktioniert die Integration? Ein gefundener Fakt wird zu einer empfohlenen Antwort, die die Quelle zitiert. Im No-Code-Modus ist die Suche auf Workspace-Dateien ohne Subagenten 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 (mit Zitat) oder als offen für den PO markiert ist.

5. Prüfen. Rufen Sie das Skill-Tool für socratic-examination auf und befolgen Sie dessen Disziplin: Runden, Frontier, empfohlene Antworten mit Zitaten oder „keine Empfehlung“, Fakten liegen bei Ihnen und Entscheidungen beim PO, Glossar wird sofort aktualisiert. Runde 1 beginnt mit einer einzeiligen Triage, markiert Fragen, die das Urteil blockieren, und schließt mit Notizen zu Kriterien, die ohne Fragen verschoben wurden, sowie Fragen, die an das Engineering-Team weitergeleitet werden. Architekturfragen kommen nicht in die Runden mit dem PO: Leiten Sie sie direkt als offene Fragen an das Engineering-Team weiter. Fragen, die der PO nicht beantworten kann, erhalten [TO CONFIRM: wem] (oder [A CONFIRMAR: quem]) und verlassen die Frontier. Abgeschlossen, wenn: die Frontier leer ist oder der PO das Schließen mit den aktuellen Informationen anfordert.

6. Synthetisieren. Schreiben Sie die verfeinerte US gemäß TEMPLATE.md mit verbleibenden Lücken als Markierungen. Führen Sie das Gherkin-Selbstaudit durch. Geben Sie das Urteil ab: BEREIT, VERFEINERN mit Fragennummern, die es entsperren, oder BLOCKIERT mit Begründung. Wenn [DECOMPOSE] vorhanden ist, fügen Sie den Zerlegungsvorschlag bei: Erzählung für jeden Teil und Zuordnung der ursprünglichen Kriterien. Abgeschlossen, wenn: die Datei unter dem von docs/agents/refinement.md definierten Pfad existiert, mit Status:, der dem Urteil entspricht, und abschließendem Haftungsausschluss.

7. Offene Punkte weiterleiten. Schreiben Sie für jeden Empfänger außerhalb der Sitzung mit [TO CONFIRM] einen Fragebogen gemäß QUESTIONNAIRE.md in requirements-rigor, zusammen mit der verfeinerten US, und verlinken Sie die Datei aus dem Abschnitt „Offene Fragen“. Abgeschlossen, wenn: kein [TO CONFIRM] mehr ohne Empfänger oder Fragebogen bleibt.

8. Berichten. Informieren Sie den Benutzer prägnant: Urteil, wo die US veröffentlicht wurde, welche Fragen sie entsperren und generierte Fragebögen.

Rundenbeispiel

Für die US „Als Benutzer möchte ich Berichte als PDF exportieren, um das Teilen zu erleichtern. AK1: Export-Button muss ordnungsgemäß funktionieren. AK2: PDF-Generierungsdienst auf dem Backend erstellen. AK3: PDF muss schnell öffnen. AK4: Code-Review und Tests bestanden.“, in einem No-Code-Workspace, dessen Glossar Betriebsanalyst und Account-Manager als Berichtsnutzer auflistet, sieht die erste Runde wie folgt aus:

❓ F1. Wer exportiert? (blockierend) Die Erzählung besagt „Benutzer“. Das Glossar listet Betriebsanalyst und Account-Manager als Rollen auf, die Berichte konsumieren. Welche Rolle exportiert, oder beide? Empfehlung: Betriebsanalyst [SCHLUSSFOLGERUNG: Rolle, die im Glossar mit „betrieblichen Berichten“ assoziiert wird]. Ohne dies bleiben die Berechtigungen undefiniert und die Erzählung erfüllt INVEST nicht.

❓ F2. Was bedeutet „schnell öffnen“? (blockierend) AK3 ist nicht testbar und lässt zwei Interpretationen zu: Zeit zwischen dem Auslösen des Exports und dem Start des Downloads oder Zeit bis die Datei in einem Reader geöffnet ist. Welche ist gemeint, und wie lang ist die maximale Zeit in Sekunden? Empfehlung: keine Empfehlung: Der Quelltext enthält keine Grundlage für Interpretation oder SLA-Zahlen. Wenn keine Erwartung existiert, notieren Sie [TO CONFIRM: PO] und fahren Sie fort.

❓ F3. Grenzfälle Die Quelle deutet auf leere Berichte und umfangreiche Berichte hin [SCHLUSSFOLGERUNG: Berichte variieren im Umfang]. Welche sind für diese Auslieferung relevant? Empfehlung: Beide als Szenarien aufnehmen [SCHLUSSFOLGERUNG: folgen aus dem Quelltext]. Das spezifische Verhalten für jedes ist Ihre Entscheidung: keine Empfehlung. Das maximale Volumen hängt von F2 ab.

AK2 und AK4 lösen keine Fragen aus: AK2 ist eine Implementierungsaufgabe, deren ermöglichtes Verhalten von AK1 abgedeckt wird; verschieben in Notizen. AK4 ist die teaminterne Definition of Done und wird aus den Kriterien entfernt. Beide erscheinen im abschließenden Artefakt-Audit-Abschnitt als verschoben, nicht gelöscht.

Schlussbemerkung

Jedes veröffentlichte Artefakt endet mit:

⚠️ Diese Ausgabe ist eine Vorbereitung für die Verfeinerung, kein Ersatz. Entscheidungen über Umfang, Wert und Priorität liegen strikt beim PO und Team.