gener8v/gener8v.claude-skills.engineering

Entwicklungsbefehle

1. Befehle finden

Nutze die erste Quelle, die eine Antwort gibt. Nenne den Befehl, bevor du ihn ausführst.

1. Repository-Anweisungen: CLAUDE.md, CONTRIBUTING.md, README.md. In einem gener8v Pipeline-Repository listet .gener8v/context.md die Verify-Befehle für jedes Repository.
2. Task-Runner: Makefile, justfile, Taskfile.yml, package.json-Skripte, pyproject.toml-Tool-Abschnitte, tox.ini, noxfile.py.
3. CI-Workflow: .github/workflows/*.yml. Was CI ausführt, definiert, dass „die Tests bestehen“.
4. Ökosystem-Standard: resources/ecosystems.md.

Wenn das Projekt in Containern läuft (compose.yaml, docker-compose.yml, ein Dev-Container), führe die Befehle so im Container aus, wie das Projekt es dokumentiert. Siehe resources/ecosystems.md.

2. Ausführen

• Starte eng: eine Testdatei oder ein Paket. Dann führe die gesamte Suite aus, bevor du berichtest.
• Starte keinen Watch-Modus. Viele Test-Runner watch-en standardmäßig. Nutze die „Einmal ausführen“-Form (resources/ecosystems.md).
• Behalte den Exit-Code, wenn du die Ausgabe kürzt:

  set -o pipefail
  <Befehl> 2>&1 | tail -n 60
  echo "exit=$?"
  

• Starte einen Dev-Server im Hintergrund. Warte, bis seine URL antwortet. Stoppe ihn, wenn du fertig bist.

3. Ergebnis lesen

• Der Exit-Code entscheidet. Text wie „fertig“ bedeutet nicht Erfolg.
• Zähle. Melde bestandene, fehlgeschlagene und übersprungene Tests. Übersprungene, erwartet fehlschlagende und „keine Tests gesammelt“ sind keine Bestandenen.
• Flaky-Tests. Führe einen fehlgeschlagenen Test ein weiteres Mal allein aus. Besteht er, melde ihn als flaky. Verstecke ihn nicht.
• Bereits vorhandene Fehler. Prüfe den Basis-Branch: den letzten CI-Lauf (gh run list --branch <Basis> --limit 3) oder einen Lauf in einem separaten Worktree. Melde diese Fehler als „bereits fehlgeschlagen auf <Basis>“. Nutze sie nicht als Ausrede für eigene Fehler.
• Schwäche keinen Test, damit er besteht. Wenn der Test falsch ist, erkläre warum und ändere ihn in einem separaten, sichtbaren Commit.

4. Daten für UI-Arbeit

Wenn die UI realistische Daten benötigt, folge resources/throwaway-data.md. Die kurze Regel: Seede nur eine Datenbank, die du zu diesem Zweck erstellt hast. Seede niemals die echte, die Standard- oder eine gemeinsam genutzte Datenbank des Projekts.

5. Bericht

Gib den Befehl, den Exit-Code, die Zählungen und den ersten echten Fehler für jeden Fehlschlag an. Wenn du etwas nicht ausgeführt hast (z. B. End-to-End-Tests, die Anmeldedaten benötigen), sage das.

Verwandte Fähigkeiten

• engineering:github-pr-merge und engineering:github-issue-workflow rufen diese Fähigkeit vor einem PR auf.
• engineering:documentation-bootstrap nutzt sie, um die Befehle zu finden, die in der Dokumentation aufgeführt werden müssen.