| name | plain-language-with-westonnnn |
| description | Use this skill before sending any message to @westonnnn or to Feishu human users/groups via Musk agents. Forces plain-language Chinese — friendly opening, clear problem/background/help request, short sentences, concrete examples, no jargon stacks, no English technical terms when Chinese works. Catches the common failure of agent jargon-heavy writing. |
| allowed-tools | null |
Plain language when talking to @westonnnn or Feishu humans
硬规则 — 给 westonnnn / 飞书人类发消息前过一遍
- 像朋友聊天一样开头 — 先礼貌招呼或自然提醒，不要上来就是公文、命令、术语堆。
- 开头抓住注意力 — 前两句说清楚：现在遇到什么问题、背景是什么、为什么需要他帮忙。
- 请求要具体 — 只问需要人类决策 / 帮忙的事。不要把日志、路径、证据包、环境细节一股脑塞给人类。
- 不堆术语 — 一个句子里不要塞 3 个以上专门词。"Doctrine D recursive self-application" 这种词放给同行，不是给人类快速决策用的。
- 能用中文就别用英文 — 不要 "trailer hygiene"、"single source"、"forward-decl"、"layer-aware"、"cascade"。中文换成"提交时把 AI 标记清掉"、"只在一篇里写、其他篇引用"、"先写引用，等被引用的文档落地"、"分层来看"、"连锁问题"。
- 短句优先 — 一句话讲一件事。看到长句子就拆开。
- 具体例子比抽象好 — 别说"推行一致性原则"，说"今天合并了 3 个 PR，所有 doc 的标题格式都对齐了"。
- 状态更新用列表 — 别写一大段连续文字。三条以内的清单更好读。
- 数字代替形容词 — "今天 land 16 个 PR" 比 "今天进展很顺" 好。
- 不带情绪渲染 — 不写"非常 / 极其 / 非常重要"。事实自己说话。
何时调用
每次给 westonnnn 发消息前都过一遍：
- DM 直接回复
- 状态汇报
- 提问 / 求决策
- 发现问题报告
- 通过 Musk3 / Musk1 发给飞书群或飞书人类的消息
- 请求人类 owner review PR、给权限、给镜像、指定 owner、确认环境
飞书外发结构
给飞书群或人类 owner 的消息用这个顺序：
<自然称呼>，我这边有个小事需要你帮忙看一下。
现在卡在：<一句话说问题>。
背景是：<一句话说为什么会卡>。
需要你帮忙决定/提供：<一件具体事>。
我这边不会停着等，会先做 <agent 能并行做的 patch / 验证 / 准备>。
你方便时帮忙确认 <owner / 权限 / 镜像 / review> 就行。
技术细节放最后，且只放人类判断需要的最少内容。
反例 → 改写
反例 1（太多英文术语）
❌ "今天 sediment 了 A6 doctrine 的 squash-merge contributor email leak variant，narrowed trigger condition 到 multi-author cross-hostname。"
✅ "发现一个新坑：GitHub 的 squash merge 有时候会把开发者的 email 自动加到 commit 里。发生条件是这个 PR 有多个不同 git 配置的作者，单作者的 PR 不会有这个问题。"
反例 2（嵌套 framing）
❌ "consolidated [style-harmonize] sweep 的 trigger condition 调整为 (Tom shared-cluster-resilience + Kevin step-closure) two land。"
✅ "等 Tom 那篇 shared-cluster 文档和 Kevin 那篇 step-closure 文档都合并了，我再做一次清理。"
反例 3（炫技式精确）
❌ "PR #62 §3.9 ALLOW_PENDING flag 实现 gap + cascade Ops Succeed check 漏掉。"
✅ "PR #62 那篇文档里 §3.9 提到的 ALLOW_PENDING 这个开关有 bug：开了之后还是会因为 OpsRequest 没成功被判 FAIL。"
反例 4（结构感太强）
❌ "今日 PR landings: 17 PRs land 到 main，6/6 IDC vcluster ecosystem complete，2 个新 doctrine doc 落地，单 day curator activity peak。"
✅ "今天合并了 17 个 PR：IDC 测试环境的 6 篇文档全 land 了，又新增 2 篇方法论文档。"
自检 (3 question)
发出前问自己：
- 如果删掉所有英文专门词，意思还能传达吗？ 不能 → 重写
- westonnnn 看一眼能 30 秒理解吗？ 不能 → 拆短
- 里面有没有"看着很专业"但其实没传达事实的形容词？ 有 → 删掉
例外
可以保留英文：
- 项目名（KubeBlocks / Claude Code / Codex）
- PR 号（PR #69）
- 文件名（
addon-X-guide.md）
- 命令（
git commit）
- 标识符（commit hash）
- 已被全公司熟悉的术语（如"smoke 测试"、"chaos 测试"——但更专业的不行）
触发场景
如果你正在写：
- 给 westonnnn 的 DM
- 给 westonnnn 看的 #all 公告（westonnnn-only post 时 — 现在 #all silence 状态除外）
- 涉及 westonnnn 决策的报告
- 给其他人转给 westonnnn 看的内容
- 给 @Musk3 的飞书外发请求
- 需要飞书人类处理的权限、环境、镜像、owner、review 请求
→ 跑这个 skill
与其他 skill 的关系
evidence-discipline — 这个 skill 管"证据强度对齐描述强度"；本 skill 管"语言层级降到对方能懂"。两个都要跑：先 evidence 自检，再大白话改写。team-skill-rollout — 跨成员推 skill 的工程流程；本 skill 是"和老板说话"的人际流程。
历史背景（自己记着）
westonnnn 多次提到"大白话"：
- 2026-05-04 21:16 (msg=e4071009): 所有人发消息都说大白话
- 2026-05-05 09:25: 计算量浪费的根因之一是堆砌信息
- 2026-05-05 16:31: 让我专门写这个 skill
理解：他不是不懂技术，是不想花时间解析 agent 用术语堆出来的句子。直接讲事情快。
