Agents-On-Rails/skills

/aor-req — Anforderungserstellung

Erstellt UN, PR und SR nach EARS-12-Mustern, INCOSE C1-C9 Qualitätsattributen und kanonischer Kreuzreferenz-Syntax. Die Ausgabe erfolgt in Markdown.

Hinweis zu Skills vs. Agenten. Das AOR-Bundle enthält Skills unter .claude/skills/aor-*/SKILL.md (direkt aufrufbar, wie dieser hier) und SME-Agenten unter .claude/agents/aor-sme-*.md (Sub-Agenten-System-Prompts, die nur durch aor-review / aor-review-adhoc gestartet werden). Rufen Sie einen Agenten NICHT als Skill auf — dies führt zu einem Fehler „Skill nicht gefunden".

Betriebsdisziplin

Durchgehend anwenden. Geben Sie jede Disziplin beim Start an, damit der Benutzer sie sieht.

• Modus (beim Start deklariert): Fragen, ob es sich um eine explorative Sitzung (einzelne Anforderung, konversationell, keine Dateien) oder eine Dokumenten-Sitzung (vollständige Spezifikationserstellung, Dateien werden geschrieben) handelt. Standardmäßig explorativ, wenn der Umfang als Inline-Text ohne Dateipfad eingeht, andernfalls Dokument. Der Modus steuert, ob die Schritte 5–7 auf die Festplatte schreiben.
• Aufrufbestätigung: Die erste Antwort des Skills gibt an: „Wird als aor-req im -Modus ausgeführt. Dateien werden nach geschrieben, sofern Sie nichts anderes angeben." Beseitigt die Unklarheit „Wurde der Skill tatsächlich ausgeführt?".
• Q&A-Disziplin: Stellen Sie jeweils eine klärende Frage. Warten Sie auf die Antwort des Benutzers, bevor Sie die nächste Frage stellen. Stapeln Sie keine Fragen. Ein einzelner AskUserQuestion-Aufruf, der eine Entscheidung mit mehreren Alternativen präsentiert (z. B. ein Multiple-Choice-Menü), ist eine Frage; die Präsentation von zwei nicht zusammenhängenden Entscheidungen in einem Aufruf ist Stapeln.
• Fehleroffenlegung: Wenn ein vorgeschriebener Schritt nicht abgeschlossen werden kann (Dateischreibvorgang blockiert, Sub-Agenten-Aufruf fehlgeschlagen, Referenzdatei nicht verfügbar, teilweise Fertigstellung, Zeitüberschreitung, Berechtigung verweigert), geben Sie dies im Chat an. Nach der Offenlegung anhalten und fragen, ob Wiederholung, Rückgriff auf die offengelegte manuelle Nachbildung oder Abbruch gewünscht wird — nicht stillschweigend fortfahren. Bei eindeutig transienten Fehlern (z. B. Netzwerk-Zeitüberschreitung) ist vor der obligatorischen Offenlegung ein Wiederholungsversuch zulässig.

Arbeitsablauf

Schritt 1: Umfang festlegen

Wenn der Benutzer Umfangstext oder einen Dateipfad übergeben hat, diesen verwenden. Andernfalls über AskUserQuestion fragen: „Welche Funktionen oder Änderungen sollen spezifiziert werden?"

Unterscheidung von Umfangstext und Dateipfad (REQ-B): Die Eingabe als Pfad behandeln, wenn eines der folgenden Kriterien zutrifft: (a) sie enthält / oder \, (b) sie endet auf .md / .txt / .xlsx / .csv / .docx oder (c) sie wird über Read() in eine vorhandene Datei im Dateisystem aufgelöst. Andernfalls als Umfangstext behandeln — einschließlich mehrwortiger Beschreibungen wie „Patiententerminbuchungssystem".

Entscheidungsregel: Wenn nur Regel (c) zutrifft (kein / oder \, keine erkannte Erweiterung, aber Read() wird erfolgreich aufgelöst) UND die Eingabe ein einzelnes Wort ist, mit dem Benutzer bestätigen, bevor sie als Pfad behandelt wird: „Ich sehe, dass eine Datei namens <Eingabe> existiert. Meinten Sie diese Datei oder ist das eine Umfangsbeschreibung?"

Bei Eingaben aus Excel wird erwartet, dass das Host-LLM Zeilen in einen Arbeits-Markdown-Puffer transkribiert hat, bevor dieser Skill ausgeführt wird (das Bundle analysiert Excel nicht direkt).

Schritt 1a: Die Ebene klassifizieren

Im explorativen Modus fragen:

„Handelt es sich um einen User Need (UN), ein Product Requirement (PR) oder ein Software Requirement (SR)?"

Nicht benötigte Schritte überspringen, sobald die Ebene bekannt ist: UN-Überprüfung benötigt Schritt 2; PR-Überprüfung benötigt Schritt 3 + Echo-Gate; SR-Überprüfung benötigt die Schritte 4–6.

Mehrstufige Eingabe im explorativen Modus: Wenn der Benutzer einen UN+PR+SR-Satz (oder eine beliebige Kombination mehrerer Ebenen) anstelle einer einzelnen Auswahl bereitstellt, als mehrstufige Überprüfung behandeln — die Schritte 2–4 der Reihe nach für die bereitgestellten Ebenen durchlaufen, aber die explorative Dateischreibdisziplin beibehalten (keine automatischen Datenträgerschreibvorgänge; Ergebnisse inline darstellen).

Im Dokumentmodus standardmäßig alle drei Ebenen (UN → PR → SR) in den Schritten 2–4 durchlaufen, sofern der Benutzer nichts anderes angibt.

Schritt 2: User Needs schreiben (UN-NNN)

Für jeden eindeutigen Stakeholder-Bedarf einen UN schreiben. Regeln:

• Technologieunabhängig, aus Stakeholder-Sicht formuliert
• Reine Erzählung (KEINE EARS-Syntax)
• Problemstellung (2-3 Sätze) + Bedarfsaussage enthalten
• Eine Persona über traces_to::UN->Persona [<Persona-ID>] taggen
• Priorität: Kritisch | Hoch | Mittel | Niedrig

Siehe templates.md für das Format.

Schritt 3: Product Requirements schreiben (PR-NNN)

Für jeden UN PRs ableiten:

• Technologieunabhängig, messbar, objektiv
• EARS-Syntax (siehe ears-guide.md für die 12 Muster)
• Jedes PR rückwärts verfolgen: derived_from::PR->UN [UN-NNN]
• Jedes PR vorwärts verfolgen: traces_to::PR->SR [SR-NNN]
• Jedes Happy-Path-PR muss mindestens einen Wenn/Dann (Ungewolltes)-PR-Begleiter haben
• Dieselbe Wenn/Dann-Begleiterregel gilt auf SR-Ebene in Schritt 4 — jedes Happy-Path-SR muss einen Wenn/Dann-SR-Begleiter haben, der die implementierungsspezifische Wiederherstellung spezifiziert
• Jedes EARS-N (negativ/„darf nicht")-PR muss mindestens einen positiven Begleiter-PR (Ubiquitous, Event-Driven oder State-Driven) haben, der das erwartete korrekte Verhalten spezifiziert; dieselbe Regel gilt auf SR-Ebene

„Happy-Path" definiert (REQ-E): Ein PR ist ein Happy-Path, wenn es eines der positiven EARS-Muster verwendet — Ubiquitous, Event-Driven, State-Driven, Optional, Complex, EARS-E, EARS-T, EARS-P. Ausgeschlossen: Unerwünschtes Verhalten, EARS-N (negativ/„darf nicht"), EARS-F (Fehlermodus deklarativ).

Führen Sie für jeden UN eine Adversarial Error Decomposition durch:

1. Wie schlägt es still fehl?
2. Wie schlägt es laut fehl?
3. Wie schlägt es unter Last fehl?
4. Wie schlägt es unter böswilligen Angriffen fehl?
5. Wie schlägt es im Laufe der Zeit fehl?

Jeder Fehlermodus wird entweder zu einem EARS Wenn/Dann PR (mit [ADV] im Titel versehen; die Kennung bleibt kanonisch, z. B. PR-007 [ADV]) oder zu einem Hinweis für ein separates Risikoregister.

Ausgearbeitetes Beispiel. UN: „Jede hochgeladene Datei bewahren". Fehlermodus: „schlägt still fehl, wenn der freie Speicherplatz auf der Festplatte erschöpft ist". Resultierendes PR:

### PR-007 [ADV]: Upload bei hohem Festplattendruck ablehnen
Wenn der freie Festplattenspeicher unter 5 % fällt, dann soll das System neue
Uploads mit HTTP 507 Insufficient Storage ablehnen und einen Retry-After-Header
zurückgeben.
derived_from::PR->UN [UN-001]
traces_to::PR->SR [SR-014]

Beachten Sie, dass der Fehlermodus konkret und quantifiziert ist (5 %, HTTP 507, Retry-After) — genau das macht das PR verifizierbar (C7).

Schritt 4: Software Requirements schreiben (SR-NNN)

Für jedes PR SRs ableiten:

• Implementierungsspezifisch: Dienste, APIs, Datenbanken, Fehlercodes benennen
• EARS-Syntax mit spezifischen Komponentennamen
• Jedes SR rückwärts verfolgen: derived_from::SR->PR [PR-NNN]
• Jedes SR vorwärts verfolgen: traces_to::SR->TC [TC-NNN]
• Klauselgranularität verwenden (SR-NNN.c1, .c2), um verwandte Verhaltensweisen unter einer einzigen SR-ID zu konsolidieren
• Jedes Happy-Path-SR muss mindestens einen Wenn/Dann (Ungewolltes)-SR-Begleiter haben (siehe Schritt 3 für die Definition von „Happy-Path")
• Jedes EARS-N-SR muss mindestens einen positiven Begleiter-SR haben

Schritt 5: Feldspezifikationstabellen

Für Funktionen mit Dateneingabe/-anzeige Feldspezifikationstabellen im SR-Abschnitt hinzufügen:

Feld-ID	Name	Label	Typ	Min	Max	Einheit	Standard	Erforderlich	UI-Exposition	Validierungsregel	Fehlermeldung	Übergeordnetes SR

UI-Expositionswerte: editable | display-only | hidden.

Schritt 6: Echo-Gate

Für jede SR-Klausel eine einzeilige testbare Behauptung schreiben:

VERIFY: [SR-NNN.c1] — [Neufassung der Anforderung als testbare Behauptung]

Wenn die Behauptung nicht geschrieben werden kann, ist die Anforderung nicht testbar — sie umschreiben.

Schritt 7: Vollständigkeitsprüfung

Die Checkliste in completeness.md durchführen, bevor die Erstellung als abgeschlossen erklärt wird.

Verarbeitung großer Eingaben

Wenn die Eingabe ~200 Quellelemente überschreitet (z. B. eine große Excel-Einfügung):

1. In Batches von 50 Zeilen aufteilen.
2. Für jeden Batch: a. Den Batch lesen. b. Gemäß den obigen Schritten in Markdown UN/PR/SR transkribieren. c. An die Arbeitsdatei anhängen (nicht überschreiben). d. Fortschritt melden: „Batch von abgeschlossen; Anforderungen erstellt."
3. Nach allen Batches die Vollständigkeitsprüfung für die gesamte Datei durchführen.

Wenn ein Batch mehrdeutige Eingaben enthält, anhalten und vor dem Fortfahren um Klärung bitten — Zeilen nicht stillschweigend überspringen.

Ausgabepfade

Standard: ./requirements/SPECIFICATION.md für die konsolidierte UN/PR/SR. Der Benutzer kann dies überschreiben.

Beim Aktualisieren einer vorhandenen Datei vorhandene IDs beibehalten — neue IDs mit der nächsten fortlaufenden Nummer anhängen.

Kreuzreferenz-Syntax (Spickzettel)

beziehungstyp::QUELLE->ZIEL [ID-Liste]

Typ	Richtung	Verwendung
traces_to	vorwärts	UN→PR, PR→SR, SR→TC, UN→Persona
derived_from	rückwärts	PR→UN, SR→PR, TC→SR
validates	Verifikation	TC→SR
mitigates	Risikokontrolle	SR→RISIKO
conflicts_with	Widerspruch	beliebig→beliebig

Kennungsformat

Regex: ^(UN|PR|SR|TC)-\d{3}(\.[A-Z])?$

• Basis-IDs: UN-001, PR-001, SR-001
• Unter-IDs (EARS-P tabellarisch): PR-010.A, PR-010.B
• Klauselnotation: SR-001.c1, SR-001.c2

Referenzdateien

• ears-guide.md — die 12 EARS-Muster
• templates.md — Markdown-Vorlagen für UN/PR/SR-Abschnitte
• completeness.md — Exit-Checkliste (UN→PR→SR-Abdeckung)