Transforme qualquer comando CLI em um workflow confiável e repetível

Use a skill do Dagu para criar um workflow de preparação de standup diário. Consulte as referências de schema, agente de codificação e armadilhas para a sintaxe correta. Pergunte ao usuário: - Quantos dias atrás o relatório deve cobrir? (padrão: 1) - A que horas deve executar nos dias úteis? (padrão: 8:00 AM) - Qual CLI de agente de codificação IA está instalado? (verifique claude, codex, gemini, opencode, aider nessa ordem — use o primeiro encontrado, ou pergunte se nenhum for detectado) Pré-requisitos: gh CLI autenticado (gh auth login), pelo menos um CLI de agente de codificação IA instalado. O workflow deve: 1. Buscar a atividade do usuário no GitHub usando gh api graphql com --jq para formatação JSON no servidor (NÃO use jq CLI). Buscar commits por repositório (com mensagens via REST), PRs mesclados (com corpo), PRs abertos/rascunho atualizados no período (com commits recentes e timestamps, agrupados por repositório), e revisões. 2. Auto-descobrir todas as organizações a partir da atividade e agrupar tudo por organização. 3. Para cada organização com atividade, usar um sub-DAG inline (separador ---) para gerar um rascunho de standup falado usando o CLI do agente de IA do usuário. Use o modelo mais barato/rápido disponível para aquele agente, pois é uma tarefa simples de resumo de texto. Pule a chamada inteiramente para organizações sem atividade para evitar desperdício de tokens. 4. O comando do agente, modelo e prompt do rascunho devem ser definidos como variáveis de ambiente de nível superior (use YAML multiline | para o prompt) para que os usuários possam facilmente trocar agentes ou personalizar a saída sem editar a lógica das etapas. 5. Montar cada seção de organização como markdown: rascunho falado, PRs mesclados, PRs abertos agrupados por repositório com histórico de commits e timestamps, e revisões. 6. Combinar todas as seções de organizações em um único relatório salvo em DAG_DOCS_DIR. 7. Agendar nos dias úteis com catchup, padrões de retry e timeouts nas etapas do agente. Importante: revise a referência de armadilhas para soluções conhecidas. Siga a referência do agente de codificação para o comando não-interativo correto e flags de modelo para cada CLI de agente.

Use a skill do Dagu para criar um workflow gerador de notas de versão. Consulte as referências de schema, agente de codificação e armadilhas para a sintaxe correta. Pergunte ao usuário: - Qual repositório? (padrão: o repositório atual, detectado via gh repo view --json nameWithOwner) - Quais tags comparar? (padrão: tag mais recente vs tag anterior, auto-detectadas) Pré-requisitos: gh CLI autenticado (gh auth login), pelo menos um CLI de agente de codificação IA instalado. O workflow deve: 1. Resolver as duas tags git a comparar. Se não especificadas, auto-detectar as tags mais recente e anterior usando a API do GitHub. Saída como JSON para que as etapas subsequentes possam referenciar campos individuais via JSON path (ex: ${TAGS.to}). 2. Extrair todos os números de PR dos commits entre as duas tags usando a API de comparação do GitHub com --jq (NÃO use jq CLI). Saída com um número de PR por linha. 3. Para cada PR, buscar detalhes via gh api graphql: número, título, login do autor, resumo do corpo (primeiros ~300 caracteres), labels e closingIssuesReferences (número, título, login do autor). Construir um array JSON com os resultados. - CRÍTICO: Ao iterar sobre a saída de uma etapa anterior, NÃO use "for X in $VAR" — o Dagu captura saída multilinha em uma única variável string, então a divisão por palavras não funciona. Em vez disso, leia o arquivo stdout da etapa anterior linha por linha: `while IFS= read -r line; do ... done < "${prev_step.stdout}"`. Remova caracteres não numéricos de cada linha com `tr -dc '0-9'` antes de passar para a query GraphQL. - A string de query GraphQL do gh usa nomes de variáveis com prefixo $ ($owner, $name, $num). Estes são seguros em scripts do Dagu porque o Dagu só expande variáveis ${entre chaves} e padrões $nomedavariavel que correspondem a variáveis Dagu definidas — nomes $indefinidos são preservados como estão para o shell. No entanto, passe variáveis inteiras para -F sem aspas (ex: -F num=$NUM e não -F num="$NUM") para que o gh as envie como inteiros, não strings. 4. Use uma única etapa de agente de IA (auto-detectar qual CLI está disponível, usar o modelo mais barato) para categorizar cada PR e formatar as notas de versão finais. Forneça o JSON de detalhes dos PRs, o template do changelog e contexto (repositório, tags, data, dono do repositório para excluir dos contribuidores). 5. Salvar a saída em DAG_DOCS_DIR. 6. Usar defaults.retry_policy e timeout_sec: 300 na etapa do agente de IA. O template de formato do changelog DEVE ser definido como uma variável de ambiente de nível superior usando YAML multiline (|) para que os usuários possam personalizar a saída sem editar a lógica das etapas.

Use a skill do Dagu para criar um workflow de limpeza de escrita IA. Consulte as referências de schema, agente de codificação e armadilhas para a sintaxe correta. Pergunte ao usuário: - Deseja processar um arquivo ou colar texto inline? (suporte para ambos os parâmetros input_file e input_text) - Quantas rodadas de reescrita? (padrão: 2) - Nível de rigor? (low/medium/high, padrão: medium) Pré-requisitos: pelo menos um CLI de agente de codificação IA instalado (claude ou gemini). curl para buscar a referência da Wikipédia. O workflow tem 4 etapas: detect_agent, setup, review_loop, finalize. Etapa 1 — detect_agent: Exporte o caminho completo do binário (não apenas o nome), pois os scripts do Dagu podem não ter o PATH completo do usuário. Verifique locais comuns como ~/.local/bin/ como fallback. Adicione PATH: "${HOME}/.local/bin:${PATH}" ao env de nível superior. Etapa 2 — setup: - Busque a página mais recente da Wikipédia "Signs of AI Writing" (wikitext bruto) via curl. A URL deve ser uma variável de ambiente de nível superior para que os usuários possam trocá-la. - Prepare o texto de entrada. Para input_file, use cp. Para input_text, use `printenv input_text` para escrevê-lo com segurança em um arquivo — NÃO use ${input_text} diretamente em scripts porque o Dagu expande variáveis antes do shell executar. Veja a armadilha do printenv. - Escreva todas as variáveis de ambiente multilinha/controladas pelo usuário (WRITING_STYLE, ADDITIONAL_RULES, CHECK_STRICTNESS) em arquivos auxiliares com um prefixo comum em DAG_DOCS_DIR. Esses arquivos são lidos pela etapa de loop e limpos em finalize. Etapa 3 — review_loop: Uma única etapa de script com um loop for em bash (NÃO repeat_policy, NÃO um sub-DAG). O loop executa até max_rounds iterações: a. Construa um prompt com a referência wiki, estilo (do arquivo), rigor (do arquivo) e texto atual. Use um delimitador heredoc com aspas simples (<<'INSTR') para as instruções do sistema para que o shell não as expanda. b. Chame o agente de IA (CHECK_MODEL, ex: sonnet) para verificar o texto. Primeira linha da saída: contagem de problemas. Linhas restantes: feedback por problema com formato: ISSUE: "<citação>" | SIGN: <categoria> | FIX: <reescrita>. c. Salve o feedback em um arquivo por rodada (ex: ${P}_feedback_round${ROUND}.txt) para que finalize possa incluí-lo no relatório. d. Extraia a contagem. Se 0, interrompa imediatamente (reescrita não necessária). e. Chame o agente de IA (REWRITE_MODEL, ex: opus) para reescrever. Escreva a saída diretamente no arquivo de texto, sobrescrevendo no local. CRÍTICO: NÃO referencie variáveis de ambiente multilinha como WRITING_STYLE ou ADDITIONAL_RULES diretamente no script — o Dagu as expande antes do shell executar, o que pode quebrar o parsing. Leia-as dos arquivos auxiliares escritos pelo setup via cat. Apenas variáveis simples de ambiente (caminhos, nomes de modelos, números) são seguras para uso direto. Etapa 4 — finalize: Construa um relatório completo com: cabeçalho de metadados (data, contagens de palavras, rigor, contagens de problemas por rodada), depois uma seção "Problemas Encontrados e Corrigidos" listando todo o feedback por rodada, depois uma seção "Texto Final" com o texto reescrito. Limpe todos os arquivos auxiliares incluindo arquivos de feedback por rodada. Variáveis de ambiente configuráveis (todas de nível superior, facilmente personalizáveis): - WRITING_STYLE: instruções de estilo de escrita alvo multilinha (|) - CHECK_STRICTNESS: low/medium/high - CHECK_MODEL: modelo para verificação (mais barato, ex: sonnet) - REWRITE_MODEL: modelo para reescrita (qualidade, ex: opus) - ADDITIONAL_RULES: regras adicionais além da referência da Wikipédia - WIKI_URL: URL bruta da Wikipédia (substituível) - WIKI_EXCERPT_LINES: quantas linhas da wiki alimentar a IA Use parâmetros fortemente tipados (name, type, description, default, minimum, maximum). Importante: revise a referência de armadilhas para soluções conhecidas. Siga a referência do agente de codificação para o comando não-interativo correto e flags de modelo.