ARQAWA/cursor-pi

Ziel definieren

Überblick

Formen Sie die Absicht des Benutzers in ein konkretes Ergebnis mit begrenztem Umfang und nachvollziehbaren Abschlusskriterien um, die aus der Anfrage abgeleitet sind. Die übliche Überprüfung erfolgt durch Lesen und logische Bewertung gemäß den Regeln der Hauptaufforderung; verwenden Sie Zahlen nur, wenn sie eine echte Anforderung ausdrücken.

Diese Fähigkeit umfasst nur die Zieldefinition und die Erstellung von Zielwerkzeugen. Erstellen Sie keine Zwischenplanungsartefakte, dauerhaften Schnappschüsse, Journale, Entscheidungsprotokolle oder Wiederaufnahmedateien aus dieser Fähigkeit.

Nur die Hauptinstanz (Main) verwaltet das native Ziel. Seine Auswahl fügt keine Tests, Überprüfungen, Delegationen, Berechtigungen oder andere Arbeitsabläufe hinzu. Der Goldstandard bewertet unabhängig den nützlichen Arbeitszustand, mit oder ohne Ziel. Notebook kann unter seinen eigenen Bedingungen automatisch einem ausgewählten Ziel beitreten, ohne eine weitere manuelle Anfrage; das Ziel allein erfordert dies nicht. Führen Sie nützliche Betriebsnotizen unter dieser Richtlinie außerhalb dieses Definitionsverfahrens; das native Ziel und der Status bleiben maßgeblich.

Die Definition allein autorisiert nicht die Ausführung der vorgeschlagenen Aufgabe. Ein Ziel ersetzt niemals die erforderliche Genehmigung oder Ausführungsbestätigung: Die ToSpec-Vorbereitung startet nicht das zukünftige Ausführungsziel, während ein explizit ausgewähltes Vorbereitungsziel nur das angeforderte Vorbereitungsergebnis betrifft. Die automatische Auswahl überschreibt keine Benutzerpause oder verwandelt einen Blocker, eine Genehmigungswartezeit, ein Endsignal oder eine Stornierung ohne Verwerfung in eine Fertigstellung. Befolgen Sie die tatsächlichen nativen Statusregeln; der Abschluss erfordert das tatsächliche Ergebnis und alle bereits obligatorischen Aktionen.

Arbeitsablauf

1. Bewerten Sie, ob ein Ziel für den tatsächlichen aktuellen Auftrag nützlich ist.

   • Wählen Sie es automatisch aus, wenn ein unabhängig angefordertes Ergebnis Kontinuität durch abhängige Phasen, substantielle Recherche oder Unsicherheit oder eine längere Ausführung benötigt, vorbehaltlich der Autoritätsprüfung in Schritt 6.
   • Kurze Fragen, einfache kurze Bearbeitungen und Diskussionen über mögliche zukünftige Arbeiten erfordern kein Ziel. Eine angeforderte Recherche kann selbst ein konkretes Ergebnis haben; die Diskussion autorisiert nicht deren Ausführung.
   • Ein direkter /goal-Befehl, eine Anfrage zur Erstellung eines Ziels oder eine Anfrage zur Zieldefinition wählt diese Fähigkeit unabhängig von der Komplexität aus. Eine Anweisung, ohne Ziel zu arbeiten, hat Vorrang vor der automatischen Auswahl für die betroffene Aufgabe.
   • Bewerten Sie nach einer wesentlichen Änderung der Aufgabe neu, nicht bei jedem Tool-Aufruf; verwenden Sie keine Schwellenwerte für Befehle, Minuten oder Dateien.

2. Formulieren Sie das wahrscheinliche Ziel in konkreten Begriffen um. Ein brauchbares Ziel benennt:

   • das spezifische Ergebnis, das wahr sein wird
   • das Hauptartefakt, System, Repository, die Umgebung oder das benutzerseitige Verhalten, das betroffen ist
   • wie das tatsächliche Ergebnis durch Lesen und logische Bewertung sowie durch explizit erforderliche Nachweise ermittelt wird
   • was im Umfang enthalten ist
   • was nicht im Umfang enthalten ist, wenn Mehrdeutigkeit relevant wäre
   • die Abbruchbedingung für Nachfragen beim Benutzer anstatt endlosem Bearbeiten

3. Verwenden Sie Kriterien, die das angeforderte Ergebnis darstellen.

   • Leiten Sie Ergebnis, Artefaktpfade, Umfang, Format, Werte und binäre Abschlussbedingungen aus der Anfrage ab.
   • Erfinden Sie keine Metriken, Schwellenwerte, Validatoren oder Ausführungszählungen für formale Messbarkeit.
   • Tests, Befehle, CI, Messungen und Nachweiszählungen sind nur Optionen für explizit angeforderte empirische Nachweise oder ein speziell übernommenes Verfahren oder eine höher priorisierte Verpflichtung.
   • Für gewöhnliche Fehlerbehebungen, Analysen oder architekturbasierte Leistungsarbeiten definieren Sie den Abschluss durch das tatsächliche Ergebnis und die logische Bewertung.

4. Beheben Sie schwache Ziele, bevor Sie sie setzen.

   • Formulieren Sie vage Ziele in konkrete Ergebniskriterien um, wenn die Anfrage und der lokale Kontext diese Interpretation sicher machen.
   • Stellen Sie eine knappe Klarstellungsfrage, wenn das fehlende Detail das beabsichtigte Ergebnis oder die Validierung ändert.
   • Lehnen Sie reine Aktivitätsziele wie „Fortschritt machen“, „weiter recherchieren“, „Dinge verbessern“ oder „an X arbeiten“ ab, es sei denn, sie werden zu einem überprüfbaren Ergebnis geschärft.

5. Überprüfen Sie den aktiven Zielstatus, bevor Sie ein Ziel erstellen.

   • Lesen Sie den aktuellen nativen Ziel-Schnappschuss aus scope_focus_native_context. Validieren Sie conversationId, goalId, Ziel und nativen Status (0 nicht spezifiziert, 1 aktiv, 2 pausiert, 3 abgeschlossen, 4 gelöscht). Ein fehlender gültiger Stammzustand bedeutet kein Ziel; unbekannte Identität/Status ist unbekannt, nicht Abwesenheit. Kinder verwalten kein Stammziel. Verwenden Sie nur tatsächliche native Budgetfelder, wenn sie bereitgestellt werden; erfinden Sie sie nicht.
   • Verwenden Sie die verfügbaren nativen create_goal/update_goal-Werkzeuge und deren aktuelle Schemata. Cursor create_goal benötigt einen Zieltext; übergeben Sie kein Codex-spezifisches Budgetfeld. Eine fehlende erforderliche native Fähigkeit stoppt ihren abhängigen Übergang; simulieren Sie kein Ziel oder behaupten Sie keine vollständige Bereitschaft.
   • Wenn kein unfertiges Ziel vorhanden ist, die Zieltext die Qualitätsschwelle erfüllt und Schritt 6 die Erstellung erlaubt, rufen Sie create_goal auf.
   • Verwenden Sie ein passendes unfertiges Ziel gemäß den aktuellen Benutzeranweisungen und dem nativen Status wieder; wiederholte Auswahl erstellt kein Duplikat oder wiederholt abgeschlossene Vorgänge.
   • Bewahren Sie ein widersprüchliches unfertiges Ziel. Setzen Sie es nicht zurück, ersetzen Sie es nicht oder markieren Sie es nicht als vollständig, nur um Platz zu schaffen. Lösen Sie nur den materiellen Konflikt über einen erlaubten nativen Pfad oder eine gezielte Benutzerfrage; fordern Sie keinen neuen Thread.

6. Erstellen Sie das Ziel nur, wenn es die Qualitätsschwelle besteht.

   • Die Auswahl dieser Fähigkeit autorisiert nicht von selbst create_goal. Befolgen Sie die tatsächlichen Tool-Anweisungen und höher priorisierten Regeln. Die ausdrückliche Übernahme des bedingten automatischen Ziels durch den Benutzer oder eine anwendbare System-/Entwickleranweisung liefert eine stehende Anfrage nur dort, wo diese Regeln sie akzeptieren. Die Verfügbarkeit der Fähigkeit oder eine gewöhnliche Aufgabe allein ist nicht diese Autorität; wenn der Host eine separate explizite Anfrage erfordert, leiten Sie keine Erlaubnis gegen diese Anforderung ab.
   • Wenn das native Ziel nicht verfügbar oder nicht erlaubt ist, simulieren Sie es nicht mit Dateien oder einem anderen Controller. Fahren Sie mit kompatibler autorisierter Arbeit fort; offenlegen Sie die konkrete Einschränkung nur, wenn sie für das Ergebnis oder ein explizit angefordertes Ziel wesentlich ist.
   • Verwenden Sie eine einzige prägnante Zielzeichenfolge.
   • Fügen Sie ausreichende Abschlusskriterien hinzu: das angeforderte Ergebnis, bewertet durch Lesen und Logik, plus alle explizit erforderlichen Nachweise. Jeder hinzugefügte Schwellenwert oder jede Methode muss der Anfrage folgen; das Schreiben in den Zieltext schafft keine Autorität.
   • Fügen Sie Umfangsgrenzen hinzu, wenn sie die Arbeit einschränken.
   • Ein Budget wird nur bereitgestellt, wenn es explizit angefordert und vom tatsächlichen nativen Schema unterstützt wird. Wenn ein angefordertes Budget nicht durch das native Cursor-Ziel dargestellt werden kann, stoppen Sie diesen abhängigen Übergang und offenlegen Sie die fehlende Fähigkeit; werfen Sie das Budget nicht stillschweigend weg oder simulieren Sie es nicht.
   • Formulieren Sie ein klares erlaubtes Ziel, ohne erneut zu fragen, bloß um den Modus zu aktivieren oder seine technische Formulierung zu genehmigen. Fragen Sie nur, wenn eine fehlende Wahl das angeforderte Ergebnis, die Autorität oder die erforderlichen Nachweise wesentlich ändert. Eine definitionsnur-Anfrage bleibt definitionsnur.

Zielqualitätsschwelle

Vor create_goal sollte der Zieltext beantworten:

• Welche konkrete Sache wird wahr sein, wenn dies erledigt ist?
• Welche tatsächlichen materiellen und logischen Grundlagen belegen dies, und welche empirischen Nachweise hat der Benutzer explizit gefordert?
• Welches angeforderte Ergebnis oder welche aussagekräftige binäre oder quantitative Bedingung definiert den Erfolg?
• Welche Umfangsgrenzen sind wichtig?
• Was sollte dazu führen, dass der Agent anhält und nachfragt?

Gut:

Ersetzen Sie A durch B in der angegebenen Einstellung. Beenden Sie, wenn die Bearbeitung vorhanden ist und das Lesen des betroffenen Codes die Konsistenz mit der Anfrage belegt.

Gut:

Lösen Sie die angegebene Designfrage aus relevanten Quellen und Logik. Beenden Sie, wenn die Schlussfolgerung gestützt wird und materielle Widersprüche adressiert sind.

Schwach:

Checkout schneller machen.

Schwach:

Untersuchen Sie die PR-Kommentare weiter.

Quantifizierungsheuristiken

• Für Fehler: Definieren Sie die erforderliche Korrektur und erklären Sie sie anhand des betroffenen Codes und der Logik. Reproduktion und ein fehlschlagender-dann-bestehender Validator erfordern eine explizite Anfrage für diesen Nachweis.
• Für explizit angeforderte Tests: Nennen Sie das geordnete Szenario und seine Bestehensbedingung; beachten Sie einen angegebenen Befehl.
• Für Leistung: Argumentieren Sie auf Basis von Mechanismen, Arbeit und Kontext. Kennzeichnen Sie berechnete Komplexität als Berechnung; beanspruchen Sie eine gemessene Verbesserung nur aus tatsächlichen Messungen. Erfinden Sie keine Metrik, kein Ziel, keine Methode und keine Ausführungsanzahl.
• Für Qualitätsarbeit: Verwenden Sie das angeforderte Ergebnis, das normalerweise durch Lesen und Logik bewertet wird; fügen Sie nicht automatisch Linting, Typprüfungen oder Tests hinzu.
• Für Recherche: Definieren Sie die Entscheidung, die die Recherche ermöglichen muss, die Quellen oder Systeme im Umfang und den Nachweisstandard.
• Für Betrieb: Definieren Sie den angeforderten resultierenden Zustand. Erfinden Sie keine Überwachungsfenster, Schwellenwerte oder Rollback-Arbeiten.

Klarstellungsfragen

Fragen Sie nur, wenn eine angemessene Umformulierung riskieren würde, das falsche Ergebnis zu verfolgen. Halten Sie die Frage kurz und auf die fehlende Validierung oder Umfangsgrenze ausgerichtet.

Nützliche Frageformen:

• „Welche Metrik sollte den Erfolg hier definieren: Latenz, Kosten, Genauigkeit oder benutzerseitiges Verhalten?“
• „Welche Umgebung soll ich zur Überprüfung verwenden: lokal, Staging oder Produktion?“
• „Was ist der minimale Nachweis, den Sie wünschen, bevor ich dieses Ziel als abgeschlossen markiere?“

Wenn ein aussagekräftiges Kriterium direkt aus der Anfrage folgt, formulieren Sie es ohne weitere Bestätigung. Fragen Sie nur, wenn eine ungelöste Wahl das Ergebnis oder die erforderlichen Nachweise wesentlich ändert.