Erst erkunden

/opsx:explore ist Ihr Denkpartner. Greifen Sie dazu, wann immer Sie ein Problem haben, aber noch keinen Plan. Es untersucht Ihren Code, wiegt Optionen gemeinsam mit Ihnen ab und klärt, was Sie tatsächlich wollen – all das, bevor ein einziges Artefakt oder eine einzige Zeile Code erstellt wird. Wenn das Bild klar ist, übergibt es an /opsx:propose.

Wenn Sie aus diesen Dokumenten eine Gewohnheit mitnehmen, nehmen Sie diese mit: Wenn Sie unsicher sind, erkunden Sie, bevor Sie vorschlagen.

Hier ist der Grund, warum das wichtig ist. KI-Coding-Assistenten sind eifrig. Fragen Sie vage, und sie bauen mit Zuversicht etwas – vielleicht aber nicht das, was Sie gebraucht hätten. Erkunden ist das Gegenmittel. Es ist ein risikofreies Gespräch, in dem Sie und die KI gemeinsam den richtigen Schritt finden, sodass Sie beim Vorschlagen das Richtige vorschlagen.

Wann erkunden

Erkunden ist häufiger der richtige erste Schritt, als man denkt. Nutzen Sie es, wenn eine der folgenden Bedingungen zutrifft:

• Sie kennen das Problem, aber nicht die Lösung. („Seiten fühlen sich langsam an." „Auth ist ein Chaos." „Wir bekommen ständig doppelte Bestellungen.")
• Sie wählen zwischen Ansätzen und möchten die Abwägungen anhand Ihres tatsächlichen Codes dargestellt sehen.
• Sie sind neu in einem Codebase und müssen verstehen, wie etwas funktioniert, bevor Sie es ändern.
• Die Anforderungen sind vage und Sie möchten sie schärfen, bevor Sie sich festlegen.
• Sie vermuten, dass die Arbeit größer oder kleiner ist, als sie aussieht, und möchten sie ehrlich einordnen.

Überspringen Sie Erkunden nur, wenn Sie bereits genau wissen, was Sie wollen und wie. In diesem Fall gehen Sie direkt zu /opsx:propose.

Was es tut (und was nicht)

Erkunden ist ein Gespräch, kein Generator.

Es tut:

• Liest und durchsucht Ihren Code, um echte Fragen zu beantworten.
• Vergleicht Optionen und benennt die Abwägungen jeder einzelnen.
• Zeichnet Diagramme, um ein Design lesbar zu machen.
• Hilft Ihnen, eine vage Idee in einen konkreten, umsetzbaren Umfang einzugrenzen.
• Wechselt zu /opsx:propose, wenn Sie bereit sind.

Es tut nicht:

• Erstellt keinen Änderungordner.
• Schreibt keine Artefakte (kein Vorschlag, keine Spezifikationen, kein Design, keine Aufgaben).
• Schreibt oder ändert keinen Code.

Darin liegt der Punkt. Erkunden kostet Sie nichts und verpflichtet Sie zu nichts. Sie können drei Sackgassen erkunden, aus jeder etwas lernen und erst dann den Weg vorschlagen, der überlebt hat.

Es ist bereits installiert

Gute Nachricht: /opsx:explore ist im Standard-core-Profil enthalten, direkt neben propose, apply, update, sync und archive. Sie müssen nichts aktivieren. Wenn OpenSpec in Ihrem Projekt eingerichtet ist, ist Erkunden in Ihrem KI-Chat bereit. (Wie bei allen /opsx:*-Befehlen tippen Sie es in den Chat Ihres Assistenten, nicht in das Terminal. Siehe So funktionieren Befehle.)

Ein vollständiges Beispiel

Sehen Sie, wie eine vage Sorge zu einer präzisen, umsetzbaren Änderung wird.

You: /opsx:explore

AI:  What would you like to explore?

You: Our checkout sometimes creates duplicate orders. I don't know why
     and I don't know how to fix it safely.

AI:  Let me dig into the checkout path...
     [reads the order service, the payment webhook handler, and the
      client submit logic]

     Here's what I found. There are two ways a duplicate can happen:

     1. The client can submit twice (double-click, retry on slow network).
        Nothing debounces it.
     2. The payment webhook can fire more than once, and the handler
        creates an order each time. There's no idempotency key.

     Cause #2 is the dangerous one: it can charge and fulfill twice.

     Three ways to fix it, roughly in order of robustness:
     - Idempotency key on the order-creation endpoint (handles both causes)
     - Dedup on the webhook by payment-intent id (handles #2 only)
     - Client-side debounce (handles #1 only, papers over the real bug)

     Given your code already stores the payment-intent id, the
     idempotency-key approach is a small change with the biggest payoff.
     Want me to scope that?

You: Yes, let's do the idempotency key.

You: /opsx:propose add-order-idempotency-key

AI:  Created openspec/changes/add-order-idempotency-key/, with a proposal
     and delta spec grounded in what we just found. Ready for implementation.

Beachten Sie, was passiert ist. Der Ausgangspunkt war „etwas stimmt nicht und ich traue mich nicht, es anzufassen." Zwanzig Sekunden Erkunden haben daraus eine benannte Ursache, drei priorisierte Optionen, eine Empfehlung, die auf dem vorhandenen Code basiert, und eine präzise Änderung gemacht. Der folgende Vorschlag ist scharf, weil das Denken zuerst stattfand.

Übergabe an propose

Erkunden archiviert in nichts. Wenn Sie bereit sind, starten Sie einfach eine Änderung, und die KI übernimmt den Kontext aus Ihrem Gespräch in die Artefakte.

explore  ──►  propose  ──►  apply  ──►  archive
 (think)     (agree)       (build)     (record)

Sie können es in einfacher Sprache sagen („lass uns das in eine Änderung verwandeln") oder /opsx:propose <name> direkt ausführen. Auf jeden Fall wird die Erkundung, die Sie gerade durchgeführt haben, zur Grundlage des Vorschlags – nicht zu Wegwerf-Chat.

Wenn Sie den erweiterten Befehlssatz verwenden, kann Erkunden stattdessen an /opsx:new übergeben, für die schrittweise Artefakterstellung. Siehe Workflows.

Tipps für eine gute Erkundung

• Bringen Sie das Problem mit, nicht die Lösung. „Logins fühlen sich langsam an" gibt der KI Raum zur Untersuchung. „Füge einen Redis-Cache hinzu" verpflichtet Sie vorab zu einer Antwort, die Sie noch nicht getestet haben.
• Fragen Sie laut nach den Abwägungen. „Was sind die Nachteile jeder Option?" liefert Ihnen einen ehrlicheren Vergleich.
• Lassen Sie es zuerst lesen. Die besten Erkundungen beginnen damit, dass die KI tatsächlich in Ihren Code schaut, statt zu raten. Weisen Sie es auf den relevanten Bereich hin, wenn das hilft.
• Es ist okay, abzubrechen. Wenn die Erkundung zeigt, dass die Idee nicht lohnenswert ist, ist das ein Gewinn. Sie haben es günstig gelernt.
• Erkunden Sie auch während einer Änderung. Stecken Sie bei /opsx:apply fest? Sie können zurücktreten und ein Teilproblem erkunden, dann zurückkehren.

Die ehrlichen Abwägungen

Was Sie gewinnen: Erkunden erkennt Fehlentscheidungen im günstigsten möglichen Moment, bevor ein Artefakt existiert. Besonders leistungsfähig ist es in unbekanntem Code, wo die Fähigkeit der KI, das System zu lesen und zusammenzufassen, Ihnen einen Nachmittag des Erkundens erspart.

Was es kostet: ein wenig Geduld. Erkunden ist ein Gespräch, daher ist es langsamer als /opsx:propose abzufeuern und zu hoffen. Für Arbeit, die Sie bereits wirklich verstehen, ist dieser zusätzliche Schritt reine Überhead, und Sie sollten ihn überspringen.

Die Faustregel: Je vager die Aufgabe, desto mehr lohnt sich Erkunden. Je klarer die Aufgabe, desto mehr können Sie direkt zum Vorschlagen springen.

Wo es weitergeht

• Befehle: /opsx:explore: die präzise Referenz
• Workflows: Erkunden als Teil des täglichen Ablaufs
• Beispiele & Rezepte: Erkunden in einer vollständigen Schritt-für-Schritt-Anleitung
• Erste Schritte: die Anleitung zur ersten Änderung, Erkundung inklusive