Verwandeln Sie jeden CLI-Befehl in einen zuverlässigen, wiederholbaren Workflow

Verwende den Dagu-Skill, um einen Workflow zur täglichen Standup-Vorbereitung zu erstellen. Beziehe dich auf die Schema-, Coding-Agent- und Fallstricke-Referenzen für die korrekte Syntax. Frage den Benutzer: - Wie viele Tage zurück soll der Bericht abdecken? (Standard: 1) - Um welche Uhrzeit soll er an Werktagen laufen? (Standard: 8:00 Uhr) - Welche KI-Coding-Agent-CLI ist installiert? (Prüfe in dieser Reihenfolge: claude, codex, gemini, opencode, aider — verwende die erste gefundene, oder frage nach, wenn keine erkannt wird) Voraussetzungen: gh CLI authentifiziert (gh auth login), mindestens eine KI-Coding-Agent-CLI installiert. Der Workflow soll: 1. Die GitHub-Aktivitäten des Benutzers mit gh api graphql und --jq für serverseitige JSON-Formatierung abrufen (NICHT die jq-CLI verwenden). Commits pro Repository (mit Nachrichten über REST), gemergte PRs (mit Body), offene/Draft-PRs, die im Zeitraum aktualisiert wurden (mit aktuellen Commits und Zeitstempeln, gruppiert nach Repository), und Reviews abrufen. 2. Automatisch alle Organisationen aus der Aktivität erkennen und alles nach Organisation gruppieren. 3. Für jede Organisation mit Aktivität einen Inline-Sub-DAG (--- Trennzeichen) verwenden, um mit der KI-Agent-CLI einen gesprochenen Standup-Entwurf zu generieren. Das günstigste/schnellste verfügbare Modell für den jeweiligen Agenten verwenden, da es sich um eine einfache Textzusammenfassung handelt. Den Aufruf für Organisationen ohne Aktivität komplett überspringen, um Token zu sparen. 4. Den Agent-Befehl, das Modell und den Entwurfs-Prompt als Top-Level-Umgebungsvariablen definieren (YAML-Mehrzeilenformat | für den Prompt verwenden), damit Benutzer einfach Agenten wechseln oder die Ausgabe anpassen können, ohne die Schrittlogik zu bearbeiten. 5. Jeden Organisationsabschnitt als Markdown zusammenstellen: gesprochener Entwurf, gemergte PRs, offene PRs gruppiert nach Repository mit Commit-Verlauf und Zeitstempeln, und Reviews. 6. Alle Organisationsabschnitte zu einem einzigen Bericht zusammenfügen und in DAG_DOCS_DIR speichern. 7. An Werktagen mit Catchup, Standard-Wiederholungsversuchen und Timeouts für Agent-Schritte planen. Wichtig: Die Fallstricke-Referenz auf bekannte Workarounds prüfen. Der Coding-Agent-Referenz für den korrekten nicht-interaktiven Befehl und die Modell-Flags jeder Agent-CLI folgen.

Verwende den Dagu-Skill, um einen Workflow zur Generierung von Release-Notes zu erstellen. Beziehe dich auf die Schema-, Coding-Agent- und Fallstricke-Referenzen für die korrekte Syntax. Frage den Benutzer: - Welches Repository? (Standard: das aktuelle Repository, erkannt über gh repo view --json nameWithOwner) - Welche Tags sollen verglichen werden? (Standard: neuester Tag vs. vorheriger Tag, automatisch erkannt) Voraussetzungen: gh CLI authentifiziert (gh auth login), mindestens eine KI-Coding-Agent-CLI installiert. Der Workflow soll: 1. Die beiden zu vergleichenden Git-Tags auflösen. Falls nicht angegeben, die neuesten und vorherigen Tags automatisch über die GitHub-API erkennen. Als JSON ausgeben, damit nachfolgende Schritte einzelne Felder über JSON-Pfad referenzieren können (z.B. ${TAGS.to}). 2. Alle PR-Nummern aus Commits zwischen den beiden Tags mit der GitHub-Compare-API und --jq extrahieren (NICHT die jq-CLI verwenden). Eine PR-Nummer pro Zeile ausgeben. 3. Für jeden PR Details über gh api graphql abrufen: Nummer, Titel, Autor-Login, Body-Zusammenfassung (erste ~300 Zeichen), Labels und closingIssuesReferences (Nummer, Titel, Autor-Login). Ein JSON-Array aus den Ergebnissen erstellen. - KRITISCH: Beim Iterieren über die Ausgabe eines vorherigen Schritts NICHT "for X in $VAR" verwenden — Dagu erfasst mehrzeilige Ausgaben in einer einzelnen String-Variable, daher funktioniert Wort-Splitting nicht. Stattdessen die stdout-Datei des vorherigen Schritts Zeile für Zeile lesen: `while IFS= read -r line; do ... done < "${prev_step.stdout}"`. Nicht-numerische Zeichen mit `tr -dc '0-9'` aus jeder Zeile entfernen, bevor sie an die GraphQL-Abfrage übergeben werden. - Der gh-GraphQL-Abfragestring verwendet $-präfixierte Variablennamen ($owner, $name, $num). Diese sind in Dagu-Skripten sicher, da Dagu nur ${geklammerte} Variablen und bare $varname-Muster expandiert, die definierten Dagu-Variablen entsprechen — undefinierte bare $names werden unverändert für die Shell beibehalten. Ganzzahlige Variablen jedoch ohne Anführungszeichen an -F übergeben (z.B. -F num=$NUM, nicht -F num="$NUM"), damit gh sie als Ganzzahlen und nicht als Strings sendet. 4. Einen einzelnen KI-Agent-Schritt verwenden (automatisch erkennen, welche CLI verfügbar ist, das günstigste Modell verwenden), um jeden PR zu kategorisieren und die endgültigen Release-Notes zu formatieren. Die PR-Details als JSON, die Changelog-Vorlage und den Kontext (Repository, Tags, Datum, Repository-Besitzer zum Ausschluss aus den Mitwirkenden) übergeben. 5. Die Ausgabe in DAG_DOCS_DIR speichern. 6. defaults.retry_policy und timeout_sec: 300 für den KI-Agent-Schritt verwenden. Die Changelog-Formatvorlage MUSS als Top-Level-Umgebungsvariable mit YAML-Mehrzeilenformat (|) definiert werden, damit Benutzer die Ausgabe anpassen können, ohne die Schrittlogik zu bearbeiten.

Verwende den Dagu-Skill, um einen Workflow zur KI-Text-Bereinigung zu erstellen. Beziehe dich auf die Schema-, Coding-Agent- und Fallstricke-Referenzen für die korrekte Syntax. Frage den Benutzer: - Soll eine Datei verarbeitet oder Text direkt eingefügt werden? (Unterstützung für sowohl input_file als auch input_text Parameter) - Wie viele Überarbeitungsrunden? (Standard: 2) - Strenge-Stufe? (low/medium/high, Standard: medium) Voraussetzungen: mindestens eine KI-Coding-Agent-CLI installiert (claude oder gemini). curl zum Abrufen der Wikipedia-Referenz. Der Workflow hat 4 Schritte: detect_agent, setup, review_loop, finalize. Schritt 1 — detect_agent: Den vollständigen Binärpfad ausgeben (nicht nur den Namen), da Dagu-Skripte möglicherweise nicht den vollständigen PATH des Benutzers haben. Gängige Speicherorte wie ~/.local/bin/ als Fallback prüfen. PATH: "${HOME}/.local/bin:${PATH}" zu den Top-Level-Umgebungsvariablen hinzufügen. Schritt 2 — setup: - Die neueste Wikipedia-Seite "Signs of AI Writing" (Roh-Wikitext) über curl abrufen. Die URL sollte eine Top-Level-Umgebungsvariable sein, damit Benutzer sie austauschen können. - Den Eingabetext vorbereiten. Bei input_file mit cp kopieren. Bei input_text `printenv input_text` verwenden, um ihn sicher in eine Datei zu schreiben — NICHT ${input_text} direkt in Skripten verwenden, da Dagu Variablen vor der Shell-Ausführung expandiert. Siehe den printenv-Fallstrick. - Alle mehrzeiligen/benutzergesteuerten Umgebungsvariablen (WRITING_STYLE, ADDITIONAL_RULES, CHECK_STRICTNESS) in Hilfsdateien mit gemeinsamem Präfix in DAG_DOCS_DIR schreiben. Diese Dateien werden vom Schleifenschritt gelesen und im Finalisierungsschritt bereinigt. Schritt 3 — review_loop: Ein einzelner Skript-Schritt mit einer Bash-for-Schleife (NICHT repeat_policy, NICHT ein Sub-DAG). Die Schleife läuft bis zu max_rounds Iterationen: a. Einen Prompt mit der Wiki-Referenz, dem Stil (aus Datei), der Strenge (aus Datei) und dem aktuellen Text erstellen. Ein Heredoc-Trennzeichen in einfachen Anführungszeichen (<<'INSTR') für die Systemanweisungen verwenden, damit die Shell sie nicht expandiert. b. Den KI-Agenten aufrufen (CHECK_MODEL, z.B. sonnet), um den Text zu prüfen. Erste Zeile der Ausgabe: Anzahl der Probleme. Restliche Zeilen: Feedback pro Problem im Format: ISSUE: "<Zitat>" | SIGN: <Kategorie> | FIX: <Umschreibung>. c. Das Feedback in einer Datei pro Runde speichern (z.B. ${P}_feedback_round${ROUND}.txt), damit der Finalisierungsschritt es in den Bericht aufnehmen kann. d. Die Anzahl extrahieren. Bei 0 sofort abbrechen (keine Umschreibung nötig). e. Den KI-Agenten aufrufen (REWRITE_MODEL, z.B. opus) zum Umschreiben. Die Ausgabe direkt in die Textdatei schreiben und vor Ort überschreiben. KRITISCH: Mehrzeilige Umgebungsvariablen wie WRITING_STYLE oder ADDITIONAL_RULES NICHT direkt im Skript referenzieren — Dagu expandiert sie vor der Shell-Ausführung, was das Parsing unterbrechen kann. Stattdessen aus den vom Setup geschriebenen Hilfsdateien über cat lesen. Nur einfache Umgebungsvariablen (Pfade, Modellnamen, Zahlen) können direkt verwendet werden. Schritt 4 — finalize: Einen vollständigen Bericht erstellen mit: Metadaten-Header (Datum, Wortanzahlen, Strenge, Problemanzahl pro Runde), dann ein Abschnitt "Gefundene und behobene Probleme" mit dem gesamten Feedback pro Runde, dann ein Abschnitt "Endgültiger Text" mit dem umgeschriebenen Text. Alle Hilfsdateien einschließlich der Feedback-Dateien pro Runde bereinigen. Umgebungsvariablen-Einstellungen (alle auf Top-Level, einfach anpassbar): - WRITING_STYLE: mehrzeilig (|) Anweisungen zum Ziel-Schreibstil - CHECK_STRICTNESS: low/medium/high - CHECK_MODEL: Modell zum Prüfen (günstiger, z.B. sonnet) - REWRITE_MODEL: Modell zum Umschreiben (Qualität, z.B. opus) - ADDITIONAL_RULES: zusätzliche Regeln über die Wikipedia-Referenz hinaus - WIKI_URL: Wikipedia-Roh-URL (austauschbar) - WIKI_EXCERPT_LINES: wie viele Zeilen des Wikis der KI zugeführt werden Stark typisierte Parameter verwenden (name, type, description, default, minimum, maximum). Wichtig: Die Fallstricke-Referenz auf bekannte Workarounds prüfen. Der Coding-Agent-Referenz für den korrekten nicht-interaktiven Befehl und die Modell-Flags folgen.