Ziele festlegen und abnehmen

Ein Auftrag scheitert selten an der Technik. Häufiger scheitert er daran, dass niemand genau gesagt hat, wann er fertig ist. Dieses Kapitel zeigt zwei Hilfen, die genau dort ansetzen: den Skill goalengine, der aus einer vagen Absicht einen schriftlichen Zielvertrag macht, und die Abnahme mit Akzeptanzkriterien, die eine Aufgabe erst schließen lässt, wenn jedes Pflichtkriterium belegt ist.

Der Skill goalengine: aus Absicht wird ein Vertrag

goalengine klärt, was Sie erreichen wollen, und hält das Ergebnis als Zielvertrag mit festen Versionen fest. Er fragt gezielt nach, ohne eine Lösung vorzugeben. Die Frage „Welche Datenbank wollen Sie?“ stellt er nicht. Er fragt: „Welche Wartezeit ist aus Sicht der Nutzer akzeptabel?“

Er klärt nur. Er plant nicht und setzt nichts um: keine Codeänderung, kein Build, kein Deploy, keine Installation. Auch Aufgabenlisten und technische Wege gehören nicht in seinen Vertrag, sondern in die Planung danach.

So rufen Sie ihn

Mit Schrägstrich und Ihrer Zielbeschreibung:

/goalengine <Zielbeschreibung>

Dazu kennt er drei weitere Formen:

Er startet nur auf Ihren Aufruf. Claude ruft ihn nie von selbst auf.

Was dabei herauskommt

Im Gespräch fragt er in Runden von einer bis drei Fragen. Jede Aussage im Entwurf trägt eine Herkunft: von Ihnen gesagt, von Ihnen bestätigt, im Projekt gefunden, von außen vorgegeben, von der KI vorgeschlagen oder unbekannt. Was die KI nur vorschlägt, gilt nicht als Ihre Anforderung. Ein Pflichtkriterium, das als KI-Vorschlag markiert ist, lässt sich nicht freigeben.

Aus dem Gespräch entsteht ein Vertrag aus Ergebnis, Nutznießer, Grenzen und Erfolgskriterien. Meilensteine und Unterziele gruppieren nur Erfolgskriterien zu sichtbaren Zwischenergebnissen („Die Suche liefert passende Beiträge“). Arbeitsschritte sind sie nie.

Freigabe und Einfrieren

Ein Vertrag gilt erst, wenn Sie ausdrücklich eine benannte Version freigeben. Der Skill ist angewiesen, nie selbst freizugeben und keinen Entwurf als fertig weiterzureichen. Das Werkzeug goal.py prüft bei der Freigabe Schema und Version, aber nicht, wer freigibt: der Name hinter --durch wird frei eingetragen. Mit der Freigabe wird diese Version eingefroren und nie überschrieben. Eine Änderung beginnt eine neue Fassung, die Sie wieder freigeben müssen. Unveränderte Kriterien behalten dabei Zustand und Beleg.

Ein Kriterium zählt erst dann als erfüllt, wenn ein Beleg dran hängt: ein Commit, ein Testprotokoll mit exit=0, eine URL oder eine benannte Handprüfung. Das Ziel gilt nur als erreicht, wenn jedes Pflichtkriterium einen Beleg hat.

Der /goal-Prompt am Ende

Mit der Freigabe gibt der Skill einen fertigen, kopierbaren Prompt für den Claude-Code-Befehl /goal aus. Er beginnt mit „/goal Der freigegebene Vertrag .goals/<ID>-<slug>/vertrag-vNNN.json (Ziel <ID>, Version vNNN) muss erfüllt sein.“ und nennt die Kennungen aller Pflichtkriterien. Diesen Prompt geben Sie einer arbeitenden Sitzung. Erst er macht den Vertrag zur Abbruchbedingung dieser Sitzung. Ohne ihn bleibt der Vertrag eine Ablage. Der Prompt wird mit dem Vertrag gespeichert und lässt sich später wieder ausgeben.

Wo alles liegt und wo Sie es sehen

Die Ziele liegen im Projekt im Ordner .goals/. Dort steht je Ziel ein eigener Unterordner mit der Zieldatei, einer Lesefassung (GOAL.md), dem Verlauf und den eingefrorenen Vertragsdateien. Geschrieben wird nur über das mitgelieferte Programm goal.py, das jede Änderung gegen die Regeln prüft. Von Hand sollen Sie die Dateien nicht ändern.

Im Verzeichnis ~/.claude/goals/ führt das Werkzeug eine Liste der Projekte, die Ziele haben. Entfernen Sie Code Guardian, bleiben ~/.claude/goals/ und die .goals/-Ordner Ihrer Projekte stehen. Ein Deinstallationsskript liegt dem Paket derzeit nicht bei; wie Sie es von Hand entfernen, beschreibt die README des Pakets.

Im Leitstand zeigt der Reiter „Goal Engineering“ die Ziele aller Projekte: Status, freigegebene Version, Kriterien mit Zustand und Beleg, und das Kriterium, an dem gerade gearbeitet wird. Jede Zielkarte mit freigegebenem Vertrag trägt außerdem den /goal-Prompt zum Aufklappen und Kopieren.

Abnahme mit Akzeptanzkriterien

Seit v17.15 tragen neue Aufgabenordner (aufgabe.py neu) Akzeptanzkriterien. Das ist die Abnahme im Kleinen, direkt an der einzelnen Aufgabe:

• Die Kriterien werden vor dem ersten eigenen Commit eingefroren und gesiegelt.
• aufgabe.py abschliessen schließt die Aufgabe erst, wenn jedes Pflichtkriterium belegt ist.
• Ein Kriterium, das später dazukommt, erscheint nur als sichtbarer Nachtrag mit neuem Review. Still ergänzen lässt sich nichts.
• Wer bewusst ohne Kriterien arbeitet, sagt das mit --kriterien-entfaellt "<Grund>". Der Grund steht dann nachlesbar dabei.
• Ein einzelnes Pflichtkriterium kann nur mit Grund und sichtbar entfallen (aufgabe.py beleg … --kriterium K<n> --entfaellt "<Grund>"). Es hält den Abschluss danach nicht mehr auf.
• Wer erst nach dem Code einfriert, sagt das mit --trotz-code "<Grund>". Der Grund geht in das Siegel der Kriterien ein.
• Optionale Kriterien (--optional-kriterium) halten den Abschluss nie auf.
• Ein Review-Urteil REVIEW: CHANGES ohne kritischen Befund gilt als Beleg. „NICHT GEPRÜFT“ gilt in keiner Schreibweise als Beleg.
• Für ein Repository ohne ersten Commit gibt es --ohne-basis.

Bestehende Aufgabenordner sind nicht betroffen.

Gesiegelte Testprotokolle

Ein eingeklebter Testlauf beweist wenig. Das Werkzeug beleg-lauf.py versiegelt deshalb ein Testprotokoll mit dem Inhaltsstand Ihres Arbeitsbaums. Daraus folgt:

• Veraltet: Ändert sich der Baum während des Laufs, gilt der Beleg als veraltet. Das Protokoll gehört dann nicht mehr zum Stand, den es belegen soll.
• Übersprungen belegt nichts: Tests, die mit SKIP übersprungen wurden, zählen nicht als bestanden.
• Neuer Commit: Steht HEAD inzwischen auf einem anderen Commit, etwa nach einem Rebase, nennt die Absage genau diesen Fall.

Verdeckte Abnahmefälle

Ein Kriterium der Art review · holdout gilt nur durch Fälle, die ein frischer Subagent nach dem Einfrieren schreibt und die beim Bauen nicht sichtbar sind. Jeder dieser Fälle braucht ein gesiegeltes Protokoll.

Grenzen – ehrlich

• Kein Hook erzwingt den Vertrag. Kein Riegel liest .goals/ und hält eine Sitzung an, die einen Vertrag nicht erfüllt. Das Werkzeug prüft Schema, Freigabe und Beleg, aber nur im Moment, in dem Sie goal.py aufrufen. Dazwischen passiert nichts.
• Zielklarheit ist keine Machbarkeit. Ein freigegebener Vertrag sagt, was gelten soll. Er sagt nicht, dass es sich bauen lässt, dass die Arbeit richtig ist oder dass der Beleg stimmt. Das Ziel ist danach geschrieben und prüfbar, mehr nicht.
• Er startet nur auf Aufruf. Wer /goalengine nicht ruft, bekommt keinen Vertrag.
• Nur Claude Code. Der /goal-Prompt hat im Codex-Paket keine Entsprechung.
• Die Abnahme gilt für neue Aufgabenordner. Alte Ordner bleiben, wie sie sind.

In einem Satz

goalengine macht aus Ihrer Absicht einen eingefrorenen, belegbaren Zielvertrag, und die Abnahme schließt eine Aufgabe erst, wenn jedes Pflichtkriterium mit einem Beleg dasteht.