Превратите любую CLI-команду в надёжный, воспроизводимый рабочий процесс

Используйте навык Dagu для создания рабочего процесса подготовки к ежедневному стендапу. Обратитесь к справочникам по схеме, coding agent и известным подводным камням для правильного синтаксиса. Спросите у пользователя: - За сколько дней назад формировать отчёт? (по умолчанию: 1) - В какое время запускать в будние дни? (по умолчанию: 8:00) - Какой AI coding agent CLI установлен? (проверить наличие claude, codex, gemini, opencode, aider в этом порядке — использовать первый найденный или спросить, если ни один не обнаружен) Предварительные требования: авторизованный gh CLI (gh auth login), как минимум один установленный AI coding agent CLI. Рабочий процесс должен: 1. Получить активность пользователя на GitHub с помощью gh api graphql с --jq для серверного форматирования JSON (НЕ используйте jq CLI). Получить коммиты по репозиториям (с сообщениями через REST), объединённые PR (с телом), открытые/черновые PR, обновлённые за период (с недавними коммитами и временными метками, сгруппированные по репозиторию), и ревью. 2. Автоматически обнаружить все организации из активности и сгруппировать всё по организациям. 3. Для каждой организации с активностью использовать встроенный sub-DAG (разделитель ---) для генерации черновика устного стендапа с помощью AI agent CLI пользователя. Использовать самую дешёвую/быструю доступную модель для этого агента, так как это простая задача суммаризации текста. Полностью пропускать вызов для организаций без активности, чтобы не тратить токены. 4. Команда агента, модель и промпт черновика должны быть определены как переменные окружения верхнего уровня (использовать YAML multiline | для промпта), чтобы пользователи могли легко менять агентов или настраивать вывод без редактирования логики шагов. 5. Собрать каждую секцию организации в markdown: черновик устного выступления, объединённые PR, открытые PR, сгруппированные по репозиторию с историей коммитов и временными метками, и ревью. 6. Объединить все секции организаций в единый отчёт, сохранённый в DAG_DOCS_DIR. 7. Запланировать на будние дни с catchup, значениями retry по умолчанию и таймаутами на шагах агента. Важно: просмотрите справочник по подводным камням для известных обходных решений. Следуйте справочнику по coding agent для правильных неинтерактивных команд и флагов моделей для каждого agent CLI.

Используйте навык Dagu для создания рабочего процесса генерации релиз-нотов. Обратитесь к справочникам по схеме, coding agent и известным подводным камням для правильного синтаксиса. Спросите у пользователя: - Какой репозиторий? (по умолчанию: текущий репозиторий, определяется через gh repo view --json nameWithOwner) - Какие теги сравнивать? (по умолчанию: последний тег с предыдущим, определяются автоматически) Предварительные требования: авторизованный gh CLI (gh auth login), как минимум один установленный AI coding agent CLI. Рабочий процесс должен: 1. Определить два git-тега для сравнения. Если не указаны, автоматически определить последний и предыдущий теги через GitHub API. Вывести их в формате JSON, чтобы последующие шаги могли ссылаться на отдельные поля через JSON path (например, ${TAGS.to}). 2. Извлечь все номера PR из коммитов между двумя тегами с помощью GitHub compare API с --jq (НЕ используйте jq CLI). Выводить по одному номеру PR на строку. 3. Для каждого PR получить детали через gh api graphql: номер, заголовок, логин автора, краткое описание тела (первые ~300 символов), метки и closingIssuesReferences (номер, заголовок, логин автора). Собрать JSON-массив из результатов. - КРИТИЧНО: При итерации по выводу предыдущего шага НЕ используйте "for X in $VAR" — Dagu захватывает многострочный вывод в одну строковую переменную, поэтому разделение по словам не работает. Вместо этого читайте файл stdout предыдущего шага построчно: `while IFS= read -r line; do ... done < "${prev_step.stdout}"`. Удаляйте нечисловые символы из каждой строки с помощью `tr -dc '0-9'` перед передачей в GraphQL-запрос. - Строка запроса gh GraphQL использует переменные с префиксом $ ($owner, $name, $num). Это безопасно в скриптах Dagu, потому что Dagu раскрывает только ${переменные_в_фигурных_скобках} и шаблоны $имя_переменной, совпадающие с определёнными переменными Dagu — неопределённые $имена сохраняются как есть для оболочки. Однако передавайте целочисленные переменные в -F без кавычек (например, -F num=$NUM, а не -F num="$NUM"), чтобы gh отправлял их как целые числа, а не строки. 4. Использовать один шаг AI-агента (автоопределение доступного CLI, использовать самую дешёвую модель) для категоризации каждого PR и форматирования итоговых релиз-нотов. Передать ему JSON с деталями PR, шаблон changelog и контекст (репозиторий, теги, дата, владелец репозитория для исключения из списка контрибьюторов). 5. Сохранить результат в DAG_DOCS_DIR. 6. Использовать defaults.retry_policy и timeout_sec: 300 на шаге AI-агента. Шаблон формата changelog ДОЛЖЕН быть определён как переменная окружения верхнего уровня с использованием YAML multiline (|), чтобы пользователи могли настраивать вывод без редактирования логики шагов.

Используйте навык Dagu для создания рабочего процесса очистки AI-текста. Обратитесь к справочникам по схеме, coding agent и известным подводным камням для правильного синтаксиса. Спросите у пользователя: - Обработать файл или вставить текст напрямую? (поддержка обоих параметров: input_file и input_text) - Сколько раундов переписывания? (по умолчанию: 2) - Уровень строгости? (low/medium/high, по умолчанию: medium) Предварительные требования: как минимум один установленный AI coding agent CLI (claude или gemini). curl для загрузки справочника из Википедии. Рабочий процесс состоит из 4 шагов: detect_agent, setup, review_loop, finalize. Шаг 1 — detect_agent: Вывести полный путь к бинарному файлу (а не только имя), так как скрипты Dagu могут не иметь полного PATH пользователя. Проверить стандартные расположения, такие как ~/.local/bin/, как запасной вариант. Добавить PATH: "${HOME}/.local/bin:${PATH}" в переменные окружения верхнего уровня. Шаг 2 — setup: - Загрузить последнюю страницу Википедии «Signs of AI Writing» (сырой викитекст) через curl. URL должен быть переменной окружения верхнего уровня, чтобы пользователи могли его заменить. - Подготовить входной текст. Для input_file — cp. Для input_text — использовать `printenv input_text` для безопасной записи в файл. НЕ используйте ${input_text} напрямую в скриптах, потому что Dagu раскрывает переменные до запуска оболочки. См. описание подводного камня с printenv. - Записать все многострочные/пользовательские переменные окружения (WRITING_STYLE, ADDITIONAL_RULES, CHECK_STRICTNESS) во вспомогательные файлы с общим префиксом в DAG_DOCS_DIR. Эти файлы читаются шагом цикла и очищаются в finalize. Шаг 3 — review_loop: Один шаг-скрипт с bash-циклом for (НЕ repeat_policy, НЕ sub-DAG). Цикл выполняется до max_rounds итераций: a. Построить промпт со справочником из вики, стилем (из файла), строгостью (из файла) и текущим текстом. Использовать heredoc-разделитель в одинарных кавычках (<<'INSTR') для системных инструкций, чтобы оболочка не раскрывала их. b. Вызвать AI-агента (CHECK_MODEL, например sonnet) для проверки текста. Первая строка вывода: количество проблем. Остальные строки: обратная связь по каждой проблеме в формате: ISSUE: "<цитата>" | SIGN: <категория> | FIX: <исправление>. c. Сохранить обратную связь в файл для каждого раунда (например, ${P}_feedback_round${ROUND}.txt), чтобы finalize мог включить её в отчёт. d. Извлечь количество. Если 0, немедленно прервать цикл (переписывание не требуется). e. Вызвать AI-агента (REWRITE_MODEL, например opus) для переписывания. Записать вывод напрямую в текстовый файл, перезаписывая на месте. КРИТИЧНО: НЕ ссылайтесь на многострочные переменные окружения, такие как WRITING_STYLE или ADDITIONAL_RULES, напрямую в скрипте — Dagu раскрывает их до запуска оболочки, что может нарушить парсинг. Читайте их из вспомогательных файлов, записанных в setup, через cat. Только простые переменные окружения (пути, имена моделей, числа) безопасны для прямого использования. Шаг 4 — finalize: Собрать полный отчёт с: заголовком метаданных (дата, количество слов, строгость, количество проблем по раундам), затем раздел «Найденные и исправленные проблемы» со списком обратной связи по всем раундам, затем раздел «Итоговый текст» с переписанным текстом. Очистить все вспомогательные файлы, включая файлы обратной связи по раундам. Настраиваемые переменные окружения (все верхнего уровня, легко настраиваются): - WRITING_STYLE: многострочный (|) — инструкции по целевому стилю письма - CHECK_STRICTNESS: low/medium/high - CHECK_MODEL: модель для проверки (дешевле, например sonnet) - REWRITE_MODEL: модель для переписывания (качественнее, например opus) - ADDITIONAL_RULES: дополнительные правила помимо справочника Википедии - WIKI_URL: URL сырого текста Википедии (заменяемый) - WIKI_EXCERPT_LINES: сколько строк вики передавать AI Используйте строго типизированные параметры (name, type, description, default, minimum, maximum). Важно: просмотрите справочник по подводным камням для известных обходных решений. Следуйте справочнику по coding agent для правильных неинтерактивных команд и флагов моделей.