[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FVE18TY18MFDM7CFNSYXX":3,"skill-same:01M70FVE18TY18MFDM7CFNSYXX":57},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":42,"install":43,"resources":56},"01M70FVE18TY18MFDM7CFNSYXX","execplan",null,"任务开工前用这个 skill 评估是否需要先写 spec。触发：涉及 ≥3 模块、>30 文件改动、>10 步骤、架构级决策、或用户说「先出方案 \u002F 先写 spec」。生成的 spec 放 workspace\u002Fspecs\u002F","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\u002Fexecplan\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29],"spec","生成","workspace","user","评估","文件","2026-11-10 10:12:30",false,"---\nname: execplan\ndescription: 任务开工前用这个 skill 评估是否需要先写 spec。触发：涉及 ≥3 模块、>30 文件改动、>10 步骤、架构级决策、或用户说「先出方案 \u002F 先写 spec」。生成的 spec 放 workspace\u002Fspecs\u002F\nprovenance: user-authored\n---\n\n复杂任务（>10 步骤、>30 文件、跨会话恢复、需要 Karry 审阅后 agent 独立推进）前写一份 ExecPlan，让**不知道任何上下文的新会话**也能接着干完。\n\n基于 OpenAI Codex Exec Plans + Yansu scenario-simulation 改造。\n\n## 双层触发（与 skill-factory 对称）\n\n### 即时层：任务开工前的 Gate\n\n每次 worker 收到任务，**开工前**先评估复杂度（不向用户输出评估过程，只在命中时开口）：\n\n**命中门槛（满足任一就必须提议）**：\n- 任务涉及 ≥ 3 个模块 \u002F 文件目录\n- 预估 > 30 个文件改动 或 > 10 个有序步骤\n- 架构级决策（新增存储 \u002F 改 IPC \u002F 增 cron \u002F 改 schema）\n- Karry 明说「先出方案」「先写 spec」「先想清楚」\n- 预估单次 worker 无法完成（需要跨会话推进）\n\n**命中时的提议格式**（任务回复的开头，而不是夹在中间）：\n```\n:clipboard: 这个任务建议先写 ExecPlan\n*理由*：{触发的具体门槛}\n*spec 路径*：`workspace\u002Fspecs\u002F{kebab-name}.md`\n*选项*：\n  - `写 spec` — 我先出 ExecPlan 供你审阅再开工\n  - `直接干` — 跳过 spec，立即执行\n  - `我来写` — 你自己写 spec\n```\n\n用户回复「直接干」或已显式给出简单指令 → 不再追问，正常执行。\n用户回复「写 spec」→ 按骨架写完 ExecPlan 并 commit，**等 Karry 在 `## 验收场景` 段对场景拍板后**再进实施 turn。\n\n### 被动层：现有 spec 的活文档维护\n\n进入 `workspace\u002Fspecs\u002F{name}.md` 相关任务时：\n- 每个停顿点必须更新 Progress（勾选 \u002F 拆分 \u002F 时间戳）\n- 发现意外 → Surprises & Discoveries 追加\n- 改方向 → Decision Log 追加\n- milestone 完成 → Outcomes & Retrospective 追加\n- 每次 commit 带对应 spec 引用（`spec(xxx): ...`）\n\n### 聚合层：spec 健康度按需巡检\n\n用户说「巡检一下 spec \u002F 看看 spec 状态」时执行：\n- 扫 `workspace\u002Fspecs\u002F*.md`，按 Progress 未勾选比例、最后更新时间排序\n- 发现 Progress 停滞 > 7 天且未标完结 → 报告\n- 发现 Outcomes 未填但最后 Progress 显示 100% → 提醒补 retrospective\n- 不自动修改 spec 文件，只做诊断\n\n**不设 cron**（2026-04-18 决定，遵循简洁原则）。\n\n## 核心铁律\n\n1. **自包含**：单个文件看完就能干活，不依赖「你之前说过」「见上一版」\n2. **活文档**：边做边改 Progress \u002F Decision Log，不是写完就扔\n3. **可验证结果**：每个 milestone 描述可观测的行为（跑什么命令、看到什么输出），不是「加了个 struct」\n4. **绝对路径 + 具体命令**：文件路径从 repo root 写全，命令写清 cwd\n5. **嵌入知识**：需要的背景直接写进来，不要「参见某博客」\n6. **场景先于代码**（2026-04-25 起）：spec 草稿必带 `## 验收场景` 段（≥3 条），Karry 拍板才进实施。借鉴 Yansu，挡前置理解错位\n\n## Orb 工作流约定\n\n- **位置**：`~\u002FOrb\u002Fprofiles\u002F\u003Cyour-profile>\u002Fworkspace\u002Fspecs\u002F{task-name}.md`\n- **命名**：kebab-case，见名知意（`dm-routing.md` \u002F `worker-zombie-cleanup.md`）\n- **提交时机**：ExecPlan 本身就是一个 commit，后续每个 milestone 完成也要 commit\n- **不要**在 ExecPlan 里再嵌套 ``` 代码块（用缩进块替代）；顶层也不必用 ``` 包裹整份文档\n- **必带「执行」段**：spec 末尾必须有 `## 执行` 段，注明总 turn 预算；大改拆「调研 turn ≤ X」+「实施 turn ≤ Y」两段\n- **必带「验收场景」段**（2026-04-25 起）：≥3 条 happy\u002Fedge\u002Ffail 场景，写完发 Slack 等 Karry 拍板后再开工\n\n## 骨架（必须包含这些段）\n\n```\n# {动作短语标题}\n\n## Purpose \u002F 大图景\n做完这个 Karry 能做什么之前做不了的？用户可见行为是什么？\n\n## Progress\n- [x] (2026-04-18 11:30 JST) 已完成项\n- [ ] 待办项\n\n## Surprises & Discoveries\n- 观察: ...\n  证据: {日志\u002F测试输出}\n\n## Decision Log\n- 决策: 用 A 不用 B\n  理由: ...\n  日期: 2026-04-18\n\n## Outcomes & Retrospective\n（收尾写）\n\n## Context \u002F 当前状态\n假设读者零上下文。关键文件写全路径，定义每个术语。\n\n## Plan of Work\n散文描述：改哪些文件（全路径）、加什么、为什么。\n\n## 验收场景  ← Karry 拍板 gate\n列 ≥3 条具体场景，每条写「输入 → 期望可观测行为」。覆盖至少：\n- **Happy path**：典型成功用例\n- **Edge case**：边界 \u002F 罕见输入 \u002F 并发 \u002F 部分失败\n- **Failure mode**：明确的失败行为（报错文案 \u002F 降级路径 \u002F 不该发生什么）\n\n写完发 Slack 等 Karry 确认。Karry 改场景 = spec 调整；Karry 点头 = 进实施。\n\n## Concrete Steps\n具体命令 + cwd + 预期输出片段。\n\n## Validation \u002F Acceptance\n跑什么、看到什么——对应「验收场景」每条要可执行验证。\n\n## Idempotence \u002F Recovery\n能不能重跑？失败如何回滚？\n\n## Interfaces \u002F Dependencies\n涉及的模块、函数签名、IPC 协议。写全限定路径。\n\n## 执行\n总预算 ≤ N turn；若是大改，拆「调研 turn ≤ X」+「实施 turn ≤ Y」两次 codex session。\n```\n\n## Milestone 原则\n\n每个 milestone 独立可验证、增量交付。写 milestone 时讲故事：**目标 → 工作 → 结果 → 证据**。\n\n## 什么时候更新 ExecPlan\n\n- 每个停顿点：更新 Progress（必要时拆分「已做 X \u002F 剩余 Y」）\n- 发现意外行为：写入 Surprises，附证据\n- 改变方向：写入 Decision Log，说明 why\n- Milestone 完成：写 Outcomes 片段\n- 大改完方向：文档底部加一条 revision note\n\n## 反模式\n\n- :x: 方案写一半，Progress 永远停留在 Day 1\n- :x: 步骤抽象到「合理处理 X」「按架构调整」——新会话看不懂\n- :x: 引用「上次那个 spec」但没 checked in\n- :x: 验收写成「代码通过 lint」而不是「用户可看到的行为」\n- :x: 每次停顿都不 commit，丢状态\n- :x: **跳过验收场景评审直接进实施**（场景先于代码是硬约束）\n- :x: 验收场景写成「能跑 \u002F work \u002F 不报错」——必须是具体可观测行为\n\n## 与 Orb 其他 skill 的分工\n\n| 工具 | 用途 | 触发层次 |\n|------|------|---------|\n| `execplan` (本文件) | 把**一次性复杂任务**拆成可独立执行的 spec | 即时 gate + 周扫 |\n| `skill-factory` | 把**重复工作流**沉淀为可复用 skill | 即时提议 + 周聚合 |\n| `state-assumptions-before-acting` | 开工前显式化假设 | 任务进入实施前 |\n| `commit-lineage` | commit message 锚定 spec\u002Flesson | 每次 commit |\n","复杂任务（>10 步骤、>30 文件、跨会话恢复、需要 Karry 审阅后 agent 独立推进）前写一份 ExecPlan，让**不知道任何上下文的新会话**也能接着干完。\n\n基于 OpenAI Codex Exec Plans + Yansu scenario-simulation 改造。\n\n## 双层触发（与 skill-factory 对称）\n\n### 即时层：任务开工前的 Gate\n\n每次 worker 收到任务，**开工前**先评估复杂度（不向用户输出评估过程，只在命中时开口）：\n\n**命中门槛（满足任一就必须提议）**：\n- 任务涉及 ≥ 3 个模块 \u002F 文件目录\n- 预估 > 30 个文件改动 或 > 10 个有序步骤\n- 架构级决策（新增存储 \u002F 改 IPC \u002F 增 cron \u002F 改 schema）\n- Karry 明说「先出方案」「先写 spec」「先想清楚」\n- 预估单次 worker 无法完成（需要跨会话推进）\n\n**命中时的提议格式**（任务回复的开头，而不是夹在中间）：\n```\n:clipboard: 这个任务建议先写 ExecPlan\n*理由*：{触发的具体门槛}\n*spec 路径*：`workspace\u002Fspecs\u002F{kebab-name}.md`\n*选项*：\n  - `写 spec` — 我先出 ExecPlan 供你审阅再开工\n  - `直接干` — 跳过 spec，立即执行\n  - `我来写` — 你自己写 spec\n```\n\n用户回复「直接干」或已显式给出简单指令 → 不再追问，正常执行。\n用户回复「写 spec」→ 按骨架写完 ExecPlan 并 commit，**等 Karry 在 `## 验收场景` 段对场景拍板后**再进实施 turn。\n\n### 被动层：现有 spec 的活文档维护\n\n进入 `workspace\u002Fspecs\u002F{name}.md` 相关任务时：\n- 每个停顿点必须更新 Progress（勾选 \u002F 拆分 \u002F 时间戳）\n- 发现意外 → Surprises & Discoveries 追加\n- 改方向 → Decision Log 追加\n- milestone 完成 → Outcomes & Retrospective 追加\n- 每次 commit 带对应 spec 引用（`spec(xxx): ...`）\n\n### 聚合层：spec 健康度按需巡检\n\n用户说「巡检一下 spec \u002F 看看 spec 状态」时执行：\n- 扫 `workspace\u002Fspecs\u002F*.md`，按 Progress 未勾选比例、最后更新时间排序\n- 发现 Progress 停滞 > 7 天且未标完结 → 报告\n- 发现 Outcomes 未填但最后 Progress 显示 100% → 提醒补 retrospective\n- 不自动修改 spec 文件，只做诊断\n\n**不设 cron**（2026-04-18 决定，遵循简洁原则）。\n\n## 核心铁律\n\n1. **自包含**：单个文件看完就能干活，不依赖「你之前说过」「见上一版」\n2. **活文档**：边做边改 Progress \u002F Decision Log，不是写完就扔\n3. **可验证结果**：每个 milestone 描述可观测的行为（跑什么命令、看到什么输出），不是「加了个 struct」\n4. **绝对路径 + 具体命令**：文件路径从 repo root 写全，命令写清 cwd\n5. **嵌入知识**：需要的背景直接写进来，不要「参见某博客」\n6. **场景先于代码**（2026-04-25 起）：spec 草稿必带 `## 验收场景` 段（≥3 条），Karry 拍板才进实施。借鉴 Yansu，挡前置理解错位\n\n## Orb 工作流约定\n\n- **位置**：`~\u002FOrb\u002Fprofiles\u002F\u003Cyour-profile>\u002Fworkspace\u002Fspecs\u002F{task-name}.md`\n- **命名**：kebab-case，见名知意（`dm-routing.md` \u002F `worker-zombie-cleanup.md`）\n- **提交时机**：ExecPlan 本身就是一个 commit，后续每个 milestone 完成也要 commit\n- **不要**在 ExecPlan 里再嵌套 ``` 代码块（用缩进块替代）；顶层也不必用 ``` 包裹整份文档\n- **必带「执行」段**：spec 末尾必须有 `## 执行` 段，注明总 turn 预算；大改拆「调研 turn ≤ X」+「实施 turn ≤ Y」两段\n- **必带「验收场景」段**（2026-04-25 起）：≥3 条 happy\u002Fedge\u002Ffail 场景，写完发 Slack 等 Karry 拍板后再开工\n\n## 骨架（必须包含这些段）\n\n```\n# {动作短语标题}\n\n## Purpose \u002F 大图景\n做完这个 Karry 能做什么之前做不了的？用户可见行为是什么？\n\n## Progress\n- [x] (2026-04-18 11:30 JST) 已完成项\n- [ ] 待办项\n\n## Surprises & Discoveries\n- 观察: ...\n  证据: {日志\u002F测试输出}\n\n## Decision Log\n- 决策: 用 A 不用 B\n  理由: ...\n  日期: 2026-04-18\n\n## Outcomes & Retrospective\n（收尾写）\n\n## Context \u002F 当前状态\n假设读者零上下文。关键文件写全路径，定义每个术语。\n\n## Plan of Work\n散文描述：改哪些文件（全路径）、加什么、为什么。\n\n## 验收场景  ← Karry 拍板 gate\n列 ≥3 条具体场景，每条写「输入 → 期望可观测行为」。覆盖至少：\n- **Happy path**：典型成功用例\n- **Edge case**：边界 \u002F 罕见输入 \u002F 并发 \u002F 部分失败\n- **Failure mode**：明确的失败行为（报错文案 \u002F 降级路径 \u002F 不该发生什么）\n\n写完发 Slack 等 Karry 确认。Karry 改场景 = spec 调整；Karry 点头 = 进实施。\n\n## Concrete Steps\n具体命令 + cwd + 预期输出片段。\n\n## Validation \u002F Acceptance\n跑什么、看到什么——对应「验收场景」每条要可执行验证。\n\n## Idempotence \u002F Recovery\n能不能重跑？失败如何回滚？\n\n## Interfaces \u002F Dependencies\n涉及的模块、函数签名、IPC 协议。写全限定路径。\n\n## 执行\n总预算 ≤ N turn；若是大改，拆「调研 turn ≤ X」+「实施 turn ≤ Y」两次 codex session。\n```\n\n## Milestone 原则\n\n每个 milestone 独立可验证、增量交付。写 milestone 时讲故事：**目标 → 工作 → 结果 → 证据**。\n\n## 什么时候更新 ExecPlan\n\n- 每个停顿点：更新 Progress（必要时拆分「已做 X \u002F 剩余 Y」）\n- 发现意外行为：写入 Surprises，附证据\n- 改变方向：写入 Decision Log，说明 why\n- Milestone 完成：写 Outcomes 片段\n- 大改完方向：文档底部加一条 revision note\n\n## 反模式\n\n- :x: 方案写一半，Progress 永远停留在 Day 1\n- :x: 步骤抽象到「合理处理 X」「按架构调整」——新会话看不懂\n- :x: 引用「上次那个 spec」但没 checked in\n- :x: 验收写成「代码通过 lint」而不是「用户可看到的行为」\n- :x: 每次停顿都不 commit，丢状态\n- :x: **跳过验收场景评审直接进实施**（场景先于代码是硬约束）\n- :x: 验收场景写成「能跑 \u002F work \u002F 不报错」——必须是具体可观测行为\n\n## 与 Orb 其他 skill 的分工\n\n| 工具 | 用途 | 触发层次 |\n|------|------|---------|\n| `execplan` (本文件) | 把**一次性复杂任务**拆成可独立执行的 spec | 即时 gate + 周扫 |\n| `skill-factory` | 把**重复工作流**沉淀为可复用 skill | 即时提议 + 周聚合 |\n| `state-assumptions-before-acting` | 开工前显式化假设 | 任务进入实施前 |\n| `commit-lineage` | commit message 锚定 spec\u002Flesson | 每次 commit |\n",{"name":5,"provenance":35,"description":7},"user-authored","main","cb33813b8990e4602b7c2d501659f77ebba5999f","profiles\u002F.claude\u002Fskills\u002Fexecplan",8,"https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb","https:\u002F\u002Fgithub.com\u002FKarryViber","2026-05-14 18:44:03",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add KarryViber\u002FOrb --skill execplan",{"tool":49,"command":50},"bunx","bunx skills add KarryViber\u002FOrb --skill execplan",{"tool":52,"command":53},"pnpm","pnpm dlx skills add KarryViber\u002FOrb --skill execplan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Fexecplan\u002FSKILL.md",true,[],[58,90,106,129,148,161],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":62,"licenseFileUrl":63,"sourceHtmlUrl":64,"categories":65,"keywords":72,"publishedAt":30},"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",[66,69],{"categoryNo":67,"categoryName":68,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":70,"categoryName":71,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89],"webapp","testing","webapp testing","playwright","screenshots","ui","behavior","web","for","with","browser","logs","toolkit","debugging","frontend","local","applications",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":30},"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",[],[97,98,99,100,101,102,103,104,105,27],"vendor","doc","vendor doc actionability","poc","文档","use","提案","when","URL",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":120,"publishedAt":30},"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",[112,115],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[121,122,97,123,124,125,126,101,127,102,104,27,128],"vendor api param validation","validation","api","slack","sdk","llm api","checklist","endpoint",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":136,"publishedAt":30},"01M70FYW81TRN7VAS8WTN08STH","truth-ladder","状态放行三层阶梯（attempted \u002F observed \u002F confirmed）—— 汇报任务、API、命令、消息或外部动作状态时强制分层，避免把\"动作已发起\"误写成\"结果已达成\"。Use when 准备写「任务已完成」「API 返回成功」「exit code 0」「用户已收到」「ok:true」类状态汇报；或在 cron 报告 \u002F Slack 回报 \u002F project status \u002F receipt 中表达完成度时。","https:\u002F\u002Fgithub.com\u002FKarryViber\u002FOrb\u002Fblob\u002Fmain\u002Fprofiles\u002F.claude\u002Fskills\u002Ftruth-ladder\u002FSKILL.md",[135],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},[137,138,139,123,140,104,102,141,142,143,144,145,146,124,147],"ladder","truth ladder","ok","code","exit","true","status","报告","cron","project","project status",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":30},"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",[],[155,156,157,124,158,27,159,104,160,102],"object","thread","thread object realignment","校验","slack thread","assistant",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":62,"licenseFileUrl":165,"sourceHtmlUrl":166,"categories":167,"keywords":171,"publishedAt":30},"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",[168],{"categoryNo":169,"categoryName":170,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[172,173,174,175,176,177,178,179,82,180,181,85,182,183,184,185,186,81,187,188],"theme factory","factory","theme","apply","styling","fly","generate","artifact","fonts","can","artifacts","you","themes","pages","landing","slides","SET"]