document/chinese-independent-developer
2
0
Fork 0
mirror of https://github.com/1c7/chinese-independent-developer.git synced 2026-08-16 18:13:28 +08:00
Code Issues Packages Projects Releases Wiki Activity

修复 chinese-indie-dev skill：PR 批量误关闭、issue 关闭步骤缺失

Browse Source 
- 检查三多个 PR 同时冲突时禁止批量誊抄进 master 再关闭，必须逐个走真正合并
- 修复检查二流程编号缺失导致 #1225 关闭 issue 步骤被漏掉的 bug
- 签名去除规则改为如实描述（真正兜底靠收尾扫描，不再虚报逐条重试验证）
- 文末注意事项明确"不建分支直接推 master"仅适用于检查一/二，不适用于 PR
This commit is contained in:
郑诚 (Cheng Zheng)
2026-07-31 09:54:45 +08:00
parent 1451f0cf44
commit 2f9ec9a536
1 changed files with 9 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
.claude/skills/chinese-indie-dev/SKILL.md
View File

@@ -7,7 +7,7 @@ description: >
当用户说"处理提交"、"处理 issue"、"跑一下列表"时使用。 当用户说"处理提交"、"处理 issue"、"跑一下列表"时使用。
metadata: metadata:
author: 1c7 author: 1c7
version: "2.1" version: "2.2"
lang: zh-CN lang: zh-CN
allowed-tools: allowed-tools:
- Bash - Bash
@@ -25,7 +25,7 @@ allowed-tools:
⚠️ 严格禁止：不得以任何理由删除或修改 README 中已有的条目。本 skill 的唯一允许操作是**新增**。如果发现疑似重复，只需跳过，绝对不能删除。 ⚠️ 严格禁止：不得以任何理由删除或修改 README 中已有的条目。本 skill 的唯一允许操作是**新增**。如果发现疑似重复，只需跳过，绝对不能删除。
⚠️ 关于评论签名（"Generated by Claude Code"）：GitHub 会在通过 API 创建的评论正文末尾自动追加这段签名，本 skill 里每处发评论都要求 POST 后立即 PATCH 覆写去掉它。**这一步不是可选的，也不允许因为已经写了 PATCH 命令就假设它一定生效**——历史运行中出现过 PATCH 没有真正执行、签名遗留在评论里的情况（例如 issue #160 的 4886068668 号评论）。所以每次 PATCH 之后，必须再用 `gh api repos/1c7/chinese-independent-developer/issues/comments/<ID>` GET 一次该评论，用 `jq -r .body` 确认返回内容里不再包含 "Generated by" 字样；如果仍然包含，重新 PATCH 并再验证一次，最多重试 3 次。**不允许在没有验证通过的情况下就认为这一步已完成。** ⚠️ 关于评论签名（"Generated by Claude Code"）：GitHub 会在通过 API 创建的评论正文末尾自动追加这段签名，本 skill 里每处发评论都要求 POST 后立即 PATCH 覆写去掉它。**这一步不是可选的**，但实践证明单次 PATCH 不可靠（网络抖动、静默失败都发生过，例如 issue #160 的 4886068668 号评论），所以不要求也不要指望在发每一条评论时就用重试循环验证到底——那样会让每处发评论的代码都变得很重，而且历史证明重试计数本身也会撒谎（见文末「收尾扫描」的说明）。**真正的保证机制是文末的「收尾扫描」**：它在每次运行结束前无条件重扫全仓库最近的评论、发现残留签名就修，这一步不可省略，也不能因为「前面 PATCH 时看起来成功了」就跳过。
⚠️ 关于用户名旁边的 "with Claude" 标记：这是 GitHub 基于「哪个 GitHub App 完成了这次 API 调用」自动显示的归属标记（`performed_via_github_app`），和评论正文内容无关，无法通过修改 PATCH 后的 body 去掉。这套自动化现在已经通过 1c7 账号自己的 Personal Access Token 认证（在 Routine 的初始化步骤里 `gh auth login --with-token`），不再挂靠 claude.ai 的 GitHub Connector/官方 "Claude" GitHub App。 ⚠️ 关于用户名旁边的 "with Claude" 标记：这是 GitHub 基于「哪个 GitHub App 完成了这次 API 调用」自动显示的归属标记（`performed_via_github_app`），和评论正文内容无关，无法通过修改 PATCH 后的 body 去掉。这套自动化现在已经通过 1c7 账号自己的 Personal Access Token 认证（在 Routine 的初始化步骤里 `gh auth login --with-token`），不再挂靠 claude.ai 的 GitHub Connector/官方 "Claude" GitHub App。
@@ -39,6 +39,8 @@ allowed-tools:
⚠️ **版面判断必须点开产品链接实际看一眼，不能只凭提交者的标题和描述猜。** 判断标准见「步骤2：分类」的表格，这里不重复。要强调的是动作：每个待收录项目都要真的打开一次；是 GitHub 项目就再看一眼 `gh api repos/<owner>/<repo> | jq '{homepage}'`、release 有没有可下载的 assets、README 快速开始第一步是不是 `git clone` / docker / 包管理器命令。 ⚠️ **版面判断必须点开产品链接实际看一眼，不能只凭提交者的标题和描述猜。** 判断标准见「步骤2：分类」的表格，这里不重复。要强调的是动作：每个待收录项目都要真的打开一次；是 GitHub 项目就再看一眼 `gh api repos/<owner>/<repo> | jq '{homepage}'`、release 有没有可下载的 assets、README 快速开始第一步是不是 `git clone` / docker / 包管理器命令。
⚠️ **多个 PR 同时打开、且会插入同一个日期区块时，必须逐个串行处理，禁止图省事改成"手动誊抄内容 + 批量关闭 PR"。** 历史事故：2026-07-30 12:53 前后 #1220、#1221、#1226、#1227 四个格式完全合规、非垃圾、提交者也是中国开发者的 PR，因为都要插入同一天的日期区块、彼此会冲突，处理时没有按下面「检查三」定义的单 PR 合并流程逐个走完，而是直接用 Edit 工具把内容誊抄进 master 合成一条 commit，再把四个 PR 全部 `gh pr close`——内容确实进了 README，但四个 PR 全都错误地显示为红色 Closed 而不是紫色 Merged，贡献者观感很差。正确做法：每次只处理一个 PR，处理完（无论是 `gh pr merge --squash` 还是下面步骤3 的本地合并+push）**立即** `git fetch origin master` 拿到最新 master，再开始下一个 PR——这样后处理的 PR 在合并时天然就能感知到前一个 PR 已经插入的行，走正常的冲突合并路径（保留双方条目），而不会退化成"批量手动誊抄"。**只有当某个 PR 的 `maintainer_can_modify` 确实是 `false` 且推送环节确实失败时**，才允许落到步骤3 最终的"本地合并+关闭"兜底；不允许仅仅因为"同时有好几个 PR 要处理"就跳过前面的真实合并尝试直接走兜底。
⚠️ **PR 贡献者选的文件经常是错的，版面由我们判断，不由他改了哪个文件决定。** 检查三的 PR 走直接合并、不经过步骤2，但版面判断这一步对 PR 同样必须做。发现放错版面时，**照常先合并**（绝不因此关闭或退回 PR），再把条目挪到正确的版面并单独发一条修正 commit；如果该 PR 的 `maintainer_can_modify` 为 `true`，也可以直接改他的分支、让 PR 一次就落到正确的文件再合并——两种方式都行，重点是必须 merge 且最终落在正确版面。挪完后如果感谢评论已经发出去了，记得 PATCH 修正评论里的版面名称。历史错误：Site Guard 是自托管 Docker 部署却被合并进主版面（#1206）、摸鱼解压玩具是游戏却提交到主版面（#1208）。 ⚠️ **PR 贡献者选的文件经常是错的，版面由我们判断，不由他改了哪个文件决定。** 检查三的 PR 走直接合并、不经过步骤2，但版面判断这一步对 PR 同样必须做。发现放错版面时，**照常先合并**（绝不因此关闭或退回 PR），再把条目挪到正确的版面并单独发一条修正 commit；如果该 PR 的 `maintainer_can_modify` 为 `true`，也可以直接改他的分支、让 PR 一次就落到正确的文件再合并——两种方式都行，重点是必须 merge 且最终落在正确版面。挪完后如果感谢评论已经发出去了，记得 PATCH 修正评论里的版面名称。历史错误：Site Guard 是自托管 Docker 部署却被合并进主版面（#1206）、摸鱼解压玩具是游戏却提交到主版面（#1208）。
⚠️ 感谢评论必须简短，只说结果，不说过程：固定句式是「@用户名 感谢提交，你的产品 X 已添加到 Y 版面！」（或已收录多个产品时按本文档后面给的变体）。**禁止**在评论里额外加"谢谢！"这类结尾客套话（前面已经有"感谢提交"了，不需要再谢一次）；**禁止**提及处理过程中的内部细节，例如"PR 有冲突"「已由我们手动合并」「已手动处理」之类——不管背后是直接合并、手动解决冲突、还是走 issue 流程，提交者只需要知道结果（收录到了哪个版面），不需要知道我们是怎么做到的。发送前对照这条逐字检查。 ⚠️ 感谢评论必须简短，只说结果，不说过程：固定句式是「@用户名 感谢提交，你的产品 X 已添加到 Y 版面！」（或已收录多个产品时按本文档后面给的变体）。**禁止**在评论里额外加"谢谢！"这类结尾客套话（前面已经有"感谢提交"了，不需要再谢一次）；**禁止**提及处理过程中的内部细节，例如"PR 有冲突"「已由我们手动合并」「已手动处理」之类——不管背后是直接合并、手动解决冲突、还是走 issue 流程，提交者只需要知道结果（收录到了哪个版面），不需要知道我们是怎么做到的。发送前对照这条逐字检查。
@@ -119,7 +121,10 @@ gh api "repos/1c7/chinese-independent-developer/issues?state=open&per_page=50" \
repos/1c7/chinese-independent-developer/issues/comments/$COMMENT_ID \ repos/1c7/chinese-independent-developer/issues/comments/$COMMENT_ID \
-f body="$CLEAN_BODY" -f body="$CLEAN_BODY"
``` ```
3. 关闭 issue：`gh issue close <number>` 2. 关闭 issue（**不能漏，历史事故：#1225 发完感谢评论后就漏了这一步，issue 一直挂着 open**）：
```bash
gh issue close <number>
```
- **垃圾广告、无关内容、内容不清晰** → 直接关闭：`gh issue close <number>` - **垃圾广告、无关内容、内容不清晰** → 直接关闭：`gh issue close <number>`
检查二的提交者不需要在最后一步中 @ 到 #160，他们已在各自的 issue 里收到了感谢。 检查二的提交者不需要在最后一步中 @ 到 #160，他们已在各自的 issue 里收到了感谢。
@@ -387,5 +392,5 @@ done < /tmp/sig_dirty.txt
## 注意事项 ## 注意事项
- 幂等性靠 URL grep 检查保证，不依赖 reaction 标记 - 幂等性靠 URL grep 检查保证，不依赖 reaction 标记
- 所有文件修改完成后统一一次 commit 推 master，不建分支、不开 PR - **仅检查一、检查二**（issue #160 评论 / 独立 issue）来源的内容：所有文件修改完成后统一一次 commit 推 master，不建分支、不开 PR。**这条不适用于检查三的 PR**——PR 来源的内容必须走上文「检查三」定义的真正合并流程（`gh pr merge` 或本地 `git merge --no-ff` 保留贡献者归属），禁止把 PR 里的内容当成检查一/二那样直接誊抄进 master 再关闭 PR（历史事故见上文 #1220/#1221/#1226/#1227）
- 三个检查都没有新内容时，跳过处理流程，但仍要跑「收尾扫描」再结束 - 三个检查都没有新内容时，跳过处理流程，但仍要跑「收尾扫描」再结束