docs(talk-like-scarletkc): loosen tweet voice guidance

skills/talk-like-scarletkc/SKILL.md

@@ -30,8 +30,8 @@ scarletkc 的文字像一个有情绪、有明确判断的开发者在实时分
 
 1. 直接进入内容。第一句话承载真正想说的东西：判断、发现、情绪、具体
    问题或有意思的反差。不写"当然可以""这是一个很有意思的问题"一类开场。
-2. 使用第一人称。我感觉、我觉得、对我来说、好像、其实。技术评价和产品
-   体验明确是个人体验，不假装绝对客观。
+2. 自然使用第一人称。我感觉、我觉得、对我来说、好像、其实。技术评价和
+   产品体验明确是个人体验；介绍事实时不必硬加我觉得。
 3. 保留即时感。允许先给反应再解释原因，短句和长说明混用，节奏自然
    不规则。但不要故意制造错别字、语病或漏字。
 4. 保留情绪。惊讶、兴奋、失望、烦躁、自嘲和吐槽按原始内容自然保留，
@@ -107,6 +107,8 @@ scarletkc 的文字像一个有情绪、有明确判断的开发者在实时分
    经历或观点。
 6. 默认只输出可直接使用的成稿。用户要求解释时，把说明放在正文之外；
    核心立场缺失时，先按第 2 步澄清。
+   修改已经认可的推文时，保留原有语气和中心判断，默认给整合后的完整稿。
+   用户只要一句或局部时按指定范围返回，不因修正一个事实而重新设计整篇。
 
 ## 交付前自检
 

skills/talk-like-scarletkc/evals/evals.json

@@ -410,6 +410,30 @@
         "成稿和说明清楚分开，可单独复制成稿"
       ],
       "files": []
+    },
+    {
+      "id": 31,
+      "name": "social-casual-rhythm",
+      "prompt": "帮我润色成短推文：找了半天导出按钮 结果在右键菜单里，笑死 谁能想到啊",
+      "expected_output": "保留随口吐槽和自然停顿，不主动写成正式的产品体验小结。允许正常标点，不要求某一种标点布局。",
+      "assertions": [
+        "保留找了半天、右键菜单和觉得意外的反应，没有添加产品名称或未提供的经历",
+        "语气接近原稿，没有改成正式的使用反馈、设计评价或改进建议",
+        "不为书面完整补解释或总结，也不为随意而额外添加口头禅、错字或符号噪声"
+      ],
+      "files": []
+    },
+    {
+      "id": 32,
+      "name": "social-technical-punctuation-remains-flexible",
+      "prompt": "按我的语气写条技术推文，下面是虚构实验的完整材料，别为了短删掉关键条件：同一模型面对同一组越权请求，在请求前一轮提醒别越权，100次里90次停止。使用相同提醒，但提醒后先聊三轮无关内容再发越权请求，另外100次里只有40次停止。目前只测试了这一个模型。",
+      "expected_output": "自然但清楚的技术推文，保留必要标点和解释，不把口语偏好变成极短聊天，也不强加个人亲测经历。",
+      "assertions": [
+        "清楚区分紧邻请求的提醒和间隔三轮无关对话的提醒，保留两组各100次及90次、40次停止的结果",
+        "保留仅测试一个模型的范围，不声称所有模型都会如此或用户亲自做了实验",
+        "标点和分段足以读清条件、比较与结果，没有为了松散风格删掉必要关系或切成聊天碎片"
+      ],
+      "files": []
     }
   ]
 }

skills/talk-like-scarletkc/references/surface-profiles.md

@@ -72,9 +72,9 @@ Chat mode 内部还分两个子场景，松紧度差别很大。先判断是跟
 
 适用于 X、微博、评论和公开短文。
 
-- 第一行直接给观点或情绪
+- 第一行直接给具体事实、观点或情绪
 - 一条内容集中表达一个主要想法
-- 保留第一人称
+- 保留已有的第一人称，事实介绍不强加个人体验
 - 可以有轻微吐槽、反讽和自嘲
 - 使用具体经历和细节
 - 有字面说法就使用字面说法，不添加为了显得聪明或深刻的修辞
@@ -86,6 +86,18 @@ Chat mode 内部还分两个子场景，松紧度差别很大。先判断是跟
 用户要求增强流量时，第一句可以使用素材里最强的事实、反差或个人判断。
 不要套万能爆款句式，也不要编造重要性、紧迫性和读者共识。
 
+### 推文的松紧度
+
+推文默认偏口语，不主动提高原稿的正式程度。她反馈过话术和标点太标准，
+需要一起调整措辞、句子和停顿，不能只删几个句号。
+
+- 清楚的短句、省略主语和随口补充可以保留，不必补成完整书面句。
+  能说又买了一遍、直接给退了，就不必改成重复订阅、退款申请获得批准。
+- 短段末可以不加句号，也可以用换行或少量空格停顿。标点按理解需要使用，
+  不强制每段一致，也不机械删标点或把每句话拆成一行。
+- 吐槽和短反应可以更松，技术解释按需要说完整。不要套用私聊的极短字数、
+  标点比例和全小写习惯，也不额外塞口头禅来制造随意感。
+
 ### 使用外部素材
 
 用户给出文章、英文推文、引用、截图文字或发布说明时，先分开整理：
@@ -101,12 +113,13 @@ Chat mode 内部还分两个子场景，松紧度差别很大。先判断是跟
 脑损伤病例，用户要谈 GPT 和 OpenAI 的开发理念，病例只负责提供证据，
 成稿要围绕记忆、人格、情绪或价值判断等她实际指定的方向展开。
 
-发布说明通常只选一到两个能够支撑判断的变化。用户已经给出"终于争气了"
+发布说明按用户角度选值得讲的变化，不固定数量。用户已经给出"终于争气了"
 一类中心态度时，让功能细节解释这个态度，不要把整份 changelog 换成中文。
 
 ### 常见 Social 形态
 
-- 新闻加判断：第一句放最重要的新事实或个人反应，后面说明她怎么看。
+- 新闻加判断：开头简短交代事件，再接她的判断；情绪开头也要让读者知道
+  具体发生了什么。
 - 技术观点：先给使用体验或结论，再用具体功能、行为或工作流支撑。
 - 回复和评论：直接回应对方当前那句话，通常比主帖更短，不重讲完整背景。
 - 主帖加跟帖：信息确实放不下一条或用户明确要求时再拆。普通回复链的主帖