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

适配 Codex 项目收录 skill

Browse Source
This commit is contained in:
ZhengCheng
2026-08-14 19:28:53 +08:00
parent fffaeb6cc4
commit 98c56d9dac
3 changed files with 20 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.agents/skills/chinese-indie-dev Symbolic link
View File

@@ -0,0 +1 @@
../../.claude/skills/chinese-indie-dev

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

@@ -4,16 +4,7 @@ description: >
处理 1c7/chinese-independent-developer 仓库的项目提交。 处理 1c7/chinese-independent-developer 仓库的项目提交。
检查 issue #160 新评论、新开的 Issue、新开的 PR， 检查 issue #160 新评论、新开的 Issue、新开的 PR，
将有效项目添加到对应 README，关闭垃圾内容。 将有效项目添加到对应 README，关闭垃圾内容。
当用户说"处理提交"、"处理 issue"、"跑一下列表"时使用。 当用户要求“收录项目”“处理提交”“处理 issue”“跑一下列表”或运行中国独立开发者列表维护流程时使用。
metadata:
author: 1c7
version: "2.3"
lang: zh-CN
allowed-tools:
- Bash
- Read
- Edit
- Write
--- ---
# 中国独立开发者列表：处理项目提交 # 中国独立开发者列表：处理项目提交
@@ -25,11 +16,11 @@ allowed-tools:
⚠️ 严格禁止：不得以任何理由删除或修改 README 中已有的条目。本 skill 的唯一允许操作是**新增**。如果发现疑似重复，只需跳过，绝对不能删除。 ⚠️ 严格禁止：不得以任何理由删除或修改 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 有效就直接收录。 ⚠️ 本仓库**只收录中国独立开发者**的项目（仓库标题即「中国独立开发者项目列表」）。检查一、二、三的每一位提交者，在进入「通用处理流程」或合并 PR 之前，都必须先按下方「身份判断」章节确认是中国人，确认是老外的一律礼貌拒绝、不收录，绝不能因为产品本身质量好、URL 有效就直接收录。
@@ -39,7 +30,7 @@ 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"。** 历史事故：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）。 ⚠️ **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： 判断每个 PR：
- **有效项目提交**（对 README 的修改，含产品名 + URL）→ 直接合并： - **有效项目提交**（对 README 的修改，含产品名 + URL）→ 直接合并：
```bash ```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 去掉署名： - 如果合并成功：在该 PR 发感谢评论，需说清楚收录到了哪个版面（根据 PR 修改的是 README.md / pages/README-Programmer-Edition.md / pages/README-Game.md 中的哪个文件，对应主版面/程序员版面/游戏版面），立即捕获 ID 并 PATCH 去掉署名：
```bash ```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 --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>` - 检查二（独立 issue）：不进入「通用处理流程」，在该 issue 下礼貌回复后 `gh issue close <number>`
- 检查三（PR）：不合并，在 PR 下礼貌评论后 `gh pr close <number>`（不使用 `gh pr merge`） - 检查三（PR）：不合并，在 PR 下礼貌评论后 `gh pr close <number>`（不使用 `gh pr merge`）
**拒绝评论模板**（用提交者使用的语言回复，语气礼貌简短，不解释具体判断依据，不含 Claude 署名——POST 后同样要 PATCH 去署名并 GET 验证）： **拒绝评论模板**（用提交者使用的语言回复，语气礼貌简短，不解释具体判断依据；POST 后同样要 PATCH 并 GET 验证）：
``` ```
感谢分享 <产品名>！不过本仓库只收录中国独立开发者的项目（README 开头写明"聚合所有中国独立开发者的项目"），所以暂时不在收录范围内，抱歉。祝 <产品名> 发展顺利！ 感谢分享 <产品名>！不过本仓库只收录中国独立开发者的项目（README 开头写明"聚合所有中国独立开发者的项目"），所以暂时不在收录范围内，抱歉。祝 <产品名> 发展顺利！
``` ```
@@ -303,7 +294,7 @@ Thanks for sharing <product>! This repo specifically curates projects made by Ch
### 步骤3：插入文件并批量提交到 master ### 步骤3：插入文件并批量提交到 master
先用 Read 工具读取目标 README 了解格式，用 Edit 工具插入条目。**新条目插入当天日期区块的最顶部**（紧接日期标题行之后的空行后面）。 先读取目标 README 了解格式，再用本地编辑工具插入条目。**新条目插入当天日期区块的最顶部**（紧接日期标题行之后的空行后面）。
如果当天日期区块尚不存在，则在最新日期区块之前新建。 如果当天日期区块尚不存在，则在最新日期区块之前新建。
@@ -311,7 +302,7 @@ Thanks for sharing <product>! This repo specifically curates projects made by Ch
```bash ```bash
git checkout master && git pull origin master git checkout master && git pull origin master
# （用 Edit 工具对各 README 文件做完所有修改） # （用本地编辑工具对各 README 文件做完所有修改）
git add README.md pages/README-Programmer-Edition.md pages/README-Game.md git add README.md pages/README-Programmer-Edition.md pages/README-Game.md
git commit -m "新增：<项目1名>、<项目2名>、..." git commit -m "新增：<项目1名>、<项目2名>、..."
git push origin master git push origin master
@@ -323,7 +314,7 @@ git push origin master
--- ---
## 最后一步：逐人发感谢评论并删除 Claude 署名（仅针对检查一的提交者） ## 最后一步：逐人发感谢评论并验证正文（仅针对检查一的提交者）
所有三个检查都处理完之后，如果检查一中成功收录了项目，在 issue #160 为**每位来自检查一的成功提交者单独发一条评论**： 所有三个检查都处理完之后，如果检查一中成功收录了项目，在 issue #160 为**每位来自检查一的成功提交者单独发一条评论**：
@@ -337,7 +328,7 @@ git push origin master
- 检查二的提交者不要 @ 到这里（他们已在各自的 issue 里收到了感谢） - 检查二的提交者不要 @ 到这里（他们已在各自的 issue 里收到了感谢）
- 如果检查一没有成功处理任何项目，不发评论 - 如果检查一没有成功处理任何项目，不发评论
Claude Code 会自动在正文末尾追加署名。每位用户的评论都必须分别执行 POST、立即 PATCH，再 GET 验证署名已删除： 每位用户的评论都必须分别执行 POST、立即 PATCH，再 GET 验证正文准确且没有历史自动化署名：
```bash ```bash
CLEAN_BODY="@user 感谢提交，已将你的产品 Product 添加到主版面！" CLEAN_BODY="@user 感谢提交，已将你的产品 Product 添加到主版面！"

7
.claude/skills/chinese-indie-dev/agents/openai.yaml Normal file
View File

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