Finde deine Unbekannten
Übersicht
Die Lücke zwischen der Beschreibung einer Aufgabe durch den Benutzer (seinem Prompt, Kontext, Referenzen) und der realen Arbeit (der Codebasis, ihren Einschränkungen, der Realität) ist der Ort, an dem Unbekannte leben. Wenn der Agent auf ein Unbekanntes stößt, rät er die Absicht des Benutzers. Die Aufgabe dieses Skills ist es, das Raten zu unterbinden: Dem Benutzer zu helfen, seine Unbekannten vor, während und nach der Implementierung iterativ zu entdecken und zu benennen – nicht als einmaligen vorausschauenden Plan.
Dies ist ein Werkzeugkasten, keine feste Pipeline. Diagnostiziere zuerst, wende dann nur die passenden Techniken an. Führe nicht alle bei einer trivialen Aufgabe aus.
Die vier Unbekannten
Klassifiziere, was fehlt, bevor du eine Technik auswählst:
- Bekannte Bekannte – bereits im Prompt genannt.
- Bekannte Unbekannte – der Benutzer weiß, dass er dies noch nicht entschieden hat.
- Unbekannte Bekannte – zu offensichtlich, um es aufzuschreiben, aber der Benutzer erkennt es auf den ersten Blick (oft visueller/UX-Geschmack).
- Unbekannte Unbekannte – nie bedacht; der Benutzer weiß nicht, was er nicht weiß.
Schritt 0 – Diagnose
Bevor du etwas tust, entscheide, welche Unbekannten dominieren, und wähle entsprechend Techniken aus:
- Unbekannte Domäne oder unbekannte Ecke der Codebasis → Blindspot-Scan (unbekannte Unbekannte).
- Schwierig zu beschreiben, „Ich erkenne es, wenn ich es sehe“ → Prototyp (unbekannte Bekannte).
- Richtung klar, Details unscharf → Benutzer interviewen + Planentwurf (bekannte Unbekannte).
Gib immer Kontext darüber, wer der Benutzer ist und was er bereits weiß – das schärft jede der folgenden Techniken.
Übergabe an andere Skills
Nutze diesen Skill als Entdeckungsschicht, nicht als gesamten Workflow. Wähle nach dem Benennen der Unbekannten den kleinsten Folgeskill, der die nächste Unsicherheit auflöst.
| Unbekanntes oder nächster Bedarf | Übergabe an | Verwende, wenn |
|---|---|---|
| Der Benutzer hat seine Absicht nicht vollständig ausgedrückt | interview-me | Stelle eine Frage nach der anderen, bis das zugrunde liegende Bedürfnis klar ist. |
| Der Plan muss auf Stabilität geprüft werden | grill-me oder grill-with-docs | Belastungstest für Annahmen; verwende die Docs-Variante, wenn ADRs oder Glossar-Updates festgehalten werden sollen. |
| Externe Fakten fehlen | research oder source-driven-development | Sammle Primärquellen-Beweise, bevor du entscheidest. |
| Der Benutzer erkennt es, wenn er es sieht | prototype | Zeige konkrete Optionen mit Dummydaten, bevor du dich zur Implementierung verpflichtest. |
| Die Arbeit benötigt ein formelles Pflichtenheft | spec-driven-development | Wandle entdeckte Einschränkungen und Entscheidungen in eine PRD/Spezifikation um. |
| Die Arbeit ist zu groß, um sie direkt auszuführen | planning-and-task-breakdown oder writing-plans | Zerlege die abgestimmte Spezifikation in geordnete, überprüfbare Abschnitte. |
| Schnittstellengrenzen sind unklar | api-and-interface-design oder design-an-interface | Entscheide API-, Modul- oder Typverträge. |
| Die Form der Codebasis ist die Unsicherheit | codebase-design oder improve-codebase-architecture | Finde die richtige Modulgrenze, Abstraktion oder Refactoring-Richtung. |
| UI-Verhalten oder visuelle Qualität sind unsicher | frontend-ui-engineering | Wandle gewählte Prototypen oder Präferenzen in produktive UI-Arbeit um. |
| Ein Fehler ist vorhanden, aber die Ursache ist unklar | systematic-debugging oder diagnosing-bugs | Reproduzieren, isolieren, hypothesen, instrumentieren und beheben. |
| Implementierung umfasst unabhängige Aufgaben | subagent-driven-development oder dispatching-parallel-agents | Teile Arbeit nur auf, wenn Aufgaben keinen gemeinsamen Zustand oder sequenzielle Abhängigkeiten haben. |
| Arbeit erscheint abgeschlossen | verification-before-completion, requesting-code-review oder code-review | Überprüfe Beweise, dann prüfe vor Abschluss oder Merge. |
Fasse vor der Übergabe zusammen:
- Was jetzt bekannt ist.
- Was unbekannt bleibt.
- Welche Entscheidung die Implementierung ändern würde.
- Welches Artefakt weitergereicht werden soll: Prototyp, Spezifikation, Implementierungsnotizen oder Abnahmebericht.
Techniken nach Phase
Jede Technik hat einen Auslöser und eine versandbereite Prompt-Vorlage. Passe die eingeklammerten Teile an.
Erkunden (Unbekannte finden)
1. Blindspot-Scan – erster Schritt in einem unbekannten Bereich.
Ich möchte [X] hinzufügen, kenne aber das [Y]-Modul in dieser Codebasis kaum. Führe einen Blindspot-Durchlauf durch – finde meine „unbekannten Unbekannten“ und erkläre sie mir, damit ich einen besseren Prompt schreiben kann.
2. Prototyp – wenn es nicht beschrieben werden kann, zeige es. Verwende Dummydaten, kein Backend.
Bevor du die echte App anfasst, erstelle eine HTML-Datei, die [die Benutzeroberfläche] mit Dummydaten simuliert. Gib mir 4 völlig unterschiedliche Designrichtungen, damit ich sehen kann, welche sich richtig anfühlt.
3. Benutzer interviewen – drücke die verbleibenden unscharfen Punkte heraus.
Stelle mir eine Frage nach der anderen. Ziel ist auf mehrdeutige Bereiche und priorisiere Fragen, deren Antwort die Architektur ändern würde.
Planen (Absicht abstimmen)
4. Eine Referenz zeigen – die beste Referenz ist Quellcode, nicht ein Screenshot.
[Pfad / Bibliothek] implementiert das [Verhalten], das ich möchte. Lese es und implementiere dann dieselbe Semantik in [unserem Stack] neu.
5. Einen Plan entwerfen – bringe die Entscheidungen zuerst an die Oberfläche, die sich am wahrscheinlichsten ändern.
Schreibe einen HTML-Implementierungsplan, aber setze die Entscheidungen, die ich am wahrscheinlichsten anpassen werde, ganz nach oben: Datenmodelländerungen, neue Typschnittstellen, alles Benutzersichtbare. Setze mechanische Refactorings ans Ende – da vertraue ich dir.
Implementieren (Unbekannte, die während der Arbeit auftauchen, einfangen)
6. Notizen während der Arbeit – starte eine neue Sitzung, füge die Spezifikation/den Prototyp ein, dann:
Pflegen Sie eine implementierungs-notizen.md. Wenn ein Randfall Sie vom Plan abweichen lässt, wählen Sie die konservative Option, notieren Sie sie unter einem Abschnitt „Abweichungen“ und fahren Sie fort.
Ausliefern (andere abstimmen, Verständnis überprüfen)
7. Übergabe-Erklärer
Verpacke den Prototyp, die Spezifikation und die Implementierungsnotizen in ein Dokument, das ich in den Chat einfügen kann, um Zustimmung zu erhalten. Setze ein Demo-GIF an den Anfang.
8. Abnahme-Quiz – die harte Regel des Autors: Bestehe es vor dem Merge.
Ich möchte sicher sein, dass ich diese Änderung vollständig verstehe. Erstelle einen HTML-Bericht mit dem Kontext der Änderung, der Intuition und dem, was getan wurde – dann ein Quiz am Ende, das ich bestehen muss.
Betriebsregeln
- Wann immer du im Begriff bist, die Absicht des Benutzers zu erraten, halte an und wende stattdessen die passende Technik an.
- Verkette die Artefakte: Prototyp → Spezifikation → Implementierungsnotizen → Abnahmebericht; jedes ist die Eingabe für das nächste, damit eine neue Sitzung den Kontext nicht verliert.
- Für eine kleine Aufgabe erfassen
Blindspot-Scan + Planentwurf + Abnahme-Quizbereits den Großteil des Werts. Ziehe es nicht in die Länge.