heithmurray/agent-skills

bcp-finish

Der Abschlussschritt für echte Arbeit. Ein Modell hat sie erstellt; ein anderes Modell greift sie an; der Operator entscheidet. Basierend auf dem Builder-Challenger-Protocol v1.7 (https://github.com/heithmurray/builder-challenger-protocol, CC BY 4.0, Heith Murray).

Wann

• Führe es aus, bevor du um Freigabe zur Fertigstellung für Arbeiten bittest, die über eine schnelle Änderung hinausgehen. Warte nicht, bis du darum gebeten wirst.
• Überspringe es für schnelle Arbeiten: offensichtlich, klein und leicht rückgängig zu machen. Fokussierte Überprüfung ist ausreichend.
• Ein Thema pro Durchlauf: die Änderung, die du gerade einreichen möchtest.

Rollen

• Builder: Du, der Agent, der die Arbeit erledigt hat. Du behebst oder beantwortest jeden Einwand.
• Challenger: Ein anderes Modell, schreibgeschützt ausgeführt. Es findet Probleme; es bearbeitet niemals Dateien oder schreibt auslieferbaren Text.
• Operator: Die Person, die die Arbeit besitzt. Nur der Operator genehmigt, akzeptiert ein Risiko, verlängert die Rundenbegrenzung, gibt einen Wahrheitsvorbehalt oder eine REFRAME aus oder entscheidet über den Umfang. Du fungierst als Vermittler zwischen Builder und Challenger und kannst nur bei Formatverstößen einen standardmäßigen RESET — [Anweisung] ausgeben.

Wer fordert wen heraus

• Der Challenger ist immer aus einer anderen Modellfamilie als der Builder, gestartet im Headless-Modus (schreibgeschützt). Die Paarungen und genauen Befehle stehen in references/tools.md.
• Verwende das konfigurierte Standardmodell jedes Tools; wähle keines aus.
• Jeder Aufruf ist eine frische Sitzung ohne gemeinsamen Verlauf. Gib jedes Mal die vollständigen Runden-Informationen (siehe Handoff).
• Erlaube bis zu 10 Minuten pro Aufruf. Jede Runde dauert normalerweise 1 bis 5 Minuten.

Handoff (was der Challenger erhält)

Jede Runde schreibe eine Eingabeaufforderung mit diesen Teilen in dieser Reihenfolge:

1. references/challenger-prompt.md, die gesamte Datei (Rollen, Regeln und Formate).
2. RUNDE [n] — BUILDER-AUSGABE — v1.[n-1].
3. Thema: Ein Satz darüber, was diese Änderung erreichen muss, möglichst in den Worten des Operators, plus die Abnahmekriterien.
4. Wo suchen: Der Repository-Pfad, Basis- und Head-Commits, die Befehle, um den Diff zu sehen (z. B. git diff <basis>..<head>), und die relevanten Dateien.
5. Nachweise des Builders: Die von dir durchgeführte Verifikation und ihre Ergebnisse.
6. Ab Runde 2: Deine Builder-Antwort (das Builder-Antwortformat unten) und das letzte Einwandsprotokoll des Challengers, wortwörtlich.

Sonst nichts. Keine Kommentare, keine vorherigen Runden außerhalb des Protokolls.

Der Challenger darf Dateien lesen und schreibgeschützte Befehle ausführen, um seine Punkte zu belegen. Nachweisebenen sind wichtig: Ausführen des Codes oder der Mathematik ist besser als das Zitieren einer Quelle, was besser ist als eine Meinung.

Die Schleife

Die Rundenbegrenzung ist 5, es sei denn, der Operator hat vor Runde 1 eine andere festgelegt. Wenn die Grenze ohne APPROVED erreicht wird, stoppe und frage den Operator. Der Operator kann sie einmal mit einer Begründung verlängern: VERLÄNGERUNG — [aktuelle Runde] auf [neues Limit]. Grund: [die noch offenen spezifischen Arbeiten]. Es gibt keine zweite Verlängerung; das erneute Erreichen des Limits ist eine Sackgasse.

1. Runde 1: Sende den Handoff. Speichere die Antwort des Challengers wortwörtlich als Runde 1.

2. Urteil ÜBERARBEITEN oder FEHLGESCHLAGEN: Antworte im Builder-Antwortformat:

   • Antwort auf das Urteil.
   • Akzeptierte Einwände (mit ID): was du geändert hast. Für jeden: "Einwand [ID] war Stufe [X]. Meine Überarbeitung hat [Y] geändert. Das Verhältnis ist angemessen, weil [Z]."
   • Abgelehnte Einwände (mit ID): Gründe mit Nachweisen gleicher oder höherer Stufe.
   • Anfechtung schwacher Einwände.
   • Antworten auf Annahmen.
   • Vorgenommene Überarbeitungen.
   • Verbleibende offene Fragen.

   Nimm die Überarbeitungen vor und committe sie auf dem Branch. Sende dann die nächste Runden-Information.

3. Ein Einwand, der den Umfang, das Verhalten oder das Design ändern würde, ist nicht deine Sache, stillschweigend zu beheben. Stoppe und lege ihn dem Operator zur Entscheidung vor, mit dem Text des Challengers wortwörtlich.

   • Eine Spezifikation oder ein Plan, den du selbst geschrieben hast, klärt den Umfang nicht. Lehne einen Einwand nicht ab, indem du darauf verweist. Nur die Worte des Operators oder eine vom Operator genehmigte Spezifikation zählen. Wenn der Umfang der einzige Grund für eine Ablehnung ist, melde es als "Operator-Entscheidung zum Umfang erforderlich".

4. Urteil BESTANDEN zählt nur mit einer abgeschlossenen Sign-Off-Checkliste, bei der die Anzahl der offenen Punkte Null ist und das endgültige Urteil APPROVED lautet. Andernfalls behandle es als ÜBERARBEITEN.

5. Rundenbegrenzung ohne APPROVED erreicht: Stoppe und lege das offene Protokoll dem Operator vor. Wenn der Operator verlängert (einmal), fahre fort. Andernfalls oder bei der verlängerten Grenze handelt es sich um eine Sackgasse: Bitte den Challenger um ein einseitiges Schluss Positionspapier, schreibe dein eigenes und lege beide dem Operator vor.

6. SELBST-FEHLER: Wenn der Ansatz selbst kaputt ist, sage dies mit den drei erforderlichen Teilen: (a) was kaputt ist, (b) warum es die Herausforderung gebraucht hat, um es ans Licht zu bringen, (c) was einen anderen Ansatz funktionieren lassen würde. Lege es dem Operator vor.

Bearbeite, kürze oder entschärfe niemals eine Antwort des Challengers. Behaupete niemals, ein Einwand sei gelöst; nur das Protokoll des Challengers kann ihn als gelöst markieren.

Wo die Aufzeichnung abgelegt wird

• Wenn die Arbeit einen Änderungsordner oder eine Aufgabenaufzeichnung hat, speichere die Runden dort als BCP-LEDGER.md: jede Antwort des Challengers und jede Builder-Antwort der Reihe nach.
• Andernfalls speichere sie in einem temporären Ordner außerhalb des Repositorys und füge das endgültige Protokoll in deinen Bericht ein.
• Erstelle keine neuen Ordner der obersten Ebene dafür.

Bericht an den Operator (Freigabe zur Fertigstellung)

• Die verwendeten Modelle für Builder und Challenger sowie die Anzahl der Runden.
• Die endgültige Version und das endgültige Urteil des Challengers.
• Das endgültige Einwandsprotokoll, wortwörtlich.
• Die Zugeständnisse des Challengers und seine Selbstprüfung auf nicht erhobene Risiken, wortwörtlich.
• Deine Verifikationsnachweise.
• Jede Interpretation, die du bei Mehrdeutigkeit der Anfrage vorgenommen hast (z. B. "Tage 6–29 kostenlos"), damit der Operator sie bestätigen oder korrigieren kann.
• Alles, was die Entscheidung des Operators erfordert: Sackgasse, SELBST-FEHLER, Umfangsfestlegungen, umfangsändernde Einwände, zu akzeptierende Risiken.
• Frage dann nach Go oder No-Go. Pushen, Mergen und Veröffentlichen warten auf das Go des Operators.

Wenn der Challenger nicht ausgeführt werden kann

1. Wiederhole es einmal. Wenn ein Modellfehler ein nicht unterstütztes Modell erwähnt, melde es; wechsle nicht stillschweigend das Modell.
2. Wenn das andere Tool weiterhin nicht verfügbar ist, führe dieselbe Schleife mit dem Headless-Schreibschutzbefehl deines eigenen Tools als Challenger aus (siehe references/tools.md). Es ist eine frische Sitzung ohne gemeinsamen Kontext.
3. Kennzeichne das gesamte Ergebnis im Bericht als SELBST-CHALLENGE und gib an, warum das zweite Modell nicht verfügbar war. Eine Selbst-Challenge teilt die blinden Flecke des Builders, daher sollte der Operator es geringer gewichten.
4. Überspringe den Schritt niemals stillschweigend.