chinese-independent-developer Skill

Der folgende Text stammt aus dem Repo des Anbieters, nicht von PopNx MCP

---
name: chinese-indie-dev
description: >
  处理 1c7/chinese-independent-developer 仓库的项目提交。
  检查 issue #160 新评论、新开的 Issue、新开的 PR，
  将有效项目添加到对应 README，关闭垃圾内容，并把评论区的意见与建议上报维护者。
  历史判例与事故记录在同目录的 references/precedents.md，遇到边界判断时按需查阅。
  当用户要求“收录项目”“处理提交”“处理 issue”“跑一下列表”或运行中国独立开发者列表维护流程时使用。
---

# 中国独立开发者列表：处理项目提交

处理 `1c7/chinese-independent-developer` 的项目提交：扫 #160 评论、open issue、open PR，有效的收进对应 README，无效的按类别拒绝，评论区里的意见与建议单独上报。

**阅读顺序**：本文是流程和硬约束，每次运行完整读一遍。本文写「→ 判例：X」的地方，是历史上踩过的坑，遇到对应情况再去读 `references/precedents.md` 的 X 节，**不要在执行时全量加载判例库**。

## 硬红线（与任何下文冲突时，以本节为准）

1. **不得调用添加 reaction 的 API。**
2. **不得删除或修改他人已有条目**；唯一例外是产品作者本人要求更新自己的条目（换 URL、改描述）。
3. **合并 PR 前必须 `gh pr diff` 逐行审查**，diff 里出现删他人条目的 `-` 行，一律先恢复再合并，绝不让删除落进 master。
4. **所有 GitHub 操作只能走 shell 里的 `gh` / `git`**，保证用的是维护者 1c7 的 PAT；不用 GitHub Connector 或平台原生 GitHub 工具。本地文件读写用当前运行环境自带的工具。
5. **格式问题绝不能作为拒绝 / 关闭理由。** 允许拒绝的只有：垃圾广告、非中国开发者、大厂产品、返佣链接、刷量平台。**链接打不开是「暂不收录、等补链」，既不是拒绝也不是关闭理由**（→ 判例：M）。
6. **状态图标、描述文字以提交者为准。** 提交者写 🕗 就是 `:clock8:`，不许改成 ✅；不许拿官网资料重写他的简介。
7. **版面名称固定写「主版面」「程序员版面」「游戏版面」**，带「面」字。
8. **每一次拒绝都必须在最终汇报里单列**，不许悄悄处理掉；致谢评论不用列。
9. **评论区里的意见与建议只上报、不处置**：不改、不删、不回复、不关闭。
10. 版面判断必须点开产品链接实际看一眼，不能凭标题猜。
11. **遇到身份、拒绝、版面、格式、去重、PR、容量、签名、接口任一类判断，先读 `references/precedents.md` 对应小节再拍板**，那是维护者已经定过调的先例；不要让"想当然"覆盖踩过的坑。

---

## 0. 预检

### 0.1 环境自检（先跑这个，不通过就停）

```bash
git status --short                                                   # 必须为空
git fetch origin master && git rev-list --count HEAD..origin/master   # 必须为 0
gh auth status | head -5                                             # 必须是 1c7 本人的 PAT
```

- 落后远端 → `git pull --rebase origin master` 再开始。
- 工作区有改动 → 多半是上次运行中断，先 `git diff` 看清是补完还是丢弃，不要直接 `checkout --`。

### 0.2 三个计数

```bash
SINCE=$(date -u -d '72 hours ago' +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -v-72H +%Y-%m-%dT%H:%M:%SZ)

COUNT_COMMENTS=$(gh api "repos/1c7/chinese-independent-developer/issues/160/comments?since=$SINCE&per_page=100" | tee /tmp/c160.json | jq 'length')
COUNT_ISSUES=$(gh api "repos/1c7/chinese-independent-developer/issues?state=open&per_page=50" \
  | jq '[.[] | select(.number != 160 and .pull_request == null)] | length')   # 另有「已知保留 issue」清单，见第 2 节末尾
COUNT_PRS=$(gh api "repos/1c7/chinese-independent-developer/pulls?state=open&per_page=50" \
  | jq '[.[] | select(.head.ref | startswith("auto-add-") | not)] | length')

echo "新评论: $COUNT_COMMENTS  新Issue: $COUNT_ISSUES  待处理PR: $COUNT_PRS"
wc -c README.md
```

- 时间窗统一 **72 小时**（运行间隔不固定，取 3 天余量）。距上次超过 3 天就临时改 `-v-240H`。
- 评论数偏大是正常的：里面混着我们自己的致谢。
- **三个数字全为 0 不等于收工**：仍要跑 0.3 的差集、检查一之二、收尾扫描。
- ⚠️ **`wc -c README.md` 超过 490,000 就地处理，别等到插入条目之后**：运行间隔里别人 merge 也可能顶过线。直接按 6.3 跑 `migrate_archive.py --write`，**即使本次空跑也要单独发一条搬迁 commit**（2026-09-27 实测：开跑时已是 490,082 字节，只想着"这次没新条目"就会把超标状态原样留给下一次）。

### 0.3 差集：只看域名和产品名

**查重永远只看两样东西：产品域名、产品名。提交者是谁、他以前投过几次、隔了几周几个月，统统不参与判断**——同一个作者跨月跨年反复投稿是常态。

```bash
python3 .github/scripts/pending_submissions.py /tmp/c160.json; echo "EXIT=$?"
```

脚本把窗口内每条非我方评论里的 URL 和产品名抽出来，逐个到 README 系列（主版面 / 程序员版面 / 游戏版面 / 两个分册）比对，按结果打三种标签：

| 标签 | 含义 | 怎么办 |
|---|---|---|
| `[新]` | 域名和产品名都没命中 | 正常新提交，进检查一 |
| `[同名]` | 产品名命中、域名没命中 | 重点看：老产品换域名 → 照常收录，描述必须写它独有的功能点；纯重复 → 静默跳过，不发致谢 |
| `[无链接]` | 只有裸 URL、没写产品名 | 人看，判断是提交还是垃圾 |

- 输出「无待处理项」→ 本次确实没有新提交，可以空跑。
- 作者主页 / 博客 / 社交页会混在输出里，看一眼跳过。
- **禁止用「提交者 - 已致谢」的用户名差集来查重**。撞过两次：huangy7（2026-10-10）、stimQQ（2026-10-21，LayerGrab 已收，又投 Flux3Max）。按人去重会把老作者的新投稿整批遮掉（→ 判例：F）。
- 用户名差集只剩一个用途：交叉核对有没有**漏发致谢**。不参与「该不该收」的判断。

---

## 1. 检查一：#160 的新评论

```bash
SINCE=$(date -u -d '72 hours ago' +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -v-72H +%Y-%m-%dT%H:%M:%SZ)
gh api "repos/1c7/chinese-independent-developer/issues/160/comments?since=$SINCE&per_page=100"
```

对每条评论提取产品 URL，查是否已在任一分册：

```bash
grep -rF "<产品完整URL>" README.md .github/pages/README-Programmer-Edition.md .github/pages/README-Game.md
```

**去重规则**
- 必须用完整 URL 精确匹配（`grep -F`），禁止用产品名或关键词判断重复。
- URL 已存在 → 跳过，且**不发致谢**（说「已添加」会误导）。
- URL 不存在 → 进「通用处理流程」。
- 本次运行中已通过 PR 合并的条目视为已存在。
- 同一产品换域名不算拒绝理由，照常收录，但描述必须写出它独有的功能点（→ 判例：F）。

**72h 窗口重叠**：被判「拒绝」的评论不会在 README 留痕迹，URL 去重挡不住重复处理。发拒绝回复前先查这条评论之后有没有我们 `@` 该提交者的回复：

```bash
gh api "repos/1c7/chinese-independent-developer/issues/160/comments?per_page=100" \
  | jq --arg since "<该评论created_at>" \
    '[.[] | select(.created_at > $since and (.user.login=="1c7" or .user.login=="claude[bot]"))]'
```

处理完记录：作者用户名、产品名、目标版面（供第 7 步逐人致谢）。

---

## 1b. 检查一之二：评论区的意见与建议（只上报，不处理）

> 维护者很少回看原文，这类内容不上报等于消失。**每次运行都跑，空跑也跑。**

拉 #160 最新 200 条评论，排除我们自己：

```bash
TOTAL=$(gh api repos/1c7/chinese-independent-developer/issues/160 --jq .comments)
LAST=$(( (TOTAL + 99) / 100 ))
for p in $((LAST-1)) $LAST; do
  gh api "repos/1c7/chinese-independent-developer/issues/160/comments?per_page=100&page=$p"
done | jq -s 'add' \
  | jq -r '.[] | select(.user.login != "1c7" and .user.login != "claude[bot]")
           | "\(.created_at[0:10])\t\(.id)\t@\(.user.login)\n\(.body[0:300])\n---"'
```

⚠️ 单 issue 评论接口的 `sort`/`direction` **无效**、`per_page>100` 会截断并返回**最早**的一批。必须按上面的算法倒着取页（→ 判例：J）。

**判据**：有没有「产品名 + 可访问 URL + 描述」三元组？有 → 是提交，走检查一。没有、说的是列表本身 → 属于本节。

典型内容：指出描述过时/链接失效/分类放错/作者不是中国人/是返佣或刷量站；要求修改或下架自己的条目；质疑收录标准；抱怨重复、排序、分册、格式；建议加版面或字段；版权侵权投诉；对运营方式的不满。

**动作（硬约束）**
- 不改任何条目、不删、不回复、不关闭、不发 reaction。
- 只登记：链接（`https://github.com/1c7/chinese-independent-developer/issues/160#issuecomment-<id>`）、作者、时间、原文摘要（保留原措辞，不改写成中性描述）、类别 + 建议选项。
- 涉及版权/侵权/法律、要求删他人条目、指认刷量返佣 → 标「紧急」，汇报里置顶。
- 不许因为「语气冲」「像广告」就当噪音忽略；也不许顺手替他改了再报「已处理」。
- 已上报的 comment id 记进 automation memory 的「已上报意见评论 id」，下次先排除。

---

## 2. 检查二：所有未关闭的 Issue（排除 #160）

不限时间窗（2026-10-19 调整）：原来只查「最近 72 小时开启」的 issue，一旦某次运行没跑到这步，issue 就永久滑出窗口、再也不会被看到。

```bash
gh api "repos/1c7/chinese-independent-developer/issues?state=open&per_page=50" \
  | jq '[.[] | select(.number != 160 and .pull_request == null)]'
```

- **有效提交** → 进通用处理流程 → 在**该 issue 本身**（不是 #160）发致谢并 PATCH 验证 → **关闭 issue（不能漏）**。
- **垃圾广告、无关内容** → `gh issue close <number>`。
- **对列表本身的意见 / 纠错 / 投诉** → **不是垃圾，不许关**。保持 open，按 1b 的格式登记进汇报。
- **内容不清、信息缺漏** → 不是关闭理由，尽力提取收录；确属纯广告无任何可定位产品才关。
- **确凿是老外** → 按第 4 步拒绝流程。
- 明显是维护者自己的公告 / 征集 / 置顶帖 → 不关闭，**把这个 issue 编号记进 automation memory 的「已知保留 issue」清单**，下次运行直接跳过，不要每次都重新判断一遍。

检查二的提交者已在各自 issue 收到致谢，不需要在第 7 步再 @。

---

## 3. 检查三：所有未关闭的 PR（排除 auto-add- 分支）

```bash
gh api "repos/1c7/chinese-independent-developer/pulls?state=open&per_page=50" \
  | jq '[.[] | select(.head.ref | startswith("auto-add-") | not)]'
```

每个 PR 的处理顺序：

1. `gh pr diff <number>` **逐行看**。有删他人条目的 `-` 行 → 先恢复（`maintainer_can_modify` 为 true 就推到贡献者分支；否则本地合并时恢复），让最终 diff 回到纯新增（→ 判例：G）。
2. 新增行若落在「### 子版面」清单里 → 照常合并，合并后单独 commit 挪到正确位置（普通产品进当天日期区块；基于本列表数据源的产品进 README 底部专属区块）。
3. `gh pr merge <number> --squash`。报 `Base branch was modified` 不是真失败，`sleep 5` 后重查 `mergeable/mergeable_state`，`true`/`clean` 就重试一次（→ 判例：G）。
4. 合并成功后在该 PR 发致谢（POST → PATCH → GET），说清收录到哪个版面。**PR 和 issue 共用编号空间，致谢必须发在 PR 自己的号上**；同一次运行里既有 issue 又有 PR 时逐条核对目标号（→ 第 7 节的串号事故）。
5. 合并失败（冲突）：**由我们解决，绝不要求提交者 rebase**。优先改他分支再 `--merge`；推不了才本地 `git merge --no-ff` + `git push` + `gh pr close` 兜底（→ 判例：G）。冲突复杂到分不清该保留什么（不只是新增条目，而是改了已有结构）→ **不要瞎猜、不要删任何已有内容**，在 PR 里说明冲突原因、保持打开等人工介入。

```bash
# 先取分支信息（冲突路径和推送都靠这两个值）
HEAD_REF=$(gh api repos/1c7/chinese-independent-developer/pulls/<number> | jq -r '.head.ref')
HEAD_REPO_URL=$(gh api repos/1c7/chinese-independent-developer/pulls/<number> | jq -r '.head.repo.clone_url')
MAINTAINER_CAN_MODIFY=$(gh api repos/1c7/chinese-independent-developer/pulls/<number> | jq -r '.maintainer_can_modify')

# maintainer_can_modify=true：改他的分支，让 PR 保持紫色 Merged
git fetch origin master
git fetch origin pull/<number>/head:pr-<number>
git checkout pr-<number> && git merge origin/master --no-edit
# 手工解决冲突：双方新增的条目都保留，冲突标记清干净
git add <冲突文件> && git commit --no-edit
git push "$HEAD_REPO_URL" "pr-<number>:$HEAD_REF"
gh pr merge <number> --merge

# 推不了才兜底（PR 会显示为 Closed，评论里不要提这件事）
git fetch origin master && git fetch origin pull/<number>/head:pr-<number>
git checkout master && git reset --hard origin/master
git merge pr-<number> --no-ff -m "合并 PR #<number>：<项目名>"