[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FYW81TRN7VAS8WTN08STH":3,"skill-same:01M70FYW81TRN7VAS8WTN08STH":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M70FYW81TRN7VAS8WTN08STH","truth-ladder",null,"状态放行三层阶梯（attempted \u002F observed \u002F confirmed）—— 汇报任务、API、命令、消息或外部动作状态时强制分层，避免把\"动作已发起\"误写成\"结果已达成\"。Use when 准备写「任务已完成」「API 返回成功」「exit code 0」「用户已收到」「ok:true」类状态汇报；或在 cron 报告 \u002F Slack 回报 \u002F project status \u002F receipt 中表达完成度时。","KarryViber\u002FOrb","KarryViber","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F223777671?v=4","01M70FTGZ485AP97T3CJCYW1Z2","Karryz","01M70FTGZRWF3FEQBYZ3JWTSPR",66,"MIT","https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Ftruth-ladder\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"ladder","truth ladder","slack","status","code","api","cron","project status","use","ok","exit","project","true","报告","when","2026-11-10 10:12:30",false,"---\nname: truth-ladder\ndescription: 状态放行三层阶梯（attempted \u002F observed \u002F confirmed）—— 汇报任务、API、命令、消息或外部动作状态时强制分层，避免把\"动作已发起\"误写成\"结果已达成\"。Use when 准备写「任务已完成」「API 返回成功」「exit code 0」「用户已收到」「ok:true」类状态汇报；或在 cron 报告 \u002F Slack 回报 \u002F project status \u002F receipt 中表达完成度时。\n---\n\n# Truth Ladder — 状态放行阶梯\n\n## When to Use\n- 准备写「任务已完成」「API 返回成功」「exit code 0」「用户已收到」「ok:true」「已发出」「已通知」等状态结论\n- cron 报告、receipt、project status update、Slack 收尾消息\n- 多步外部动作（发消息 \u002F 写文件 \u002F 调 vendor API）执行后的回报\n\n## 三层状态\n\n| 层 | 含义 | 证据要求 |\n|----|------|---------|\n| **attempted** | 动作已发起 | exit code 0 \u002F 命令跑完 \u002F 函数返回 |\n| **observed** | 外部已观察到变化 | API `ok:true` 且拿到 ts\u002Fid \u002F 文件落盘 \u002F DB 行写入 |\n| **confirmed** | 最终目标方\u002F下游验收达成预期 | 人工确认 \u002F 下游系统验收 \u002F 用户回执 |\n\n## 规则\n\n1. **默认从 attempted 起步**——没有外部可观测证据就不上 observed\n2. **observed ≠ 终点**——系统回 success 不代表用户真收到、事情真成\n3. **confirmed 必须有第三方确认源**（人 \u002F 下游 \u002F 真实目标方）\n4. **写事实而非结论**——记录 `ok:true` \u002F id \u002F path \u002F timestamp，不直接写「已完成」\n5. **禁止跳级**——没 observed 证据不写 confirmed；没 attempted 事实不写任何成功状态\n6. **源端必须新鲜**——任何状态判断的「证据」必须来自当下读取（grep \u002F cat \u002F API call \u002F log tail），禁止凭 commit message、thread 记忆、上一轮自己说的话推断当前 src 或外部系统状态\n\n## 典型映射\n\n- 命令 exit 0 → **attempted**\n- Slack `chat.postMessage` 返回 `ok:true` + ts → **observed**\n- 用户在 thread 里 react \u002F 回复确认看到 → **confirmed**\n- cron 脚本跑完没报错 → **attempted**（不是「报告已送达」）\n- vendor API 200 OK → **observed**（不是「客户已知悉」）\n\n## Gotchas\n\n- ❌ 把「命令跑完了」写成「任务已完成」\n- ❌ 把「API 成功了」写成「用户已经收到」\n- ❌ 为了显得利索跳过中间状态\n- ❌ 摘要里只写结论不写支撑事实（id \u002F ts \u002F path）\n- ❌ Slack 投递后只看 ok:true 就报 confirmed——message_not_in_streaming_state 类降级失败也是 ok:true 后发生的\n- ❌ **凭 commit message 推断 src 现状**——commit 描述「修了 X」≠ 当前 src 真的修好了；动手前必须 grep 当前文件验证。反例：04\u002F29 funnel 5 笔重构方向全错的共同根因就是凭 thread 记忆 + commit log 推断 dedup 在哪一层做的\n- ❌ **凭 thread 记忆判断脚本是否跑过**——「我刚才发了命令」≠「命令真的执行成功」；必须 ps \u002F log tail \u002F 产物文件 stat 三选一验证。反例：04\u002F29 setsid 不存在导致脚本根本没跑，12 分钟后 Karry 探针才暴露\n- ❌ **凭 stdout 尾巴判断「都跑完了」**——log 末尾安静≠任务完成，可能是 hang \u002F 中断 \u002F 输出走 stderr。反例：04\u002F30 codex log 尾巴误判\n\n## 「好了吗」探针识别\n\n用户说「好了吗 \u002F 完成了吗 \u002F 好了吧 \u002F 跑完没」时，**默认假定自己上一轮的状态报告是 attempted 但被错说成 confirmed**——回复前必须重新跑一次源端验证（不是回看 thread 历史），把当前真实状态按三层重新分类。\n\n## 与其他纪律的关系\n\n- `execution-discipline` § 状态诚实 \u002F 副作用留据 → Truth Ladder 是落地写法\n- `debug-audit-on-second-miss` → 第 2 次 patch 不中走 audit 时，所有「已试假设 \u002F 已排除方向」的事实必须遵循本 skill 的源端新鲜原则\n- `operation-receipt` → receipt 内的状态字段直接遵循三层\n- `compliance-delivery-checklist` → 对外交付前 7 点审查含「事实」一项，本 skill 是事实分层标准\n\n## One-liner\n\n**attempted ≠ observed ≠ confirmed，三级不可跳；证据必须当下重读，禁止凭记忆。**\n","# Truth Ladder — 状态放行阶梯\n\n## When to Use\n- 准备写「任务已完成」「API 返回成功」「exit code 0」「用户已收到」「ok:true」「已发出」「已通知」等状态结论\n- cron 报告、receipt、project status update、Slack 收尾消息\n- 多步外部动作（发消息 \u002F 写文件 \u002F 调 vendor API）执行后的回报\n\n## 三层状态\n\n| 层 | 含义 | 证据要求 |\n|----|------|---------|\n| **attempted** | 动作已发起 | exit code 0 \u002F 命令跑完 \u002F 函数返回 |\n| **observed** | 外部已观察到变化 | API `ok:true` 且拿到 ts\u002Fid \u002F 文件落盘 \u002F DB 行写入 |\n| **confirmed** | 最终目标方\u002F下游验收达成预期 | 人工确认 \u002F 下游系统验收 \u002F 用户回执 |\n\n## 规则\n\n1. **默认从 attempted 起步**——没有外部可观测证据就不上 observed\n2. **observed ≠ 终点**——系统回 success 不代表用户真收到、事情真成\n3. **confirmed 必须有第三方确认源**（人 \u002F 下游 \u002F 真实目标方）\n4. **写事实而非结论**——记录 `ok:true` \u002F id \u002F path \u002F timestamp，不直接写「已完成」\n5. **禁止跳级**——没 observed 证据不写 confirmed；没 attempted 事实不写任何成功状态\n6. **源端必须新鲜**——任何状态判断的「证据」必须来自当下读取（grep \u002F cat \u002F API call \u002F log tail），禁止凭 commit message、thread 记忆、上一轮自己说的话推断当前 src 或外部系统状态\n\n## 典型映射\n\n- 命令 exit 0 → **attempted**\n- Slack `chat.postMessage` 返回 `ok:true` + ts → **observed**\n- 用户在 thread 里 react \u002F 回复确认看到 → **confirmed**\n- cron 脚本跑完没报错 → **attempted**（不是「报告已送达」）\n- vendor API 200 OK → **observed**（不是「客户已知悉」）\n\n## Gotchas\n\n- ❌ 把「命令跑完了」写成「任务已完成」\n- ❌ 把「API 成功了」写成「用户已经收到」\n- ❌ 为了显得利索跳过中间状态\n- ❌ 摘要里只写结论不写支撑事实（id \u002F ts \u002F path）\n- ❌ Slack 投递后只看 ok:true 就报 confirmed——message_not_in_streaming_state 类降级失败也是 ok:true 后发生的\n- ❌ **凭 commit message 推断 src 现状**——commit 描述「修了 X」≠ 当前 src 真的修好了；动手前必须 grep 当前文件验证。反例：04\u002F29 funnel 5 笔重构方向全错的共同根因就是凭 thread 记忆 + commit log 推断 dedup 在哪一层做的\n- ❌ **凭 thread 记忆判断脚本是否跑过**——「我刚才发了命令」≠「命令真的执行成功」；必须 ps \u002F log tail \u002F 产物文件 stat 三选一验证。反例：04\u002F29 setsid 不存在导致脚本根本没跑，12 分钟后 Karry 探针才暴露\n- ❌ **凭 stdout 尾巴判断「都跑完了」**——log 末尾安静≠任务完成，可能是 hang \u002F 中断 \u002F 输出走 stderr。反例：04\u002F30 codex log 尾巴误判\n\n## 「好了吗」探针识别\n\n用户说「好了吗 \u002F 完成了吗 \u002F 好了吧 \u002F 跑完没」时，**默认假定自己上一轮的状态报告是 attempted 但被错说成 confirmed**——回复前必须重新跑一次源端验证（不是回看 thread 历史），把当前真实状态按三层重新分类。\n\n## 与其他纪律的关系\n\n- `execution-discipline` § 状态诚实 \u002F 副作用留据 → Truth Ladder 是落地写法\n- `debug-audit-on-second-miss` → 第 2 次 patch 不中走 audit 时，所有「已试假设 \u002F 已排除方向」的事实必须遵循本 skill 的源端新鲜原则\n- `operation-receipt` → receipt 内的状态字段直接遵循三层\n- `compliance-delivery-checklist` → 对外交付前 7 点审查含「事实」一项，本 skill 是事实分层标准\n\n## One-liner\n\n**attempted ≠ observed ≠ confirmed，三级不可跳；证据必须当下重读，禁止凭记忆。**\n",{"name":5,"description":7},"main","cb33813b8990e4602b7c2d501659f77ebba5999f","profiles\u002F.claude\u002Fskills\u002Ftruth-ladder",8,"https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb","https:\u002F\u002Fgithub.com\u002FKarryViber","2026-05-14 18:44:03",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add KarryViber\u002FOrb --skill truth-ladder",{"tool":57,"command":58},"bunx","bunx skills add KarryViber\u002FOrb --skill truth-ladder",{"tool":60,"command":61},"pnpm","pnpm dlx skills add KarryViber\u002FOrb --skill truth-ladder","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Ftruth-ladder\u002FSKILL.md",true,[],[66,100,115,132,145,173],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":70,"licenseFileUrl":71,"sourceHtmlUrl":72,"categories":73,"keywords":82,"publishedAt":39},"01M70G0637CFCHAY3DYTMYS07K","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[74,79],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":80,"categoryName":81,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000009","前端开发",[83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99],"webapp testing","testing","webapp","for","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":39},"01M70FZXCJ5AHJ3JW2Q12F04TA","vendor-doc-actionability","对外合作文档（交付文档 \u002F POC 文档 \u002F Solution Doc \u002F 提案书）必须为每个「需对方执行」的动作写清具体操作入口（URL \u002F 工单系统 \u002F 脚本路径 \u002F 联系人 + 联系方式 \u002F 步骤编号）。Use when 给客户、vendor、合作方写交付文档、POC 文档、Solution Doc、提案书；或检视已有对外文档是否抽象到无法执行。","https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Fvendor-doc-actionability\u002FSKILL.md",[],[107,108,109,110,111,112,38,113,32,114],"vendor doc actionability","doc","vendor","文档","user","URL","提案","poc",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":125,"publishedAt":39},"01M70FZARY5P7VRJKVFATTCVX9","vendor-api-param-validation","第三方 API \u002F SDK 集成开工前，强制先列参数 checklist 并对照官方文档逐项验证（名称 \u002F 类型 \u002F 必填 \u002F 默认 \u002F 上限），通过后再编码——不是「写完再调通」。Use when 新接 vendor API\u002FSDK（Slack \u002F LongPort \u002F freee \u002F LLM API 等）、既有集成追加新 endpoint 或新字段、用户说「调通某接口」「接入 X」「集成 X」。","https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Fvendor-api-param-validation\u002FSKILL.md",[121,124],{"categoryNo":122,"categoryName":123,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[29,126,127,109,111,128,32,38,26,129,130,110,131],"vendor api param validation","validation","endpoint","sdk","llm api","checklist",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":39},"01M70FYTESF5WQYBVRX8BXYJQF","thread-object-realignment","长 thread 切题后的对象重定协议——thread 历史 ≥5 条且检测到切题信号时，回复前必做「用户最后显式问题对象 vs 待发回复对象」一致性校验，不一致则改写或反问。Use when Slack thread 历史 ≥5 条且当前用户消息出现切题信号（主题词突变、问句指向新实体、时间线跳跃、出现「另外」「话说」「回到 X」「换个话题」等切题语，或 ≥3 turn 后用户显式问题对象与最近 assistant 回复对象不同）。","https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Fthread-object-realignment\u002FSKILL.md",[],[139,140,141,26,142,32,143,38,144,111],"object","thread","thread object realignment","校验","assistant","slack thread",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":70,"licenseFileUrl":149,"sourceHtmlUrl":150,"categories":151,"keywords":155,"publishedAt":39},"01M70FYFC1Y2J16FJFEFQ5WYRE","theme-factory","Toolkit for styling artifacts with a theme. These artifacts can be slides, docs, reportings, HTML landing pages, etc. There are 10 pre-set themes with colors\u002Ffonts that you can apply to any artifact that has been creating, or can generate a new theme on-the-fly.","https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Ftheme-factory\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Ftheme-factory\u002FSKILL.md",[152],{"categoryNo":153,"categoryName":154,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000015","视觉设计",[156,157,158,159,160,161,91,162,163,94,164,165,166,167,168,169,86,170,171,172],"theme","theme factory","factory","you","artifacts","apply","can","fonts","artifact","generate","fly","styling","pages","landing","slides","SET","themes",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":39},"01M70FXZ7DTCA3VKYZD1VJ1GKG","terse-intent-classifier","短指令作用层判定协议——对 ≤15 字、含指代词或动词型短指令（改\u002F删\u002F切\u002F跑\u002F停\u002F加）或元问句（更优雅\u002F更好\u002F有没有办法）的输入，先判层再动手。Use when 用户消息 ≤15 字且含「这个\u002F那个\u002F上面\u002F刚才\u002F它」指代，或形如「改一下」「删掉它」「跑一下」「有没有更优雅的方法」「切回 X」这类省略了对象或意图的短输入。","https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Fterse-intent-classifier\u002FSKILL.md",[],[180,181,182,183,32,38],"intent","terse","classifier","terse intent classifier"]