适配 Codex 项目收录 skill

.claude/skills/chinese-indie-dev/SKILL.md

@@ -4,16 +4,7 @@ description: >
   处理 1c7/chinese-independent-developer 仓库的项目提交。
   检查 issue #160 新评论、新开的 Issue、新开的 PR，
   将有效项目添加到对应 README，关闭垃圾内容。
-  当用户说"处理提交"、"处理 issue"、"跑一下列表"时使用。
-metadata:
-  author: 1c7
-  version: "2.3"
-  lang: zh-CN
-allowed-tools:
-  - Bash
-  - Read
-  - Edit
-  - Write
+  当用户要求“收录项目”“处理提交”“处理 issue”“跑一下列表”或运行中国独立开发者列表维护流程时使用。
 ---
 
 # 中国独立开发者列表：处理项目提交
@@ -25,11 +16,11 @@ allowed-tools:
 
 ⚠️ 严格禁止：不得以任何理由删除或修改 README 中已有的条目。本 skill 的唯一允许操作是**新增**。如果发现疑似重复，只需跳过，绝对不能删除。
 
-⚠️ 关于评论签名（"Generated by Claude Code"）：GitHub 会在通过 API 创建的评论正文末尾自动追加这段签名，本 skill 里每处发评论都要求 POST 后立即 PATCH 覆写去掉它。**这一步不是可选的**，但实践证明单次 PATCH 不可靠（网络抖动、静默失败都发生过，例如 issue #160 的 4886068668 号评论），所以不要求也不要指望在发每一条评论时就用重试循环验证到底——那样会让每处发评论的代码都变得很重，而且历史证明重试计数本身也会撒谎（见文末「收尾扫描」的说明）。**真正的保证机制是文末的「收尾扫描」**：它在每次运行结束前无条件重扫全仓库最近的评论、发现残留签名就修，这一步不可省略，也不能因为「前面 PATCH 时看起来成功了」就跳过。
+⚠️ 关于历史评论签名（"Generated by Claude Code"）：当前 Codex 通过 `gh` 和维护者 PAT 操作，不会主动添加这段签名；但历史自动化可能留下残余。本 skill 里每处发评论仍要求 POST 后立即 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。
+⚠️ 关于用户名旁边的 GitHub App 归属标记：这是 GitHub 根据执行 API 调用的 App 自动显示的 `performed_via_github_app`，无法通过 PATCH 正文去掉。运行前确认 `gh auth status` 使用 1c7 账号自己的 Personal Access Token。
 
-⚠️ 严格禁止：本 skill 涉及的所有 GitHub 操作（发评论、开关 issue、合并/关闭 PR、改 reaction 等）**只能通过 Bash 里的 `gh` / `git` 命令行执行**，绝对不能使用任何 GitHub 连接器（Connector）或平台自带的原生 GitHub 工具（例如各种 `add_issue_comment`、`merge_pull_request`、`create_pull_request` 之类的内置工具）去完成，哪怕当前环境里这些工具可用。原因：这些内置工具走的是 claude.ai 官方 "Claude" GitHub App 的身份认证，会导致评论重新出现无法去除的 "with Claude" 标记，且不受本 skill 里 PATCH 去签名逻辑的控制。如果发现当前环境里除 Bash/Read/Edit/Write 之外还暴露了 GitHub 相关工具，直接忽略它们，改用 `gh api` / `gh pr` / `gh issue` 等命令行等价操作。
+⚠️ 严格禁止：本 skill 涉及的所有 GitHub 操作（发评论、开关 issue、合并/关闭 PR、改 reaction 等）**只能通过 shell 中的 `gh` / `git` 命令行执行**，绝对不能使用 GitHub Connector 或平台原生 GitHub 工具。这样才能确保操作使用维护者 PAT 身份。文件读取与修改使用 Codex 提供的本地文件工具。
 
 ⚠️ 本仓库**只收录中国独立开发者**的项目（仓库标题即「中国独立开发者项目列表」）。检查一、二、三的每一位提交者，在进入「通用处理流程」或合并 PR 之前，都必须先按下方「身份判断」章节确认是中国人，确认是老外的一律礼貌拒绝、不收录，绝不能因为产品本身质量好、URL 有效就直接收录。
 
@@ -39,7 +30,7 @@ allowed-tools:
 
 ⚠️ **版面判断必须点开产品链接实际看一眼，不能只凭提交者的标题和描述猜。** 判断标准见「步骤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"。** 历史事故：2026-07-30 12:53 前后 #1220、#1221、#1226、#1227 四个格式完全合规、非垃圾、提交者也是中国开发者的 PR，因为都要插入同一天的日期区块、彼此会冲突，处理时没有按下面「检查三」定义的单 PR 合并流程逐个走完，而是直接用本地编辑工具把内容誊抄进 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）。
 
@@ -153,7 +144,7 @@ gh api "repos/1c7/chinese-independent-developer/pulls?state=open&per_page=50" \
 判断每个 PR：
 - **有效项目提交**（对 README 的修改，含产品名 + URL）→ 直接合并：
   ```bash
-  gh pr merge <number> --squash --yes
+  gh pr merge <number> --squash
   ```
   - 如果合并成功：在该 PR 发感谢评论，需说清楚收录到了哪个版面（根据 PR 修改的是 README.md / pages/README-Programmer-Edition.md / pages/README-Game.md 中的哪个文件，对应主版面/程序员版面/游戏版面），立即捕获 ID 并 PATCH 去掉署名：
     ```bash
@@ -217,7 +208,7 @@ gh api "repos/1c7/chinese-independent-developer/pulls?state=open&per_page=50" \
 
 ⚠️ 严格禁止：检查三的 PR **无冲突时**必须走上面的 `gh pr merge --squash`，不能走通用处理流程（那样会丢失贡献者的 git 归属）。**有冲突时**才使用上面的本地合并步骤，因为 `git merge --no-ff` 会保留贡献者原始 commit 的作者信息，不会丢失归属。
 
-⚠️ PR 合并后要检查描述格式（`gh pr merge` 是原样合并贡献者写的文字，不会自动清理）：如果存在「中英文/数字之间没有空格」「一个、一款、高效、简洁、强大等填充词」「产品类型被埋在长修饰语最后面（如"是一个基于 X、Y、Z 构建的 W"这种结构，应改成"W，基于 X、Y、Z 构建"把 W 提前）」这几类问题，合并完之后**单独用 Edit 工具再发一条格式整理的 commit**（只改标点空格和语序，不改事实信息，也不算作「修改已有条目」——因为这是本次新增内容的同一批次收尾，不是改动历史上已收录的条目）。不要把这类清理和「新增」提交混在一条 commit 里，保持 commit 语义清晰。
+⚠️ PR 合并后要检查描述格式（`gh pr merge` 是原样合并贡献者写的文字，不会自动清理）：如果存在「中英文/数字之间没有空格」「一个、一款、高效、简洁、强大等填充词」「产品类型被埋在长修饰语最后面（如"是一个基于 X、Y、Z 构建的 W"这种结构，应改成"W，基于 X、Y、Z 构建"把 W 提前）」这几类问题，合并完之后**单独用本地编辑工具再发一条格式整理的 commit**（只改标点空格和语序，不改事实信息，也不算作「修改已有条目」——因为这是本次新增内容的同一批次收尾，不是改动历史上已收录的条目）。不要把这类清理和「新增」提交混在一条 commit 里，保持 commit 语义清晰。
 
 ---
 
@@ -249,7 +240,7 @@ gh api "users/<username>/repos?sort=updated&per_page=10" | jq '[.[] | {name, des
 - 检查二（独立 issue）：不进入「通用处理流程」，在该 issue 下礼貌回复后 `gh issue close <number>`
 - 检查三（PR）：不合并，在 PR 下礼貌评论后 `gh pr close <number>`（不使用 `gh pr merge`）
 
-**拒绝评论模板**（用提交者使用的语言回复，语气礼貌简短，不解释具体判断依据，不含 Claude 署名——POST 后同样要 PATCH 去署名并 GET 验证）：
+**拒绝评论模板**（用提交者使用的语言回复，语气礼貌简短，不解释具体判断依据；POST 后同样要 PATCH 并 GET 验证）：
 ```
 感谢分享 <产品名>！不过本仓库只收录中国独立开发者的项目（README 开头写明"聚合所有中国独立开发者的项目"），所以暂时不在收录范围内，抱歉。祝 <产品名> 发展顺利！
 ```
@@ -303,7 +294,7 @@ Thanks for sharing <product>! This repo specifically curates projects made by Ch
 
 ### 步骤3：插入文件并批量提交到 master
 
-先用 Read 工具读取目标 README 了解格式，用 Edit 工具插入条目。**新条目插入当天日期区块的最顶部**（紧接日期标题行之后的空行后面）。
+先读取目标 README 了解格式，再用本地编辑工具插入条目。**新条目插入当天日期区块的最顶部**（紧接日期标题行之后的空行后面）。
 
 如果当天日期区块尚不存在，则在最新日期区块之前新建。
 
@@ -311,7 +302,7 @@ Thanks for sharing <product>! This repo specifically curates projects made by Ch
 
 ```bash
 git checkout master && git pull origin master
-# （用 Edit 工具对各 README 文件做完所有修改）
+# （用本地编辑工具对各 README 文件做完所有修改）
 git add README.md pages/README-Programmer-Edition.md pages/README-Game.md
 git commit -m "新增：<项目1名>、<项目2名>、..."
 git push origin master
@@ -323,7 +314,7 @@ git push origin master
 
 ---
 
-## 最后一步：逐人发感谢评论并删除 Claude 署名（仅针对检查一的提交者）
+## 最后一步：逐人发感谢评论并验证正文（仅针对检查一的提交者）
 
 所有三个检查都处理完之后，如果检查一中成功收录了项目，在 issue #160 为**每位来自检查一的成功提交者单独发一条评论**：
 
@@ -337,7 +328,7 @@ git push origin master
 - 检查二的提交者不要 @ 到这里（他们已在各自的 issue 里收到了感谢）
 - 如果检查一没有成功处理任何项目，不发评论
 
-Claude Code 会自动在正文末尾追加署名。每位用户的评论都必须分别执行 POST、立即 PATCH，再 GET 验证署名已删除：
+每位用户的评论都必须分别执行 POST、立即 PATCH，再 GET 验证正文准确且没有历史自动化署名：
 
 ```bash
 CLEAN_BODY="@user 感谢提交，已将你的产品 Product 添加到主版面！"

.claude/skills/chinese-indie-dev/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "收录中国独立开发者项目"
+  short_description: "检查 GitHub 提交并维护中国独立开发者项目列表"
+  default_prompt: "使用 $chinese-indie-dev 检查并处理这个仓库当前待收录的项目。"
+
+policy:
+  allow_implicit_invocation: true