Transformez n'importe quelle commande CLI en workflow fiable et reproductible

Utilisez le skill Dagu pour créer un workflow de préparation de standup quotidien. Consultez les références de schéma, d'agent de codage et de pièges connus pour la syntaxe correcte. Demandez à l'utilisateur : - Combien de jours en arrière le rapport doit-il couvrir ? (par défaut : 1) - À quelle heure doit-il s'exécuter les jours de semaine ? (par défaut : 8h00) - Quel CLI d'agent de codage IA est installé ? (vérifier claude, codex, gemini, opencode, aider dans cet ordre — utiliser le premier trouvé, ou demander si aucun n'est détecté) Prérequis : gh CLI authentifié (gh auth login), au moins un CLI d'agent de codage IA installé. Le workflow doit : 1. Récupérer l'activité GitHub de l'utilisateur en utilisant gh api graphql avec --jq pour le formatage JSON côté serveur (NE PAS utiliser jq CLI). Récupérer les commits par dépôt (avec messages via REST), les PR fusionnées (avec corps), les PR ouvertes/brouillon mises à jour pendant la période (avec commits récents et horodatages, groupées par dépôt), et les revues. 2. Découvrir automatiquement toutes les organisations à partir de l'activité et tout regrouper par organisation. 3. Pour chaque organisation avec activité, utiliser un sous-DAG en ligne (séparateur ---) pour générer un brouillon de standup oral en utilisant le CLI de l'agent IA de l'utilisateur. Utiliser le modèle le moins cher/plus rapide disponible pour cet agent car c'est une simple tâche de résumé de texte. Ignorer complètement l'appel pour les organisations sans activité afin d'éviter de gaspiller des tokens. 4. La commande de l'agent, le modèle et le prompt de brouillon doivent tous être définis comme variables d'environnement de niveau supérieur (utiliser le multiline YAML | pour le prompt) afin que les utilisateurs puissent facilement changer d'agent ou personnaliser la sortie sans modifier la logique des étapes. 5. Assembler chaque section d'organisation en markdown : brouillon oral, PR fusionnées, PR ouvertes groupées par dépôt avec historique des commits et horodatages, et revues. 6. Combiner toutes les sections d'organisation en un seul rapport sauvegardé dans DAG_DOCS_DIR. 7. Planifier les jours de semaine avec catchup, valeurs par défaut de retry et timeouts sur les étapes d'agent. Important : consultez la référence des pièges connus pour les solutions de contournement. Suivez la référence de l'agent de codage pour la commande non interactive correcte et les flags de modèle pour chaque CLI d'agent.

Utilisez le skill Dagu pour créer un workflow de génération de notes de version. Consultez les références de schéma, d'agent de codage et de pièges connus pour la syntaxe correcte. Demandez à l'utilisateur : - Quel dépôt ? (par défaut : le dépôt courant, détecté via gh repo view --json nameWithOwner) - Quels tags comparer ? (par défaut : dernier tag vs tag précédent, détectés automatiquement) Prérequis : gh CLI authentifié (gh auth login), au moins un CLI d'agent de codage IA installé. Le workflow doit : 1. Résoudre les deux tags git à comparer. Si non spécifiés, détecter automatiquement les tags les plus récents via l'API GitHub. Les produire en JSON afin que les étapes suivantes puissent référencer les champs individuels via un chemin JSON (par ex. ${TAGS.to}). 2. Extraire tous les numéros de PR des commits entre les deux tags en utilisant l'API de comparaison GitHub avec --jq (NE PAS utiliser jq CLI). Produire un numéro de PR par ligne. 3. Pour chaque PR, récupérer les détails via gh api graphql : numéro, titre, login de l'auteur, résumé du corps (environ 300 premiers caractères), labels et closingIssuesReferences (numéro, titre, login de l'auteur). Construire un tableau JSON à partir des résultats. - CRITIQUE : Lors de l'itération sur la sortie d'une étape précédente, NE PAS utiliser "for X in $VAR" — Dagu capture la sortie multiligne dans une seule variable chaîne, donc le découpage par mots ne fonctionne pas. À la place, lire le fichier stdout de l'étape précédente ligne par ligne : `while IFS= read -r line; do ... done < "${prev_step.stdout}"`. Supprimer les caractères non numériques de chaque ligne avec `tr -dc '0-9'` avant de passer à la requête GraphQL. - La chaîne de requête GraphQL de gh utilise des noms de variables préfixés par $ ($owner, $name, $num). Ceux-ci sont sûrs dans les scripts Dagu car Dagu n'étend que les variables ${entre accolades} et les patterns $nomvariable qui correspondent à des variables Dagu définies — les $noms non définis sont préservés tels quels pour le shell. Cependant, passer les variables entières à -F sans guillemets (par ex. -F num=$NUM et non -F num="$NUM") pour que gh les envoie comme entiers, pas comme chaînes. 4. Utiliser une seule étape d'agent IA (détecter automatiquement quel CLI est disponible, utiliser le modèle le moins cher) pour catégoriser chaque PR et formater les notes de version finales. Lui fournir le JSON des détails des PR, le modèle de changelog et le contexte (dépôt, tags, date, propriétaire du dépôt à exclure des contributeurs). 5. Sauvegarder la sortie dans DAG_DOCS_DIR. 6. Utiliser defaults.retry_policy et timeout_sec: 300 sur l'étape d'agent IA. Le modèle de format de changelog DOIT être défini comme variable d'environnement de niveau supérieur en utilisant le multiline YAML (|) afin que les utilisateurs puissent personnaliser la sortie sans modifier la logique des étapes.

Utilisez le skill Dagu pour créer un workflow de nettoyage de texte IA. Consultez les références de schéma, d'agent de codage et de pièges connus pour la syntaxe correcte. Demandez à l'utilisateur : - Veulent-ils traiter un fichier ou coller du texte en ligne ? (supporter les paramètres input_file et input_text) - Combien de tours de réécriture ? (par défaut : 2) - Niveau de rigueur ? (low/medium/high, par défaut : medium) Prérequis : au moins un CLI d'agent de codage IA installé (claude ou gemini). curl pour récupérer la référence Wikipédia. Le workflow comporte 4 étapes : detect_agent, setup, review_loop, finalize. Étape 1 — detect_agent : Produire le chemin complet du binaire (pas seulement le nom) car les scripts Dagu peuvent ne pas avoir le PATH complet de l'utilisateur. Vérifier les emplacements courants comme ~/.local/bin/ en secours. Ajouter PATH: "${HOME}/.local/bin:${PATH}" aux variables d'environnement de niveau supérieur. Étape 2 — setup : - Récupérer la dernière page Wikipédia « Signs of AI Writing » (wikitext brut) via curl. L'URL doit être une variable d'environnement de niveau supérieur pour que les utilisateurs puissent la remplacer. - Préparer le texte d'entrée. Pour input_file, faire un cp. Pour input_text, utiliser `printenv input_text` pour l'écrire de manière sûre dans un fichier — NE PAS utiliser ${input_text} directement dans les scripts car Dagu étend les variables avant l'exécution du shell. Voir le piège printenv. - Écrire toutes les variables d'environnement multilignes/contrôlées par l'utilisateur (WRITING_STYLE, ADDITIONAL_RULES, CHECK_STRICTNESS) dans des fichiers auxiliaires avec un préfixe commun dans DAG_DOCS_DIR. Ces fichiers sont lus par l'étape de boucle et nettoyés dans finalize. Étape 3 — review_loop : Une seule étape de script avec une boucle bash for (PAS repeat_policy, PAS un sous-DAG). La boucle effectue jusqu'à max_rounds itérations : a. Construire un prompt avec la référence wiki, le style (depuis un fichier), la rigueur (depuis un fichier) et le texte actuel. Utiliser un délimiteur heredoc entre guillemets simples (<<'INSTR') pour les instructions système afin que le shell ne les étende pas. b. Appeler l'agent IA (CHECK_MODEL, par ex. sonnet) pour vérifier le texte. Première ligne de la sortie : nombre de problèmes. Lignes restantes : retour par problème avec le format : ISSUE: "<citation>" | SIGN: <catégorie> | FIX: <réécriture>. c. Sauvegarder le retour dans un fichier par tour (par ex. ${P}_feedback_round${ROUND}.txt) pour que finalize puisse l'inclure dans le rapport. d. Extraire le nombre. Si 0, sortir immédiatement (pas de réécriture nécessaire). e. Appeler l'agent IA (REWRITE_MODEL, par ex. opus) pour réécrire. Écrire la sortie directement dans le fichier texte, en écrasant sur place. CRITIQUE : NE PAS référencer les variables d'environnement multilignes comme WRITING_STYLE ou ADDITIONAL_RULES directement dans le script — Dagu les étend avant l'exécution du shell, ce qui peut casser l'analyse. Les lire depuis les fichiers auxiliaires écrits par setup via cat à la place. Seules les variables d'environnement simples (chemins, noms de modèles, nombres) sont sûres à utiliser directement. Étape 4 — finalize : Construire un rapport complet avec : en-tête de métadonnées (date, nombre de mots, rigueur, nombre de problèmes par tour), puis une section « Problèmes trouvés et corrigés » listant tous les retours par tour, puis une section « Texte final » avec le texte réécrit. Nettoyer tous les fichiers auxiliaires y compris les fichiers de retour par tour. Variables d'environnement configurables (toutes de niveau supérieur, facilement personnalisables) : - WRITING_STYLE : instructions multilignes (|) pour le style d'écriture cible - CHECK_STRICTNESS : low/medium/high - CHECK_MODEL : modèle pour la vérification (moins cher, par ex. sonnet) - REWRITE_MODEL : modèle pour la réécriture (qualité, par ex. opus) - ADDITIONAL_RULES : règles supplémentaires au-delà de la référence Wikipédia - WIKI_URL : URL brute Wikipédia (remplaçable) - WIKI_EXCERPT_LINES : combien de lignes du wiki fournir à l'IA Utiliser des paramètres fortement typés (name, type, description, default, minimum, maximum). Important : consultez la référence des pièges connus pour les solutions de contournement. Suivez la référence de l'agent de codage pour la commande non interactive correcte et les flags de modèle.