Convierte cualquier comando CLI en un flujo de trabajo fiable y repetible

Usa el skill de Dagu para crear un flujo de trabajo de preparación de standup diario. Consulta las referencias de schema, coding agent y pitfalls para la sintaxis correcta. Pregunta al usuario: - ¿Cuántos días atrás debe cubrir el informe? (por defecto: 1) - ¿A qué hora debe ejecutarse en días laborables? (por defecto: 8:00 AM) - ¿Qué CLI de agente de codificación IA tienen instalado? (buscar claude, codex, gemini, opencode, aider en ese orden — usar el primero encontrado, o preguntar si no se detecta ninguno) Requisitos previos: gh CLI autenticado (gh auth login), al menos un CLI de agente de codificación IA instalado. El flujo de trabajo debe: 1. Obtener la actividad de GitHub del usuario usando gh api graphql con --jq para formato JSON del lado del servidor (NO usar jq CLI). Obtener commits por repositorio (con mensajes vía REST), PRs fusionados (con cuerpo), PRs abiertos/borrador actualizados en el período (con commits recientes y marcas de tiempo, agrupados por repositorio), y revisiones. 2. Auto-descubrir todas las organizaciones de la actividad y agrupar todo por organización. 3. Para cada organización con actividad, usar un sub-DAG en línea (separador ---) para generar un borrador de standup hablado usando el CLI del agente de IA del usuario. Usar el modelo más económico/rápido disponible para ese agente ya que es una tarea simple de resumen de texto. Omitir la llamada completamente para organizaciones sin actividad para no desperdiciar tokens. 4. El comando del agente, modelo y prompt del borrador deben definirse como variables de entorno de nivel superior (usar YAML multilínea | para el prompt) para que los usuarios puedan cambiar fácilmente de agente o personalizar la salida sin editar la lógica de los pasos. 5. Ensamblar cada sección de organización como markdown: borrador hablado, PRs fusionados, PRs abiertos agrupados por repositorio con historial de commits y marcas de tiempo, y revisiones. 6. Combinar todas las secciones de organizaciones en un único informe guardado en DAG_DOCS_DIR. 7. Programar en días laborables con catchup, valores predeterminados de reintentos y timeouts en los pasos del agente. Importante: revisar la referencia de pitfalls para soluciones conocidas. Seguir la referencia de coding agent para el comando no interactivo correcto y las flags de modelo para cada CLI de agente.

Usa el skill de Dagu para crear un flujo de trabajo generador de notas de versión. Consulta las referencias de schema, coding agent y pitfalls para la sintaxis correcta. Pregunta al usuario: - ¿Qué repositorio? (por defecto: el repositorio actual, detectado vía gh repo view --json nameWithOwner) - ¿Qué tags comparar? (por defecto: último tag vs tag anterior, auto-detectados) Requisitos previos: gh CLI autenticado (gh auth login), al menos un CLI de agente de codificación IA instalado. El flujo de trabajo debe: 1. Resolver los dos tags de git a comparar. Si no se especifican, auto-detectar el último y el anterior usando la API de GitHub. Generarlos como JSON para que los pasos posteriores puedan referenciar campos individuales vía JSON path (ej. ${TAGS.to}). 2. Extraer todos los números de PR de los commits entre los dos tags usando la API de comparación de GitHub con --jq (NO usar jq CLI). Generar un número de PR por línea. 3. Para cada PR, obtener detalles vía gh api graphql: número, título, login del autor, resumen del cuerpo (primeros ~300 caracteres), etiquetas y closingIssuesReferences (número, título, login del autor). Construir un array JSON con los resultados. - CRÍTICO: Al iterar sobre la salida de un paso anterior, NO usar "for X in $VAR" — Dagu captura la salida multilínea en una sola variable string, por lo que la división por palabras no funciona. En su lugar, leer el archivo stdout del paso anterior línea por línea: `while IFS= read -r line; do ... done < "${prev_step.stdout}"`. Eliminar caracteres no numéricos de cada línea con `tr -dc '0-9'` antes de pasar a la consulta GraphQL. - La cadena de consulta GraphQL de gh usa nombres de variable con prefijo $ ($owner, $name, $num). Estos son seguros en scripts de Dagu porque Dagu solo expande variables ${con llaves} y patrones bare $varname que coincidan con variables Dagu definidas — los nombres bare $undefined se preservan tal cual para el shell. Sin embargo, pasar variables enteras a -F sin comillas (ej. -F num=$NUM no -F num="$NUM") para que gh las envíe como enteros, no strings. 4. Usar un único paso de agente IA (auto-detectar qué CLI está disponible, usar el modelo más económico) para categorizar cada PR y formatear las notas de versión finales. Alimentarlo con el JSON de detalles de PRs, la plantilla de changelog y contexto (repositorio, tags, fecha, propietario del repositorio a excluir de contribuidores). 5. Guardar la salida en DAG_DOCS_DIR. 6. Usar defaults.retry_policy y timeout_sec: 300 en el paso del agente IA. La plantilla de formato del changelog DEBE definirse como una variable de entorno de nivel superior usando YAML multilínea (|) para que los usuarios puedan personalizar la salida sin editar la lógica de los pasos.

Usa el skill de Dagu para crear un flujo de trabajo de limpieza de texto IA. Consulta las referencias de schema, coding agent y pitfalls para la sintaxis correcta. Pregunta al usuario: - ¿Quieren procesar un archivo o pegar texto en línea? (soportar ambos parámetros input_file e input_text) - ¿Cuántas rondas de reescritura? (por defecto: 2) - ¿Nivel de rigurosidad? (low/medium/high, por defecto: medium) Requisitos previos: al menos un CLI de agente de codificación IA instalado (claude o gemini). curl para obtener la referencia de Wikipedia. El flujo de trabajo tiene 4 pasos: detect_agent, setup, review_loop, finalize. Paso 1 — detect_agent: Generar la ruta completa del binario (no solo el nombre) ya que los scripts de Dagu pueden no tener el PATH completo del usuario. Verificar ubicaciones comunes como ~/.local/bin/ como respaldo. Agregar PATH: "${HOME}/.local/bin:${PATH}" al env de nivel superior. Paso 2 — setup: - Obtener la última página de Wikipedia "Signs of AI Writing" (wikitext sin procesar) vía curl. La URL debe ser una variable de entorno de nivel superior para que los usuarios puedan cambiarla. - Preparar el texto de entrada. Para input_file, usar cp. Para input_text, usar `printenv input_text` para escribirlo de forma segura en un archivo — NO usar ${input_text} directamente en scripts porque Dagu expande las variables antes de que el shell se ejecute. Ver el pitfall de printenv. - Escribir todas las variables de entorno multilínea/controladas por el usuario (WRITING_STYLE, ADDITIONAL_RULES, CHECK_STRICTNESS) en archivos auxiliares con un prefijo común en DAG_DOCS_DIR. Estos archivos son leídos por el paso del bucle y limpiados en finalize. Paso 3 — review_loop: Un único paso de script con un bucle for de bash (NO repeat_policy, NO un sub-DAG). El bucle ejecuta hasta max_rounds iteraciones: a. Construir un prompt con la referencia wiki, estilo (desde archivo), rigurosidad (desde archivo) y texto actual. Usar un delimitador heredoc entre comillas simples (<<'INSTR') para las instrucciones del sistema para que el shell no las expanda. b. Llamar al agente IA (CHECK_MODEL, ej. sonnet) para revisar el texto. Primera línea de salida: conteo de problemas. Líneas restantes: retroalimentación por problema con formato: ISSUE: "<cita>" | SIGN: <categoría> | FIX: <reescritura>. c. Guardar la retroalimentación en un archivo por ronda (ej. ${P}_feedback_round${ROUND}.txt) para que finalize pueda incluirlo en el informe. d. Extraer el conteo. Si es 0, interrumpir inmediatamente (no se necesita reescritura). e. Llamar al agente IA (REWRITE_MODEL, ej. opus) para reescribir. Escribir la salida directamente al archivo de texto, sobrescribiendo en el mismo lugar. CRÍTICO: NO referenciar variables de entorno multilínea como WRITING_STYLE o ADDITIONAL_RULES directamente en el script — Dagu las expande antes de que el shell se ejecute, lo que puede romper el análisis. Leerlas desde los archivos auxiliares escritos por setup vía cat en su lugar. Solo las variables de entorno simples (rutas, nombres de modelos, números) son seguras para usar directamente. Paso 4 — finalize: Construir un informe completo con: encabezado de metadatos (fecha, conteos de palabras, rigurosidad, conteos de problemas por ronda), luego una sección "Issues Found and Fixed" listando toda la retroalimentación por ronda, luego una sección "Final Text" con el texto reescrito. Limpiar todos los archivos auxiliares incluyendo los archivos de retroalimentación por ronda. Variables de entorno configurables (todas de nivel superior, fácilmente personalizables): - WRITING_STYLE: instrucciones de estilo de escritura objetivo multilínea (|) - CHECK_STRICTNESS: low/medium/high - CHECK_MODEL: modelo para revisión (más económico, ej. sonnet) - REWRITE_MODEL: modelo para reescritura (calidad, ej. opus) - ADDITIONAL_RULES: reglas adicionales más allá de la referencia de Wikipedia - WIKI_URL: URL raw de Wikipedia (intercambiable) - WIKI_EXCERPT_LINES: cuántas líneas del wiki alimentar a la IA Usar parámetros fuertemente tipados (name, type, description, default, minimum, maximum). Importante: revisar la referencia de pitfalls para soluciones conocidas. Seguir la referencia de coding agent para el comando no interactivo correcto y las flags de modelo.