skill v2.0：格式问题不得作为关闭理由；分类前必须验证是否开箱即用

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

@@ -7,7 +7,7 @@ description: >
   当用户说"处理提交"、"处理 issue"、"跑一下列表"时使用。
 metadata:
   author: 1c7
-  version: "1.9"
+  version: "2.0"
   lang: zh-CN
 allowed-tools:
   - Bash
@@ -35,6 +35,21 @@ allowed-tools:
 
 ⚠️ 三个版面的**固定名称**是「主版面」「程序员版面」「游戏版面」——都以"版面"两个字结尾，不是"主版"/"程序员版"/"游戏版"。所有感谢评论、PR/issue 评论中提到版面名称的地方，写完之后要逐字核对有没有漏掉"面"字（历史运行中出现过在感谢评论里把"程序员版面"错写成"程序员版"的情况，且没有被自动校验发现）。
 
+⚠️ **格式问题绝不能作为关闭 PR / Issue / 拒绝收录的理由。** 提交格式再乱（一行纯文本、没有 `####` 作者行、没有 `:white_check_mark:`、中英文没空格、描述像广告词），都只是我们收尾时要清理的事，不是拒绝提交者的理由。允许关闭的理由只有两类：**垃圾广告/无关内容**，以及**非中国开发者**。正确做法是先合并/先收录，再按下面的格式规范单独发一条整理 commit。历史上出现过 bot 以"格式和本仓库的收录要求不符"为由关掉了一个本可以合并的 PR（#1205），这是错误的。发拒绝评论前，逐字检查理由里有没有出现"格式"两个字——如果有，说明这次拒绝就是错的，退回去改成合并。
+
+⚠️ **分类前必须真的打开产品链接看一眼，不能只凭标题和描述猜版面。** 主版面和程序员版面的分界是「终端用户能不能直接用」：
+- 有官网/网页版可以直接打开使用，或提供了可下载安装的成品（App Store、release 页面里的 .dmg/.exe/.apk 等）→ 主版面
+- 只能 `git clone` + 自己跑（docker compose、npm install、./gradlew、pip install、命令行工具、需要自建服务或填 API key 才能启动）→ 程序员版面
+
+验证方式（**每个待收录项目都要做，PR 也不例外**）：
+```bash
+# GitHub 项目：看有没有官网 homepage、有没有带二进制的 release
+gh api repos/<owner>/<repo> | jq '{homepage, description}'
+gh api repos/<owner>/<repo>/releases | jq -r '.[] | .tag_name + " | assets: " + ([.assets[].name] | join(", "))' | head
+# 再读 README 的安装/快速开始章节，看第一步是不是 git clone / docker / 包管理器命令
+```
+`homepage` 为空、release 没有任何 assets、README 快速开始第一步就是 `git clone` 或 `docker compose up` —— 满足这些即为程序员版面。历史上出现过 Site Guard（自托管 Docker 部署的监控工具）被直接合并进主版面的错误（PR #1206）。⚠️ 注意：检查三的 PR 走的是直接合并、不经过「通用处理流程」的步骤2，但**版面判断这一步对 PR 同样必须做**——贡献者自己选的文件经常是错的，合并后要立刻按上面的方式核对，判断错了就把条目移到正确的版面并单独发一条修正 commit，同时 PATCH 修正已发出的感谢评论里的版面名称。
+
 ⚠️ 感谢评论必须简短，只说结果，不说过程：固定句式是「@用户名 感谢提交，你的产品 X 已添加到 Y 版面！」（或已收录多个产品时按本文档后面给的变体）。**禁止**在评论里额外加"谢谢！"这类结尾客套话（前面已经有"感谢提交"了，不需要再谢一次）；**禁止**提及处理过程中的内部细节，例如"PR 有冲突"「已由我们手动合并」「已手动处理」之类——不管背后是直接合并、手动解决冲突、还是走 issue 流程，提交者只需要知道结果（收录到了哪个版面），不需要知道我们是怎么做到的。发送前对照这条逐字检查。
 
 ---
@@ -192,6 +207,7 @@ gh api "repos/1c7/chinese-independent-developer/pulls?state=open&per_page=50" \
   - **不允许**的做法：连续多次发送「请 rebase / 请解决冲突后重新提交」这类要求人类提交者自己解决冲突的评论。冲突处理是我们的责任，不是提交者的。
 - **垃圾广告、无关内容** → 直接关闭：`gh pr close <number>`
 - **非中国开发者（老外）** → 不合并，按下方「身份判断」章节的拒绝流程处理：礼貌评论说明后 `gh pr close <number>`，不使用 `gh pr merge`
+- **格式乱、不符合模板** → 这不是关闭理由，照常合并，合并后按下面「PR 合并后要检查描述格式」的要求单独发一条格式整理 commit（见文档开头的格式禁令）
 
 ⚠️ 严格禁止：检查三的 PR **无冲突时**必须走上面的 `gh pr merge --squash`，不能走通用处理流程（那样会丢失贡献者的 git 归属）。**有冲突时**才使用上面的本地合并步骤，因为 `git merge --no-ff` 会保留贡献者原始 commit 的作者信息，不会丢失归属。
 
@@ -270,8 +286,8 @@ Thanks for sharing <product>! This repo specifically curates projects made by Ch
 
 | 类别 | 判断标准 | 目标文件 |
 |------|---------|----------|
-| 主版面 | 打开即用的网站或 App，非游戏 | README.md |
-| 程序员版面 | 需要命令行/写代码/安装依赖 | pages/README-Programmer-Edition.md |
+| 主版面 | 打开即用的网站或 App，非游戏（有官网可直接使用，或有可下载安装的成品包） | README.md |
+| 程序员版面 | 需要命令行/写代码/安装依赖（`git clone`、docker compose、npm/pip 安装、自建服务、需填 API key 才能跑） | pages/README-Programmer-Edition.md |
 | 游戏版面 | 任何游戏类产品 | pages/README-Game.md |
 | 拒绝 | 论坛、无 URL、垃圾广告、无法判断、或提交者非中国开发者（见上方「身份判断」） | 不处理 |