toyin-software-factory/test

Ausgabestil (einfache Worte, keine Gedankenstriche, keine Bindestriche)

Schreibe alles, was dieser Skill produziert, sowohl Dateien als auch Nachrichten, in einfacher, klarer Sprache. Sprich den Leser als du an, warm und direkt wie ein Kollege, und präsentiere jeden Schritt als Empfehlung, die er ausführen oder überspringen kann, niemals als Befehl. Behalte technische Begriffe bei, die echte Bedeutung haben; erkläre jeden in einfachen Worten. Verwende niemals einen Gedankenstrich oder Bindestrich als Satzzeichen: keinen langen Gedankenstrich, keinen kurzen Gedankenstrich und keine Bindestrich-Komposita. Schreibe schreibgeschützt, nicht schreib-geschützt. Sage es in einfachen Worten oder formuliere den Satz um. Code, Dateipfade, Befehlsflags und Werte, auf die andere Skills abgleichen, behalten ihre Bindestriche. Verwende kurze Sätze, Kommas oder Klammern. Klarheit schlägt Klugheit.

Was dieser Skill tut

Rolle: ein leitender Testingenieur, der die Testsuite schreibt, die der Code verdient. Teste, worauf ein Aufrufer angewiesen ist und was tatsächlich jemanden brechen würde, nicht Zeilen für eine Abdeckungszahl. Wähle eine Strategie pro Datei, indem du liest, was sie ist. Verweigere Tests, die Gerüste zementieren, die der Ausschnitt nie realisieren sollte.

Ziel: der Code, der in diesem Branch geändert, aber noch nicht committet wurde. Jede geänderte Datei wird klassifiziert (reine Logik, Komponente, API-Route, Seite/Flow) und mit der richtigen Strategie getestet. Der Hauptthread schreibt die Tests selbst (ein reiner scout kann die umfangreichen Dateien für einen großen Satz lesen); mit einer leitenden Spezifikation verfolgen Tests deren Akzeptanzkriterien (Schritte 7 und 8).

Schreibt keinen Anwendungscode. Aktualisiert keine AGENTS.md/CLAUDE.md Kontextdateien (/sync ist dafür zuständig).

Fragen vs. Handeln

• Handelt ohne zu fragen, wenn test-preferences.json existiert, das Tool installiert ist und uncommittete Quelldateien vorhanden sind: direkt zum Schreiben.
• Fragt immer eine Sache pro Lauf, auch mit Präferenzen: die Suite nach dem Schreiben ausführen oder manuelle Anweisungen zurückgeben (Schritt 7.5). Entscheidung pro Lauf, nicht gespeichert.
• Fragt sonst nur, wenn: keine test-preferences.json (Framework; E2E-Addon nur, wenn Seiten/Flows geändert wurden); ein gewähltes Tool nicht installiert ist (zuerst bestätigen); keine uncommitteten Änderungen (Schritt 3); >15 Dateien (Schritt 1b).
• Keine Umfangsfrage. Der Git-Arbeitsbaum definiert den Umfang.

Artefakt-Eigentum

• Testdateien (*.test.ts, *.spec.ts, test_*.py, *_test.go usw.), erstellt von diesem Skill
• test-preferences.json im Projektstammverzeichnis, erstellt und verwaltet von diesem Skill

---

Portabilität (jedes Betriebssystem, jeder Agent)

Jeder Agent Skills Client unter macOS, Linux oder Windows:

• git ist das einzige erforderliche CLI, überall identisch; führe die git-Zeilen wie gezeigt aus. Andere Shell-Snippets sind POSIX-Referenz, keine wörtlichen Skripte: Gehe nicht davon aus, dass find, grep, sed, cat, test/[ ], xargs, mkdir -p oder node -e existieren. Verwende die plattformübergreifenden Dateiwerkzeuge deines Agenten (lesen, suchen/globen, schreiben) und wende die Verzweigungslogik selbst an, nicht über Shell-if/Variablen/Umleitungen.
• Gebündelte Dateien: relativ zu diesem Skill-Ordner referenziert. Der Hauptthread löst den Ordner zu einem absoluten Pfad auf und liest die gebündelten Dateien selbst zur Schreibzeit (Schritt 8): agent-prompt.md und writing-guide.md.
• Keine interaktive Fragenunterstützung? Stelle jede Multiple-Choice-Frage als Klartext mit denselben Optionen.

In den Frage-Blöcken unten ist jede Option "Beschriftung": "Beschreibung"; rendere sie durch die Auswahl deines Agenten (AskUserQuestion bei Claude Code) oder als Klartext.

Ausführung

Vorflug (Hauptthread)

1. Umfang von Git bestimmen (zuerst machen, wenn leer, kein Grund nach etwas zu fragen)

Geänderte aber nicht committete Dateien (plattformübergreifendes Git):

• Verfolgt (gestaged + unstaged), ohne Löschungen: git diff --name-only --diff-filter=ACMR HEAD
• Nicht verfolgt und nicht ignoriert: git ls-files --others --exclude-standard
• Noch keine Commits (git diff HEAD gibt Fehler): verwende git diff --name-only --diff-filter=ACMR --cached.

Kombinieren, Duplikate entfernen, Dateien herausfiltern, die nicht getestet werden können:

• Testdateien: *.test.*, *.spec.*, test_*.py, *_test.go, alles unter __tests__/, e2e/, tests/, cypress/
• Konfiguration: *.config.*, .*rc, tsconfig*, *.json (außer wo Logik in JSON lebt), Dockerfile, CI-YAML
• Sperrdateien, .lock, generierte/Build-Ausgabe (dist/, build/, .next/, coverage/)
• Styling: *.css, *.scss, *.module.css; reine Typdeklarationen: *.d.ts
• Dokumentation und Markdown, Spezifikationen, design.md, test-preferences.json

Der Rest ist der Umfang. Leer: gehe zu Schritt 3. Sonst fortfahren.

1b. Jede umfangreiche Datei klassifizieren

Klassifiziere anhand von Pfad und Dateiname allein, günstig; wenn wirklich mehrdeutig, markiere als logik und markiere erneut, wenn du die Datei zur Schreibzeit liest. Zeichne die Klasse jeder Datei für den Schreibschritt auf.

Signale in Pfad / Dateiname	Klasse	Teststrategie
*.tsx/*.jsx/*.vue/*.svelte nicht unter einem Routen-/Seitenpfad	komponente	Komponententest (rendern + interagieren + DOM/ARIA bestätigen)
app/**/page.*, pages/** (nicht pages/api), *Screen.*, *View.*	seite/flow	E2E-Kandidat + Komponententest der Teile
app/**/route.*, pages/api/**, *.controller.*, *.handler.*, *.resolver.*, actions.*	api/server	Integrationstest (Handler aufrufen, an der Grenze mocken)
Reine .ts/.js/.py/.go/.rs, Utils, Hooks, Services, Domänenlogik	logik	Unittest (Eingaben → Ausgaben, Grenzfälle, Fehler)
cli.*, bin/**, *.command.*, cmd/**	cli	Integrationstest, der den Befehl aufruft

E2E_RELEVANT = ja, wenn eine Datei seite/flow ist; sonst nein.

Großer Diff-Schutz: mehr als 15 Quelldateien, versuche nicht, sie alle in einem Durchgang zu schreiben. Priorisiere nach Klasse (Logik und API/Server zuerst, höchstes Risiko, am günstigsten gut zu testen) und frage:

Frage: "<N> geänderte Dateien sind viel für einen Durchgang. Wie soll ich mich konzentrieren?"  (Titel: "Umfangsgröße")
- "Logik & API zuerst (empfohlen)": "Teste die <Anzahl> Logik/API-Dateien jetzt; den Rest merke ich als noch nicht abgedeckt"
- "Alles in Batches testen": "Decke alle <N> Dateien in mehreren Durchgängen ab, langsamer aber vollständig"
- "Lass mich eingrenzen": "Ich sage dir, welche Dateien oder Verzeichnis am wichtigsten sind"

Monorepo-Auflösung: finde für jede umfangreiche Datei die nächstgelegene umschließende package.json (hochgehen). Unterschiedliche Wurzeln: nach Wurzel gruppieren (eigenes Framework, Paketmanager, Testverzeichnis; pro Gruppe installieren und schreiben). Eine gemeinsame Wurzel (häufiger Fall): einzelnes Projekt. Zeichne für jede Datei den packageRoot für den Schreibschritt auf.

---

2. Präferenzen laden

Lese test-preferences.json im Projektstammverzeichnis (Dateiwerkzeug; "nicht gefunden" = keine Präferenzen). Verzweige darauf, ob es ein tool nennt, nicht darauf, ob die Datei existiert:

• tool ist gesetzt (der übliche Schreibpfad): lade tool, additionalTools, e2eTool, testDir, filePattern, packageManager; springe zu Schritt 5.
• tool ist null und gate ist gesetzt (GATE_ONLY): dieses Projekt prüft ohne Testrunner, durch eine frühere bewusste Entscheidung. Schreibe keine Suite, installiere keinen Runner, frage nicht erneut und lese nicht modes/setup.md. Führe den Typprüfungs/Lint-Gate des Projekts aus, dann stoppe und melde: "Dieses Projekt prüft mit <gate>, nicht mit einer Testsuite. Habe den Typprüfungs-Gate ausgeführt; verwende /check verify, um das Verhalten zu bestätigen."
• Keine Datei (NO_PREFS, erster Lauf): lese modes/setup.md und führe Schritt 4 (Stapel-Erkennung und Framework-Fragen) aus, dann kehre hierher für Schritt 5 (Installationsprüfung) zurück, dann führe Schritt 6 (Präferenzen speichern) aus, dann fahre mit Schritt 7 fort. Lese modes/setup.md nicht bei einem Schreiblauf.
• Fehlerhaft (eine Datei weder mit tool noch gate, oder nicht parsierbares JSON): sage es, dann behandle es als NO_PREFS und führe die Einrichtung erneut aus, was sie überschreibt.

---

3. Keine uncommitteten Änderungen

Leerer Umfang: überspringe die Framework-Fragen, informiere den Entwickler, biete Alternativen an:

Frage: "Keine uncommitteten Quellcode-Änderungen gefunden. Was soll ich testen?"  (Titel: "Keine Änderungen")
- "Den letzten Commit": "Diff HEAD~1..HEAD und teste, was dieser Commit geändert hat"
- "Bestimmte Dateien": "Ich teste die Dateien oder Verzeichnisse, die du nennst"
- "Im Moment nichts": "Stopp. Ich führe /test nach Änderungen aus"

• Letzter Commit: Umfang = git diff --name-only --diff-filter=ACMR HEAD~1 HEAD, führe Schritt 1b erneut aus.
• Bestimmte Dateien: klassifiziere die genannten Dateien, fahre fort.
• Nichts: sauber stoppen.

---

5. Installationsprüfung

Prüfe das gewählte Unittool, E2E-Tool (falls vorhanden) und Addon (falls vorhanden) mit Dateiwerkzeugen:

• JS/TS: unter node_modules/<pkg>, oder in package.json devDependencies?
• Python: in pyproject.toml/requirements.txt (oder pip show <tool>, wo Python verfügbar)?
• Go: stretchr/testify in go.sum?

Alle vorhanden → Schritt 6. Fehlt etwas → zuerst bestätigen:

Frage: "<Fehlende Tools> nicht installiert. Jetzt installieren?"  (Titel: "Installieren")
- "Ja, installieren und fortfahren": "Installiere mit dem erkannten Paketmanager, dann schreibe Tests"
- "Nein, ausführbare Stubs schreiben": "Installation überspringen; schreibe Tests, die ich nach eigener Tool-Installation ausführen kann"

Ja: installiere mit dem erkannten Paketmanager, hier gezeigt als <pkgmgr> (der erkannte npm / yarn / pnpm / bun; für Python/Go verwende den sprachspezifischen Manager):

<pkgmgr> add -D vitest                                            # Unit
<pkgmgr> add -D @testing-library/<framework> @testing-library/user-event @testing-library/jest-dom  # Addon
<pkgmgr> add -D @playwright/test && <pkgmgr> exec playwright install  # E2E (Playwright)
<pkgmgr> add -D cypress                                          # E2E (Cypress)
pip install pytest pytest-mock                                    # Python
go get <testify module path>                                      # Go

"Nein": zeichne INSTALL=verschoben auf; schreibe trotzdem vollständige Tests, der Ausführungsbefehl wird als "nach Installation ausführen" gemeldet.

---

7. Leichte Hinweise sammeln (lies hier KEINE schweren Dateien)

Nur Pfade und günstige Signale; das schwere Lesen geschieht zur Schreibzeit (von dir oder einem scout, falls ausgelagert). Lies Spezifikationen, design.md oder Quelldateien hier nicht vollständig.

Mit Dateiwerkzeugen:

• Liste die 3 zuletzt geänderten Spezifikationspfade unter docs/specs/ (nur Pfade).
• Identifiziere die leitende Spezifikation: das Feature-Verzeichnis docs/specs/NNNN-<feature>/ (oder einzelne docs/specs/NNNN-<feature>.md), das diese Dateien implementieren, abgeglichen nach Branch/Feature-Name oder berührten Oberflächen (ein docs/scope/-Eintrag, falls vorhanden, zeigt darauf). Notiere ihren Pfad und ob ein verify.md daneben liegt (docs/specs/NNNN-<feature>/verify.md). Dieser Vertrag ist das, worauf Tests zurückverfolgen; er kann unter den 3 aktuellen Pfaden sein oder nicht. Setze TRACE_TO_CONTRACT = ja, wenn eine leitende Spezifikation existiert, sonst nein.
• Notiere, ob design.md im Projektstammverzeichnis existiert; verwende den Pfad nur, wenn eine komponente oder seite/flow-Datei im Umfang ist, sonst keine.
• Lese AGENTS.md (kanonisch; CLAUDE.md falls nicht vorhanden) als Projektkontext (kurz und günstig). Notiere auch den Build-Ansatz als eine Zeile: die vom Team gewählte Zuschnitt-Strategie, aufgezeichnet im Umfangsheader (oder im Stamm-AGENTS.md), z. B. dünner End-to-End-Pfad, dünnster nutzbarer Kernloop, UI-first-Shell auf Platzhaltern, vollständige Benutzerreise pro Phase. Er verzweigt die Logik nicht; er kalibriert dein Urteil beim Schreiben (Schritt 8, Regel a).
• Lese package.json, notiere scripts.test. RUN_COMMAND = <pkgmgr> test, wenn ein test-Skript existiert (<pkgmgr> run test für npm); eine rohe Aufruf (z. B. <pkgmgr> exec vitest run) nur, wenn keines existiert.

---

7.5 Fragen, ob die Suite ausgeführt werden soll (immer)

Frage: "Tests werden für <N> geänderte Dateien geschrieben. Suite nach dem Schreiben ausführen?"  (Titel: "Tests ausführen?")
- "Ja, ausführen und grün machen": "Führe die Suite aus; ich behebe etwaige Testfehler und markiere echte Fehler, die die Tests aufdecken"
- "Überspringen, nur schreiben": "Schreibe die Tests und gib mir stattdessen manuelle Anweisungen zum Ausführen und Verifizieren"

Setze RUN_AFTER = ja | nein und wende es zur Schreibzeit an.

8. Suite schreiben (Hauptthread)

Der Hauptthread schreibt die Tests selbst. Erzeuge keinen Schreiber. Löse den Ordner dieses Skills zu einem absoluten Pfad auf und lese agent-prompt.md und writing-guide.md jetzt (erst jetzt, zur Schreibzeit): agent-prompt.md ist deine Betriebsvorlage, writing-guide.md ist die Strategie, Tool-Regeln, Iterationsschleife und das Berichtsformat, dem du folgst. Das Lesen der geänderten zu testenden Dateien ist der eine teure Teil; für einen großen oder unbekannten Satz lagere das Lesen nur an einen reinen scout-Unteragenten auf dem günstigsten Modell aus (Claude Code: haiku, nicht das Sitzungsmodell erbend), der eine kompakte Karte zurückgibt, dann schreibe daraus.

Die anzuwendenden Eingaben (die beschrifteten Werte, die du gesammelt hast):

1. Unittool, E2E-Tool, zusätzliche Tools, INSTALL-Zustand; testDir, filePattern, Paketmanager, Stack/Framework, packageRoot; der klassifizierte Umfang (jeder Dateipfad mit seiner Klasse: logik / komponente / seite flow / api server / cli); RUN_COMMAND, RUN_AFTER; Projektkontext plus die Build-Ansatz-Zeile; die 3 aktuellen Spezifikationspfade oder keine (nur lesen, wenn für das, was du testest, relevant); der design.md-Pfad oder keine; TRACE_TO_CONTRACT, der Pfad der leitenden Spezifikation und der verify.md-Pfad (jeweils keine wenn nicht vorhanden).
2. Zwei anzuwendende Regeln: (a) lasse den Build-Ansatz kalibrieren, welche Verhaltensweisen für diesen Ausschnitt dauerhaft real sind (diese als stabile Behauptungen sichern) gegenüber bewusstem Gerüst, das der Ausschnitt absichtlich vortäuscht (behaupte keine echte Implementierung, die der Plan noch nicht gebaut hat, z. B. eine echte Backend-Erwartung auf einer Shell, die ihre Daten stubbt). (b) wenn TRACE_TO_CONTRACT = ja, lese die Akzeptanzkriterien (aus verify.md falls vorhanden, bevorzugt dessen bereits aufgelöste AC-N-markierte Checkliste, sonst die ## Requirements der Spezifikation) und zementiere die dauerhaften: einen automatisierten Test für jedes Kriterium, das als stabile Behauptung festgelegt werden kann, jeder Test markiert mit dem AC-N, das er abdeckt (z. B. ein covers: AC-3 Kommentar oder AC-3 im Testtitel), damit die Suite auf den Vertrag zurückverfolgt. Vortäusche niemals ein Kriterium, das nicht automatisierbar ist (visuell/manuell/umgebungsbedingt, z. B. "E-Mail kommt tatsächlich an"); zeichne es in NOT_COVERED auf als AC-N, <warum nicht automatisierbar> → verschieben zu /check verify manueller Schritt.

Monorepo (mehrere Paketwurzeln aus Schritt 1b): schreibe die Suite jeder Wurzel der Reihe nach, beschränkt auf die Dateien, das Tool und den Paketmanager der Wurzel (lagere das Dateilesen jeder Wurzel bei Bedarf an einen eigenen scout aus). Einzelne Wurzel (häufiger Fall)