一键在 Manus 中运行任何 Skill

truth-ladder

星标64

分支8

更新时间2026年5月14日 10:43

状态放行三层阶梯（attempted / observed / confirmed）—— 汇报任务、API、命令、消息或外部动作状态时强制分层，避免把"动作已发起"误写成"结果已达成"。Use when 准备写「任务已完成」「API 返回成功」「exit code 0」「用户已收到」「ok:true」类状态汇报；或在 cron 报告 / Slack 回报 / project status / receipt 中表达完成度时。

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

KarryViber

KarryViber/Orb

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Truth Ladder — 状态放行阶梯

When to Use

准备写「任务已完成」「API 返回成功」「exit code 0」「用户已收到」「ok:true」「已发出」「已通知」等状态结论
cron 报告、receipt、project status update、Slack 收尾消息
多步外部动作（发消息 / 写文件 / 调 vendor API）执行后的回报

三层状态

层	含义	证据要求
attempted	动作已发起	exit code 0 / 命令跑完 / 函数返回
observed	外部已观察到变化	API `ok:true` 且拿到 ts/id / 文件落盘 / DB 行写入
confirmed	最终目标方/下游验收达成预期	人工确认 / 下游系统验收 / 用户回执

规则

默认从 attempted 起步——没有外部可观测证据就不上 observed
observed ≠ 终点——系统回 success 不代表用户真收到、事情真成
confirmed 必须有第三方确认源（人 / 下游 / 真实目标方）
写事实而非结论——记录 ok:true / id / path / timestamp，不直接写「已完成」
禁止跳级——没 observed 证据不写 confirmed；没 attempted 事实不写任何成功状态
源端必须新鲜——任何状态判断的「证据」必须来自当下读取（grep / cat / API call / log tail），禁止凭 commit message、thread 记忆、上一轮自己说的话推断当前 src 或外部系统状态

典型映射

命令 exit 0 → attempted
Slack chat.postMessage 返回 ok:true + ts → observed
用户在 thread 里 react / 回复确认看到 → confirmed
cron 脚本跑完没报错 → attempted（不是「报告已送达」）
vendor API 200 OK → observed（不是「客户已知悉」）

Gotchas

❌ 把「命令跑完了」写成「任务已完成」
❌ 把「API 成功了」写成「用户已经收到」
❌ 为了显得利索跳过中间状态
❌ 摘要里只写结论不写支撑事实（id / ts / path）
❌ Slack 投递后只看 ok:true 就报 confirmed——message_not_in_streaming_state 类降级失败也是 ok:true 后发生的
❌ 凭 commit message 推断 src 现状——commit 描述「修了 X」≠ 当前 src 真的修好了；动手前必须 grep 当前文件验证。反例：04/29 funnel 5 笔重构方向全错的共同根因就是凭 thread 记忆 + commit log 推断 dedup 在哪一层做的
❌ 凭 thread 记忆判断脚本是否跑过——「我刚才发了命令」≠「命令真的执行成功」；必须 ps / log tail / 产物文件 stat 三选一验证。反例：04/29 setsid 不存在导致脚本根本没跑，12 分钟后 Karry 探针才暴露
❌ 凭 stdout 尾巴判断「都跑完了」——log 末尾安静≠任务完成，可能是 hang / 中断 / 输出走 stderr。反例：04/30 codex log 尾巴误判

「好了吗」探针识别

用户说「好了吗 / 完成了吗 / 好了吧 / 跑完没」时，默认假定自己上一轮的状态报告是 attempted 但被错说成 confirmed——回复前必须重新跑一次源端验证（不是回看 thread 历史），把当前真实状态按三层重新分类。

与其他纪律的关系

execution-discipline § 状态诚实 / 副作用留据 → Truth Ladder 是落地写法
debug-audit-on-second-miss → 第 2 次 patch 不中走 audit 时，所有「已试假设 / 已排除方向」的事实必须遵循本 skill 的源端新鲜原则
operation-receipt → receipt 内的状态字段直接遵循三层
compliance-delivery-checklist → 对外交付前 7 点审查含「事实」一项，本 skill 是事实分层标准

One-liner

attempted ≠ observed ≠ confirmed，三级不可跳；证据必须当下重读，禁止凭记忆。

同仓库更多 Skills

同仓库

adopt-from-external-repo

KarryViber/Orb

调研开源 repo 看「可偷什么」时，用这个流程——克隆读全源、按 ROI 排清单、审视现有系统、偷抽象不偷代码、融入现有机制不做加法。Use when 用户发 GitHub 链接 + 问「可以偷师 / 借鉴什么」，或你提议要参考外部项目。

2026-05-1464

session-wrap-up

KarryViber/Orb

Session 收工标准 SOP——任何路径触发「收工」（reaction ✅ / 文字「收工 / wrap up / 闭包」/ cron 自动）都走同一动作链：自测 → commit（含受保护路径 override 规则）→ 清过程产物（临时 spec / debug 输出 / dry-run 文件 / 中间 patch）→ 报 commit hash + 清理清单。Use when 用户说「收工 / 闭包 / wrap up / OK 收工 / 结束这一段」，或 ✅ reaction 触发 inject 含「收工」字样。

2026-05-1464

debug-audit-on-second-miss

KarryViber/Orb

Bug 修复 / 排查场景，连续 2 次假设或 patch 没命中根因时强制停手出 audit。Use when 同一 bug 已经试过 ≥2 次修复、症状仍在或换了形态再现、即将动「第 3 刀」时；触发关键词：「还是有这个问题」「又出现了」「同样的报错」「再试一次」「这次应该」。不适用于一次就 reproduce + 一次修好的场景。

2026-05-1464

Truth Ladder — 状态放行阶梯

When to Use

准备写「任务已完成」「API 返回成功」「exit code 0」「用户已收到」「ok:true」「已发出」「已通知」等状态结论
cron 报告、receipt、project status update、Slack 收尾消息
多步外部动作（发消息 / 写文件 / 调 vendor API）执行后的回报

三层状态

层	含义	证据要求
attempted	动作已发起	exit code 0 / 命令跑完 / 函数返回
observed	外部已观察到变化	API `ok:true` 且拿到 ts/id / 文件落盘 / DB 行写入
confirmed	最终目标方/下游验收达成预期	人工确认 / 下游系统验收 / 用户回执

规则

默认从 attempted 起步——没有外部可观测证据就不上 observed
observed ≠ 终点——系统回 success 不代表用户真收到、事情真成
confirmed 必须有第三方确认源（人 / 下游 / 真实目标方）
写事实而非结论——记录 ok:true / id / path / timestamp，不直接写「已完成」
禁止跳级——没 observed 证据不写 confirmed；没 attempted 事实不写任何成功状态
源端必须新鲜——任何状态判断的「证据」必须来自当下读取（grep / cat / API call / log tail），禁止凭 commit message、thread 记忆、上一轮自己说的话推断当前 src 或外部系统状态

典型映射

命令 exit 0 → attempted
Slack chat.postMessage 返回 ok:true + ts → observed
用户在 thread 里 react / 回复确认看到 → confirmed
cron 脚本跑完没报错 → attempted（不是「报告已送达」）
vendor API 200 OK → observed（不是「客户已知悉」）

Gotchas

❌ 把「命令跑完了」写成「任务已完成」
❌ 把「API 成功了」写成「用户已经收到」
❌ 为了显得利索跳过中间状态
❌ 摘要里只写结论不写支撑事实（id / ts / path）
❌ Slack 投递后只看 ok:true 就报 confirmed——message_not_in_streaming_state 类降级失败也是 ok:true 后发生的
❌ 凭 commit message 推断 src 现状——commit 描述「修了 X」≠ 当前 src 真的修好了；动手前必须 grep 当前文件验证。反例：04/29 funnel 5 笔重构方向全错的共同根因就是凭 thread 记忆 + commit log 推断 dedup 在哪一层做的
❌ 凭 thread 记忆判断脚本是否跑过——「我刚才发了命令」≠「命令真的执行成功」；必须 ps / log tail / 产物文件 stat 三选一验证。反例：04/29 setsid 不存在导致脚本根本没跑，12 分钟后 Karry 探针才暴露
❌ 凭 stdout 尾巴判断「都跑完了」——log 末尾安静≠任务完成，可能是 hang / 中断 / 输出走 stderr。反例：04/30 codex log 尾巴误判

「好了吗」探针识别

与其他纪律的关系

execution-discipline § 状态诚实 / 副作用留据 → Truth Ladder 是落地写法
debug-audit-on-second-miss → 第 2 次 patch 不中走 audit 时，所有「已试假设 / 已排除方向」的事实必须遵循本 skill 的源端新鲜原则
operation-receipt → receipt 内的状态字段直接遵循三层
compliance-delivery-checklist → 对外交付前 7 点审查含「事实」一项，本 skill 是事实分层标准

One-liner

attempted ≠ observed ≠ confirmed，三级不可跳；证据必须当下重读，禁止凭记忆。