菜单
声明≠现实——任何「X 已配置 / 已声明 / 已建立」必须配 margin 量化 + detection 机制，否则把声明当现实。Use when 设计依赖外部能力的方案（vendor partnership / TTL refresh / cron schedule / health check / 配额申请 / SLA 承诺）；或评审「我们已经 X」「客户说会 X」「config 配好了」类陈述；或排查「明明配了为什么没生效」类问题。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
调研开源 repo 看「可偷什么」时，用这个流程——克隆读全源、按 ROI 排清单、审视现有系统、偷抽象不偷代码、融入现有机制不做加法。Use when 用户发 GitHub 链接 + 问「可以偷师 / 借鉴什么」，或你提议要参考外部项目。
Session 收工标准 SOP——任何路径触发「收工」（reaction ✅ / 文字「收工 / wrap up / 闭包」/ cron 自动）都走同一动作链：自测 → commit（含受保护路径 override 规则）→ 清过程产物（临时 spec / debug 输出 / dry-run 文件 / 中间 patch）→ 报 commit hash + 清理清单。Use when 用户说「收工 / 闭包 / wrap up / OK 收工 / 结束这一段」，或 ✅ reaction 触发 inject 含「收工」字样。
Bug 修复 / 排查场景，连续 2 次假设或 patch 没命中根因时强制停手出 audit。Use when 同一 bug 已经试过 ≥2 次修复、症状仍在或换了形态再现、即将动「第 3 刀」时；触发关键词：「还是有这个问题」「又出现了」「同样的报错」「再试一次」「这次应该」。不适用于一次就 reproduce + 一次修好的场景。
存档目录，非可用 skill。
何时调 AskUserQuestion 工具（出 Slack Block Kit 选择卡）vs 何时直接做 / 文字反问。Use when 用户指令含「帮我看下 / 可以吗 / 你看着办 / 哪个 / 选 / 用 X 还是 Y」等歧义表达；或动作不可逆（push/删/对外发）且有多个等价方案；或同一指令有 ≥2 种合理解读且代价差异大。Skip when 自己能 grep/读文件查到、常规决策、thread 近 5 条已有就近答、cron worker。
改动开工前强制评估爆炸半径，避免「修一漏二 / 头疼医头」。Use when 改动涉及：删除文件/符号、重命名、路径迁移、接口签名变更、状态机修改、短路逻辑修正、配置 key 改名，或用户原话含「改 X / 删 X / 重命名 / 迁移 / 重构 X / 修这个 bug」+ 该 X 在多处被引用。不适用于纯新增、孤立 bugfix（无外部依赖）、文档/注释改动。
| name | claim-vs-reality-margin |
| description | 声明≠现实——任何「X 已配置 / 已声明 / 已建立」必须配 margin 量化 + detection 机制，否则把声明当现实。Use when 设计依赖外部能力的方案（vendor partnership / TTL refresh / cron schedule / health check / 配额申请 / SLA 承诺）；或评审「我们已经 X」「客户说会 X」「config 配好了」类陈述；或排查「明明配了为什么没生效」类问题。 |
| provenance | user-authored |
「声明 X = 实现 X」是默认错觉。
每次说「X 已 OK」都必须强制问两件事：
没有这两个 → 声明只是声明，不是现实。
| 声明 | margin 应在哪 | detection 应在哪 | Source fact |
|---|---|---|---|
| Vendor partnership ≠ infra capability | capability gap 表（partnership 提供什么 vs 实际所需） | 集成阶段先做 capability matrix POC 验证，不是上线后才发现缺 | fact_50 |
| Refresh interval ≈ TTL ≠ 永远不过期 | interval ≤ TTL / 2（至少留一次重试余量） | refresh 失败 alert + token 过期前 X 分钟主动探活 | fact_39 |
| Cron 已配置 ≠ 在跑 | last-run 时间戳监控 + 漏跑阈值 | 主动 health check（不是等用户发现没收到报告） | fact_52 |
对每个「我们已经 X / 已配 X / X 会发生」的陈述：
1. X 失败的具体形态是什么？（timeout / quota exceeded / token expired / cron skipped）
2. 失败到被察觉之间有多久？（margin）
3. 谁第一个看到失败？（detection 主体）
4. 1-3 任一答不上来 → 这条声明不能落地
truth-ladder → margin / detection 是 attempted → observed → confirmed 三级跳的具体保障；本 skill 是「为什么需要三级」，truth-ladder 是「怎么写三级」vendor-api-param-validation → vendor 边界悲观验证是本 skill 在 API 集成场景的特化vendor-doc-actionability → 对外文档里每个动作要配 margin 也要配 detection（谁触发 / 谁验收）execution-discipline § 边界处悲观 / 副作用留据 → 本 skill 是「悲观」的可操作化没有 margin + detection 的声明，等于赌博。