将任何 CLI 命令转化为可靠、可重复的工作流

使用 Dagu 技能创建一个每日站会准备工作流。请参考 schema、coding agent 和 pitfalls 参考文档以获取正确语法。 询问用户： - 报告应涵盖过去多少天？（默认：1） - 工作日几点运行？（默认：上午 8:00） - 安装了哪个 AI 编程代理 CLI？（按顺序检查 claude、codex、gemini、opencode、aider——使用第一个找到的，如果都没有则询问用户） 前置条件：gh CLI 已认证（gh auth login），至少安装了一个 AI 编程代理 CLI。 工作流应： 1. 使用 gh api graphql 配合 --jq 进行服务端 JSON 格式化来获取用户的 GitHub 活动（不要使用 jq CLI）。获取每个仓库的提交（通过 REST 获取提交消息）、已合并的 PR（含正文）、在时间段内更新的打开/草稿 PR（含最近提交和时间戳，按仓库分组）以及代码审查。 2. 从活动中自动发现所有组织，并按组织分组所有内容。 3. 对每个有活动的组织，使用内联子 DAG（--- 分隔符）通过用户的 AI 代理 CLI 生成口头站会草稿。使用该代理可用的最便宜/最快的模型，因为这是一个简单的文本摘要任务。对没有活动的组织完全跳过调用以避免浪费 token。 4. 代理命令、模型和草稿提示词都应定义为顶层 env 变量（提示词使用 YAML 多行 | 格式），以便用户可以轻松更换代理或自定义输出而无需编辑步骤逻辑。 5. 将每个组织部分组装为 markdown：口头草稿、已合并 PR、按仓库分组的打开 PR（含提交历史和时间戳）以及代码审查。 6. 将所有组织部分合并为一份报告保存到 DAG_DOCS_DIR。 7. 在工作日安排运行，启用 catchup、retry 默认值和代理步骤超时。 重要：请查看 pitfalls 参考文档了解已知的解决方法。请遵循 coding agent 参考文档了解每个代理 CLI 的正确非交互命令和模型参数。

使用 Dagu 技能创建一个发布说明生成器工作流。请参考 schema、coding agent 和 pitfalls 参考文档以获取正确语法。 询问用户： - 哪个仓库？（默认：当前仓库，通过 gh repo view --json nameWithOwner 检测） - 比较哪些标签？（默认：最新标签与上一个标签，自动检测） 前置条件：gh CLI 已认证（gh auth login），至少安装了一个 AI 编程代理 CLI。 工作流应： 1. 解析要比较的两个 git 标签。如果未指定，使用 GitHub API 自动检测最新和上一个标签。以 JSON 格式输出，以便下游步骤可以通过 JSON 路径引用各个字段（例如 ${TAGS.to}）。 2. 使用 GitHub compare API 配合 --jq（不要使用 jq CLI）从两个标签之间的提交中提取所有 PR 编号。每行输出一个 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}"`。在传递给 GraphQL 查询之前，使用 `tr -dc '0-9'` 去除每行中的非数字字符。 - gh GraphQL 查询字符串使用 $ 前缀的变量名（$owner、$name、$num）。这些在 Dagu 脚本中是安全的，因为 Dagu 只展开 ${带花括号} 的变量和匹配已定义 Dagu 变量的裸 $varname 模式——未定义的裸 $name 会原样保留给 shell。但是，将整数变量传递给 -F 时不要加引号（例如 -F num=$NUM 而不是 -F num="$NUM"），以便 gh 将它们作为整数而非字符串发送。 4. 使用单个 AI 代理步骤（自动检测可用的 CLI，使用最便宜的模型）来分类每个 PR 并格式化最终的发布说明。将 PR 详情 JSON、changelog 模板和上下文（仓库、标签、日期、要从贡献者中排除的仓库所有者）提供给它。 5. 将输出保存到 DAG_DOCS_DIR。 6. 在 AI 代理步骤上使用 defaults.retry_policy 和 timeout_sec: 300。 changelog 格式模板必须定义为顶层 env 变量，使用 YAML 多行（|）格式，以便用户可以自定义输出而无需编辑步骤逻辑。

使用 Dagu 技能创建一个 AI 写作清理工作流。请参考 schema、coding agent 和 pitfalls 参考文档以获取正确语法。 询问用户： - 要处理文件还是直接粘贴文本？（支持 input_file 和 input_text 参数） - 重写多少轮？（默认：2） - 严格程度？（low/medium/high，默认：medium） 前置条件：至少安装了一个 AI 编程代理 CLI（claude 或 gemini）。用于获取维基百科参考的 curl。 工作流有 4 个步骤：detect_agent、setup、review_loop、finalize。 步骤 1 — detect_agent： 输出完整的二进制路径（不仅仅是名称），因为 Dagu 脚本可能没有用户的完整 PATH。检查 ~/.local/bin/ 等常见位置作为后备。在顶层 env 中添加 PATH: "${HOME}/.local/bin:${PATH}"。 步骤 2 — setup： - 通过 curl 获取最新的维基百科「AI 写作特征」页面（原始 wikitext）。URL 应为顶层 env 变量，以便用户可以替换。 - 准备输入文本。对于 input_file，使用 cp。对于 input_text，使用 `printenv input_text` 安全地将其写入文件——不要在脚本中直接使用 ${input_text}，因为 Dagu 在 shell 运行之前就展开变量。请参阅 printenv 的坑。 - 将所有多行/用户控制的 env 变量（WRITING_STYLE、ADDITIONAL_RULES、CHECK_STRICTNESS）写入 DAG_DOCS_DIR 中具有公共前缀的辅助文件。这些文件由循环步骤读取，并在 finalize 中清理。 步骤 3 — review_loop： 一个包含 bash for 循环的单脚本步骤（不是 repeat_policy，不是子 DAG）。循环最多运行 max_rounds 次迭代： a. 使用 wiki 参考、风格（从文件读取）、严格程度（从文件读取）和当前文本构建提示词。对系统指令使用单引号 heredoc 分隔符（<<'INSTR'），这样 shell 不会展开它们。 b. 调用 AI 代理（CHECK_MODEL，例如 sonnet）检查文本。输出第一行：问题数量。其余行：每个问题的反馈，格式为：ISSUE: "<引用>" | SIGN: <类别> | FIX: <重写>。 c. 将反馈保存到每轮文件（例如 ${P}_feedback_round${ROUND}.txt），以便 finalize 可以将其包含在报告中。 d. 提取数量。如果为 0，立即中断（无需重写）。 e. 调用 AI 代理（REWRITE_MODEL，例如 opus）进行重写。将输出直接写入文本文件，原地覆盖。 关键：不要在脚本中直接引用多行 env 变量如 WRITING_STYLE 或 ADDITIONAL_RULES——Dagu 在 shell 运行之前就展开它们，这会破坏解析。请通过 cat 从 setup 写入的辅助文件中读取它们。只有简单的 env 变量（路径、模型名称、数字）可以安全直接使用。 步骤 4 — finalize： 构建完整报告，包含：元数据头（日期、字数统计、严格程度、每轮问题数量），然后是「发现并修复的问题」部分列出所有每轮反馈，然后是「最终文本」部分包含重写后的文本。清理所有辅助文件，包括每轮反馈文件。 Env 变量配置项（全部顶层，易于自定义）： - WRITING_STYLE：多行（|）目标写作风格指令 - CHECK_STRICTNESS：low/medium/high - CHECK_MODEL：用于检查的模型（较便宜，例如 sonnet） - REWRITE_MODEL：用于重写的模型（高质量，例如 opus） - ADDITIONAL_RULES：维基百科参考之外的额外规则 - WIKI_URL：维基百科原始 URL（可替换） - WIKI_EXCERPT_LINES：提供给 AI 的 wiki 行数 使用强类型参数（name、type、description、default、minimum、maximum）。 重要：请查看 pitfalls 参考文档了解已知的解决方法。请遵循 coding agent 参考文档了解正确的非交互命令和模型参数。