routine-docslisted

跑一遍**文档类 issue 的自动开发**：扫 open issue → 分诊出纯文档类 → 合批 → 逐条开发 → 每批一个 PR。 ## 为什么存在 本仓积压着大量「把某条实战教训沉淀成 `playbooks/*.md` 一节」这类 issue：**需求已经写清楚了、改动只落在文档、不需要讨论方案**。这类活人来做是纯执行，正是该交给定时 agent 的。形态上**对标 `/quick` 而非 `/start`** —— 没有人在环时跑三件套只会产出无人读的 `PLAN.md`。 **人机回路靠 PR，不靠 IM**：routine 出 PR → 手机收到推送 → 人在手机上 review 并决定合不合。云端**没有编程可读的回路**（定时任务的运行输出取不回来），所以 **PR 就是本 routine 唯一的汇报出口** —— 这是设计约束，不是可选项。 | 形态 | 怎么触发 | 用途 | | --- | --- | --- | | **云端（主）** | claude.ai Routines 每周一 / 三 / 五定时（注册方式见末节） | 日常自动开发 | | 本机（辅） | 直接 `/routine-docs`（建议先 `--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 | 常规 `git push` | 常规 `git push`（凭证在本地代理里，`https://github.com/` 被透明改写） | **云端不要试 `gh`、也不要直连 `api.github.com`**：前者根本没装，后者被应用层 403 拒绝 —— `scripts/platform_issue.py` 正因为包的是 `gh` / `glab`，在云端整个不可用。**MCP 工具的确切名称以当次会话可见的工具列表为准，不要凭记忆硬猜**（同一条纪律对**字段值**也适用，见 Step 0.5）。 **前置闸**（任一不满足 → 打印原因并**中止整次运行**，不要将就着跑）： 1. 当前目录是本仓（`git remote get-url origin` 指向 `claude-code-global`）； 2. 工作树干净（`git status --porcelain` 为空）； 3. 已在默认分支且与远端同步（`git