Anforderungs-Klärung & Aufgaben-Triage (Grow / Change / Improve)
Ein-Satz-Haken: Leg nicht los – bevor du loslegst, beantworte die drei Fragen: „Was will der Nutzer wirklich?“, „Wie komplex ist es?“ und „Wo fängst du an?“.
Es ist die „Triage-Station“ – ohne Domänenvorgabe, ohne Ausführung. Vage Ideen werden zu strukturierten Anforderungen, Aufgabenberge werden zu einer priorisierten Ausführungsreihenfolge und bestehende Lösungen werden zu einer Liste von Verbesserungspunkten. Und dann wird klar auf den nächsten zu verwendenden Skill verwiesen, ohne dass der Skill selbst die Arbeit übernimmt.
Dieser Skill ist ein Router und leitet die Anfrage je nach Benutzerproblem an einen der drei Sub-Skills weiter:
growme-mode– Anforderungs-Klärung („Hilf mir nachzudenken“)change-mode– Aufgaben-Triage („Was mach ich zuerst?“)improve-mode– Struktur-Optimierung („Wie verbessere ich es?“)
Kernpositionierung
Jede Anfrage, bei der „nicht ganz klar ist, wo man anfangen soll“, wird zunächst durch diesen Skill geleitet. Drei Aktionen:
- Klärung (growme): Vage Ideen in ausführbare Anforderungen umwandeln
- Triage (change): Aufgabenberge in eine Ausführungsreihenfolge bringen
- Verbesserung (improve): Bestehende Lösungen in eine optimierbare Liste umwandeln
Beantworte die drei grundlegenden Fragen des Benutzers:
- Was willst du wirklich? (growme liefert „Anforderungsspezifikation“)
- Wo soll ich anfangen? (change liefert „Ausführungsreihenfolge“)
- Ist das so richtig? (improve liefert „Verbesserungspunkte“)
Routing-Zuordnungsregeln
Nach Eingang der Benutzereingabe bestimmen, welcher Modus zutrifft (Mehrfachauswahl möglich, serielle Verkettung möglich):
| Benutzermerkmal | Modus | Beispiel | Weiterleitung an |
|---|---|---|---|
| Ergebnis genannt, aber Weg unklar | growme | „Ich möchte einen KI-Lehr-Skill erstellen“ | growme-mode |
| Mehrere Aufgaben, die sortiert oder ausgewählt werden müssen | change | „Ich habe 8 Skills zu verfeinern“ | change-mode |
| Vorhandene Lösung, aber nicht sicher ob optimal | improve | „Schau dir diese SKILL.md an, ist sie richtig?“ | improve-mode |
Entscheidungsprinzipien:
- Die meisten Anfragen beginnen mit growme (Klärung), dann entscheiden, ob change / improve seriell angehängt werden
- Serielle Reihenfolge: growme → change → improve (zuerst klären was gewünscht ist, dann sortieren, dann die Lösung prüfen)
- Der Benutzer wird explizit über den aktuell erkannten Modus informiert, damit er bestätigen oder korrigieren kann
- Wenn keine Triage nötig ist, direkt „Nicht nötig“ sagen; den Skill nicht um der Nutzung willen einsetzen
- Innerhalb einer Konversation können mehrere Modi vorkommen – bei Bedarf seriell aufrufen
Nicht zurück zu sich selbst routen: Nach der Triage muss zwingend auf einen anderen ausführenden Skill verwiesen werden. Es ist nicht erlaubt, nach „A“ erneut requirement-clarifier zur Klärung zu verwenden.
Auslöseszenarien
Starke Auslöser (direkter Aufruf):
- „Hilf mir nachdenken / Wie mache ich das / Ich hab eine Idee“ → growme-mode
- „Wie sortiere ich diese Aufgaben / Was mach ich zuerst / Welche Implementierungswege gibt es / Hilf mir bei der Triage“ → change-mode
- „Wie optimiere ich / Welche Probleme gibt es noch / Schau dir diesen Plan an / Prüf das“ → improve-mode
Schwache Auslöser (unsichere Semantik im Kontext):
- Ein-Satz-Anforderung ohne Abnahmekriterien
- Aufgabenstapel ohne Abhängigkeitsbeziehungen genannt
- Vorhandene Lösung + Benutzer äußert „Irgendwas stimmt nicht“
- Teammitglieder beschreiben dasselbe Ziel unterschiedlich
Keine Auslöser (klare Grenzen):
- Informationen sind bereits vollständig klar → Leg direkt los, den Skill nicht um der Nutzung willen einsetzen
- Einzelne klare kleine Frage („Wie benutze ich X“) → Direkt mit
AskUserQuestionfragen - Bereits domänenspezifisches Problem („Wie schreibe ich einen Frontend-Button“) → An
frontend-design/ui-ux-pro-maxusw. weiterleiten - Reine Schreib-/Übersetzungs-/Generierungsaufgabe → An
original-writing/humanizer/content-rewriteweiterleiten
Ausgabeformat (Router-Perspektive)
Modusermittlung: growme / change / improve (kombinierbar)
【growme】 → growme-mode laden (Anforderungs-Klärung ausführen)
【change】 → change-mode laden (Aufgaben-Triage ausführen)
【improve】 → improve-mode laden (Struktur-Optimierung ausführen)
Nächster Schritt-Vorschlag: [Konkrete Weiterleitung an XX Skill / Direkt ausführen / Weiter klären]
Dateistruktur (Dieses Paket)
requirement-clarifier/ ← Router (Du bist hier)
├── SKILL.md ← Diese Datei: Routing + Auslöser + Grenzen
├── growme-mode/ ← Sub-Skill 1: Anforderungs-Klärung
│ ├── SKILL.md
│ └── references/
│ ├── seven-dimensions.md ← 7 Nachfragedimensionen
│ ├── ask-question-toolkit.md ← Tipps zur Verwendung von AskUserQuestion
│ └── red-flags.md ← Häufige Beispiele für falsche Klärung
├── change-mode/ ← Sub-Skill 2: Aufgaben-Triage
│ ├── SKILL.md
│ └── references/
│ ├── complexity-rubric.md ← Komplexitätsbewertungsraster
│ ├── priority-matrix.md ← P0/P1/P2/P3-Matrix
│ ├── routing-table.md ← Routing-Tabelle mit 30+ Skills
│ └── parallel-dependency.md ← Abhängigkeiten und Parallelisierung
├── improve-mode/ ← Sub-Skill 3: Struktur-Optimierung
│ ├── SKILL.md
│ └── references/
│ ├── seven-leverage-points.md ← 7 Verbesserungspunkte-Kategorien
│ ├── smart-criteria.md ← SMART-Prinzip
│ └── red-flags.md ← Beispiele für falsche Verbesserungen
├── examples/ ← Echte Beispiele
│ ├── fake-clarification.md ← Beispiel für falsche Klärung
│ ├── fake-triage.md ← Beispiel für falsche Triage
│ └── fake-improve.md ← Beispiel für falsche Verbesserung
├── test-prompts.json ← 6 Lebendtest-Beispiele + Selbstprüfungsfragen
├── README.md ← Paket-Fassade (house-style-Vorlage)
├── LICENSE ← MIT
└── .claude-plugin/
└── marketplace.json ← Plugin-Doppelkanal
Schleifbericht wurde verschoben nach
精修skills/13-元skill与治理/打磨报告/requirement-clarifier-打磨报告.md(zentral archiviert, um den Schleifstatus aller Skills einzusehen).
Gotchas (Router-Ebene)
❌ Nicht tun
- Nicht „anstelle ausführen“ – Dieser Skill ist die „Triage-Station“, nicht der „Operationssaal“. Nach Klärung und Triage explizit auf den nächsten ausführenden Skill verweisen
- Nicht „um der Nutzung willen nutzen“ – Wenn die Benutzereingabe bereits klar genug ist, einfach bestätigen
- Nicht „Domäne voraussetzen“ – Keine Frontend-, Backend-, Content-, Business- oder andere Domäne voraussetzen
- Nicht „zu sich selbst zurück routen“ – Nach der Triage nicht auf
requirement-clarifierverweisen, sondern den Kreislauf „Triage → Ausführung → Verifikation“ schließen - Nicht „growme überspringen und direkt change“ – Voraussetzung für Aufgabenberge ist, dass bereits klar ist, was gewünscht wird; sonst zuerst klären
- Nicht „mehr als 5 Fragen auf einmal stellen“ – Mehr als 5 = Du hast den Fokus verloren
- Nicht „mehr als 7 Verbesserungspunkte“ – Mehr als 7 = Du sortierst nicht, du listest nur auf
✅ Kriterien für Fertigstellungsgrad
Vor der Ausgabe sich fragen:
„Kann der Benutzer mit diesem Output direkt loslegen?“
- Ja → Fertig
- Nein → Welcher Schritt fehlt noch? Zurückgehen und ergänzen
- Unsicher → Hinzufügen „Benutzer muss XX bestätigen, bevor losgelegt werden kann“
Wann Sub-Skills laden
- growme-bezogene Anfragen →
growme-mode/SKILL.md+references/seven-dimensions.mdladen - change-bezogene Anfragen →
change-mode/SKILL.md+references/priority-matrix.md+references/routing-table.mdladen - improve-bezogene Anfragen →
improve-mode/SKILL.md+references/seven-leverage-points.mdladen - Selbstprüfung des Fertigstellungsgrads → Gotchas-Abschnitt dieser Datei lesen
Zeilenanzahl & Struktur
- SKILL.md-Hauptdatei (Router): ≤ 200 Zeilen (aktuell ~150 Zeilen, Ziel erreicht)
- Sub-Skill SKILL.md: ≤ 250 Zeilen
- Sub-Skill references/: Bei Bedarf laden, nicht in den Hauptkontext einfügen
- Gesamtzahl Strukturdateien: ≤ 20