整理：感谢评论去掉客套话和处理过程细节

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

@@ -33,6 +33,8 @@ allowed-tools:
 
 ⚠️ 三个版面的**固定名称**是「主版面」「程序员版面」「游戏版面」——都以"版面"两个字结尾，不是"主版"/"程序员版"/"游戏版"。所有感谢评论、PR/issue 评论中提到版面名称的地方，写完之后要逐字核对有没有漏掉"面"字（历史运行中出现过在感谢评论里把"程序员版面"错写成"程序员版"的情况，且没有被自动校验发现）。
 
+⚠️ 感谢评论必须简短，只说结果，不说过程：固定句式是「@用户名 感谢提交，你的产品 X 已添加到 Y 版面！」（或已收录多个产品时按本文档后面给的变体）。**禁止**在评论里额外加"谢谢！"这类结尾客套话（前面已经有"感谢提交"了，不需要再谢一次）；**禁止**提及处理过程中的内部细节，例如"PR 有冲突"「已由我们手动合并」「已手动处理」之类——不管背后是直接合并、手动解决冲突、还是走 issue 流程，提交者只需要知道结果（收录到了哪个版面），不需要知道我们是怎么做到的。发送前对照这条逐字检查。
+
 ---
 
 ## 预检：快速判断是否有任何新内容
@@ -157,9 +159,9 @@ gh api "repos/1c7/chinese-independent-developer/pulls?state=open&per_page=50" \
        ```bash
        git push origin master
        ```
-    4. 因为贡献者的分支落后于 master、GitHub 无法用按钮直接标记该 PR 为 merged，所以改为关闭 PR 并说明已手动合并、保留致谢：
+    4. 因为贡献者的分支落后于 master、GitHub 无法用按钮直接标记该 PR 为 merged，所以改为关闭 PR 并致谢。**评论正文不要提冲突、不要提手动合并这类处理过程细节**，提交者不需要知道内部是怎么处理的，只需要知道结果：
        ```bash
-       CLEAN_BODY="@<提交者用户名> 感谢提交，PR 有冲突，已由我们手动合并，你的产品 <产品名> 已添加到 <主版面/程序员版面/游戏版面>，谢谢！"
+       CLEAN_BODY="@<提交者用户名> 感谢提交，你的产品 <产品名> 已添加到 <主版面/程序员版面/游戏版面>！"
        gh pr close <number> --comment "$CLEAN_BODY"
        ```
     5. 如果冲突内容复杂到无法安全判断该保留什么（例如冲突不只是新增条目，而是修改了已有内容的结构），**不要瞎猜、不要删除任何已有内容**，改为在 PR 里说明具体冲突原因并保持 PR 打开，等待人工介入；但这应是极少数情况，绝大多数「新增条目」型冲突都应该自动解决。