make-harness

Was macht make-harness?

Verwende diesen Skill, wenn der Benutzer einen projektlokalen Harness im aktuellen Repository einrichten, überprüfen, aktualisieren oder reparieren möchte.

Dieser Skill ist der Bootstrapper und Wartungseinstiegspunkt. Der eigentliche Projektvertrag muss in den lokalen Dateien des Zielprojekts leben, nicht im Skill selbst.

Was dieser Skill verwaltet

Erstelle, aktualisiere oder repariere diese projektlokalen Dateien:

• AGENTS.md
• CLAUDE.md
• GEMINI.md
• PROJECT_HARNESS.md
• harness-contract.json
• harness-runtime.json

Vorlagenquellen befinden sich in assets/templates. Verwende tools/apply-harness.py, um die Projektionsdateien deterministisch aus dem Vertrags-/Laufzeitpaar zu regenerieren. Verwende tools/check-harness-done.py als Abschlussprüfung, bevor der Harness als fertig behandelt wird. Verwende tools/check-sensitive-change.py, wenn CI, Hooks oder Reviewers eine deterministische, lightweight pfadbasierte Smoke-Check benötigen, ob der aktuelle Diff sensible Bereiche berührt.

Kernverhalten

1. Untersuche zuerst das aktuelle Repository und alle vorhandenen Harness-Dateien.
2. Behandle /make-harness als einzelnen Einstiegsbefehl: bootstrap, wenn kein Harness existiert, update, wenn ein gesunder Harness bereits existiert, und repair, wenn Drift oder Bruch erkannt wird.
3. Bewahre den dauerhaften Projektvertrag in PROJECT_HARNESS.md und harness-contract.json auf.
4. Halte Interviewfortschritt, Synchronisationsmetadaten und Spracherkennungshinweise nur in harness-runtime.json fest.
5. Wenn der Harness unvollständig ist oder dauerhafte Standardwerte fehlen, starte ein kurzes Interview, bevor du Standardwerte als endgültig betrachtest.
6. Führe das Interview interaktiv durch, eine Frage nach der anderen.
7. Erkenne die wahrscheinliche Kollaborationssprache zuerst aus Repository-Signalen; bestätige sie, wenn sie unklar ist, anstatt einen Englisch-zuerst-Opener zu erzwingen.
8. Spiegle nach jeder Antwort den Laufzeitfortschritt in harness-runtime.json und dauerhafte Antworten in harness-contract.json wider.
9. Bestätige nur dauerhafte Projektstandards, projektspezifische Sicherheitsleitplanken und Ausführungsleitplanken.
10. Halte die minimale Durchsetzungsabsicht in rule_strengths fest, damit der Vertrag zwischen beratenden, geführten und erzwungenen Regeln unterscheiden kann.
11. Halte AGENTS.md, CLAUDE.md und GEMINI.md schlank. Lege den dauerhaften Vertrag in PROJECT_HARNESS.md ab, und behalte dann die Einstiegsdateien als Verweise und zusammenfassende Regeln.
12. Validiere, dass die verwalteten Harness-Dateien bezüglich des bestätigten Vertrags übereinstimmen. Wenn Drift erkannt wird, repariere ihn vor dem Abschluss.
13. Führe die Abschlussprüfung durch, bevor der Erfolg erklärt wird: Die Prüfung muss bestanden sein, der Laufzeitzustand muss gesund sein, validierte gemeinsame Felder müssen vollständig sein, und deterministische Projektionen müssen mit den eingecheckten Dateien übereinstimmen.
14. Wenn der aktuelle Diff sensible Bereiche berührt, verwende die leichte, pfadbasierte Leitplanken-Smoke-Check, damit CI/Hooks deterministisch fehlschlagen können, wenn erzwungene Leitplanken betroffen sind.
15. Für die Hook-Integration bevorzuge Staged-Datei-Prüfungen gegenüber HEAD~1..HEAD-Schätzungen, verwende MAKE_HARNESS_HOOK_MODE anstelle von projektübergreifenden Namensresten und erlaube einen kleinen strict / warn / off-Modusschalter anstelle eines einzelnen fest codierten Verhaltens.
16. Zeichne einen prägnanten Änderungsverlaufseintrag auf, wenn sich der dauerhafte Projektvertrag ändert.
17. Speichere keine anfragebezogenen Arbeitstypen wie bugfix, feature, maintenance oder refactor als permanenten Harness-Zustand.
18. Speichere keine Framework-Level-Orchestrierungspräferenzen als permanenten Harness-Zustand.

Laufzeitklassifizierung

Lies harness-contract.json und harness-runtime.json, falls sie existieren.

• Wenn kein Harness existiert, bootstrappe ihn.
• Wenn der Harness existiert und gesund ist, wechsle in den Update-Modus.
• Wenn der Harness existiert, aber abgedriftet oder defekt ist, repariere zuerst und fahre nur bei Bedarf mit dem Update fort.
• Wenn bootstrap_status pending_interview ist, ist der Harness noch nicht konfiguriert.
• Wenn bootstrap_status interview_in_progress ist, setze vom aufgezeichneten Laufzeitzustand aus fort.

Interaktiver Interviewprozess

• Stelle immer genau eine Frage auf einmal.
• Dies ist ein einmaliger Einrichtungsprozess, daher ist Präzision wichtiger als die Minimierung der Fragenanzahl.
• Für ein bestehendes Repository verwende ein Repository-zuerst-Interviewverhalten: Untersuche und schließe zuerst, bestätige dann nur das, was unklar bleibt.
• Für ein leeres Projekt wechsle zu einem Setup-Entdeckungsinterviewverhalten: Stelle nur die kleinen anfänglichen Fragen, die nötig sind, um Stack, Laufzeit, Paketmanager und Kernbefehle auszuwählen.
• Befolge die festgelegte Fragenreihenfolge aus references/interview-protocol.md.
• Bevorzuge Bestätigungsfragen gegenüber offenen Fragen, wenn das Repository bereits eine wahrscheinliche Antwort liefert.
• Bevorzuge die Untersuchung des Repositorys gegenüber dem Fragen nach Metadaten, die normalerweise ableitbar sind.
• Verwende eine Erkennung-zuerst-Sprachauswahl:
  • Suche nach README-Sprache, vorhandenen Root-Dokumenten, Kommentaren und Dateibenennungsmustern
  • Wenn eine Sprache stark impliziert ist, beginne dort mit einem Bestätigungston
  • Wenn die Signale schwach oder gemischt sind, stelle die Sprachfrage in einfachem Englisch
• Respektiere das Interviewfragenbudget aus dem Protokoll:
  • Ziele auf 5 oder weniger explizite Fragen für gängige Repos ab
  • Behandle 8 als weiche Obergrenze, die eine Begründung erfordert
• Normalisiere einfache Benutzerantworten in kanonische gespeicherte Werte, bevor du den Zustand schreibst.
• Verwende die kanonischen Normalisierungstabellen in references/interview-protocol.md für project_type, change_posture, approval_policy, verification_policy und communication_tone.
• Verwende die benutzergerichteten Fragenvorlagen aus references/interview-protocol.md, anstatt interne Schemanamen direkt offenzulegen.
• Wähle Formulierungen aus der dreistufigen Vorlagenmatrix des Protokolls basierend auf dem Vertrauensgrad (high, medium, low).
• Wenn das Interview auf Englisch läuft, verwende die englischen Begleitvorlagen des Protokolls anstelle von Ad-hoc-Übersetzungen.
• Passe pro Antwort an, nicht pro Personenlabel: Wechsle zwischen Präzisionsmodus, Klarstellungsmodus und Sicherheitsstandardmodus basierend auf dem tatsächlichen Antwortmuster des Benutzers.
• Halte pending_fields und confirmed_fields als sich nicht überschneidende Mengen normalisiert.
• Behandle vom Repository abgeleitete Vermutungen als temporäre Schlussfolgerungen, bis sie bestätigt sind.
• Wenn bootstrap_status interview_in_progress ist, setze vom aufgezeichneten interview_step fort, anstatt neu zu starten.
• Wenn eine neue Benutzerantwort einen Widerspruch zum dauerhaften Zustand oder zu starken Repository-Signalen erzeugt, bestätige vor dem Überschreiben des Vertrags.
• Setze bootstrap_status nur auf configured, wenn alle erforderlichen dauerhaften Standardwerte bestätigt sind.

Ausgabedateien

Nach Bootstrap, Update oder Reparatur sollte das Zielprojekt Folgendes haben:

• eine schlanke AGENTS.md
• eine schlanke CLAUDE.md
• eine schlanke GEMINI.md
• eine menschenlesbare PROJECT_HARNESS.md
• eine maschinenlesbare, dauerhafte harness-contract.json
• eine maschinenlesbare, flüchtige harness-runtime.json

Ressourcen

• Vorlagen: assets/templates
• Koexistenz: docs/coexistence.md
• Interviewleitfaden: references/interview-guide.md
• Interviewprotokoll: references/interview-protocol.md
• Reparatur- und Validierungsleitfaden: references/repair-validation-guide.md
• Validierungs-Fixtures: assets/fixtures
• Interviewplaner: tools/interview_planner.py — deterministischer Helfer, der Blank-Projekt-Entdeckung, Repository-zuerst-Bestätigung, Wiederaufnahmereihenfolge und Antwortmodusanpassung in Tests und Fixtures festlegt
• Reparatur-Playbook: assets/repair-playbook.md
• Gesundheitscheckliste: assets/healthy-checklist.md
• Beispielausgabe: assets/examples
• Lokales Prüftool: tools/audit-harness.py — überprüft verwaltete Dateien, PROJECT_HARNESS.md-Struktur, Einstiegsschlankheit und Laufzeitinvarianten
• Deterministischer Projektionsgenerator: tools/apply-harness.py — regeneriert PROJECT_HARNESS.md, AGENTS.md, CLAUDE.md und GEMINI.md aus den kanonischen Vertrags-/Laufzeitdateien
• Abschlussprüfung: tools/check-harness-done.py — erfordert erfolgreiche Prüfung, gesunden Laufzeitzustand, vollständig validierte gemeinsame Felder und keine Projektionsabweichung, bevor der Harness als erledigt betrachtet wird
• Diff-sensitiver Leitplankenprüfer: tools/check-sensitive-change.py — leichte pfadbasierte Smoke-Check für Diffs, die Authentifizierung / Berechtigungen / Geheimnisse / Zahlungen / Verschlüsselung / öffentliche API berühren; blockiert nur, wenn die relevanten Regelstärken erzwungen werden
• Positionierung: docs/positioning.md
• Mitwirken: CONTRIBUTING.md
• Optionale UI-Metadaten: agents/openai.yaml, agents/gemini.yaml