routine-devlisted

跑一遍**issue 的自动开发**：扫 open issue → 两条通道分诊 → 合批 → 逐条开发 → 每批一个 PR。 ## 为什么存在 本仓积压着大量**需求已经写清楚、不需要讨论方案**的 issue —— 沉淀一条实战教训成 `playbooks/*.md` 一节、加个小 skill、补条 template、修个边界清晰的 bug。这类活人来做是纯执行，正是该交给定时 agent 的。形态上**对标 `/quick` 而非 `/start`** —— 没有人在环时跑三件套只会产出无人读的 `PLAN.md`。 **两条通道，授权强度不同**（这是本 skill 的核心结构）： | 通道 | 谁决定纳入 | 能改什么 | | --- | --- | --- | | **自动通道** | 模型分诊（保守判） | 只有文档落点 | | **标记通道** | **owner 打 `auto:take` label** | 放开到 `skills/`（除自己）/ `templates/` / `scripts/` / `hooks/` | **为什么要有第二条通道**：自动分诊判错的代价不对称，所以它必须保守，于是一大批「其实完全够格」的 issue 被漏收。难度与风险自动区分不了，就让人来标——**`auto:take` 的语义是「owner 已过目此条，背书其正文可被无人值守执行」**。它替换掉了原先由「落点只限文档」承担的安全职责，故放宽落点的同时，标记自身的授权校验必须扎实（见 Step 1.0）。 **人机回路靠 PR，不靠 IM**：routine 出 PR → 手机收到推送 → 人在手机上 review 并决定合不合。云端**没有编程可读的回路**（定时任务的运行输出取不回来），所以 **PR 就是本 routine 唯一的汇报出口** —— 这是设计约束，不是可选项。 | 形态 | 怎么触发 | 用途 | | --- | --- | --- | | **云端（主）** | claude.ai Routines 每周一 / 三 / 五定时（注册方式见末节） | 日常自动开发 | | 本机（辅） | 直接 `/routine-dev`（建议先 `--dry-run`） | 验证分诊 / 合批质量、补跑 | ## args 三者正交、可组合： - **`--dry-run`**：只跑到 Step 2 为止，把「分诊结果 + 合批方案」打给人看，**不改任何文件、不开分支、不提 PR**。 - **`--only #N[,#M...]`**：只处理指定 issue（仍走完整分诊，不合格照样排除）。 - **`--max-prs=<n>`**：覆盖单次运行的 PR 数上限（默认 5）。 ## Step 0 · 环境判定与前置闸 **先判定跑在哪一端**，两端能用的工具完全不同： ```bash command -v gh >/dev/null 2>&1 && echo local || echo cloud ``` | 能力 | 本机（有 `gh`） | 云端（无 `gh`） | | --- | --- | --- | | 读 / 写 issue、列 / 开 PR | `python3 $HOME/.claude/scripts/platform_issue.py`、`gh pr list` / `gh pr create` | **内置 GitHub MCP 工具** | | git push | 常规 `