[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7EHTQGA1HTT2B1CPFV19ACX":3,"skill-same:01M7EHTQGA1HTT2B1CPFV19ACX":43},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":14,"categories":15,"keywords":16,"publishedAt":17,"linkOnly":18,"markdownContent":19,"markdownBody":20,"frontMatter":21,"refName":22,"commitSha":23,"skillDirectory":24,"forksCount":25,"repositoryHtmlUrl":26,"repositoryHomepageUrl":6,"ownerHtmlUrl":27,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":28,"install":29,"resources":42},"01M7EHTQGA1HTT2B1CPFV19ACX","cache-hit-debug",null,"deyi2026\u002Fllm-first-loop","deyi2026","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F267286635?v=4","01M7EHT3KGDPR2R5HCCRQA3HYM","01M7EHT3M140G7BHY5CBAJVRH4",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fdeyi2026\u002Fllm-first-loop\u002Fblob\u002Fmain\u002Fskills\u002Fcache-hit-debug\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: cache-hit-debug\ndescription: LLM 前缀缓存命中排查技能——缓存命中率异常低（~1%）、怀疑缓存不生效、或想优化 prompt 成本时使用。核心方法：三实验法（缓存类型区分\u002FTTL 排除\u002F预算链定位）+ request.meta 真相源验证。目标：系统性定位根因而非猜测（实测从误判到根因 5 步内）。常用工具: architecture_status\u002Fexecute_command\u002Fsearch_records\u002Fsearch_archive。\n---\n# LLM 前缀缓存命中排查（cache-hit-debug）\n\n用户\u002F自检发现缓存命中率异常低（面板 cache_hit_rate ~1% 级别）或想降低 prompt 成本时，按以下流程系统排查。**核心：先实验验证机制，再查配置链，最后改+重启验证。**\n\n## 为什么需要这个 skill（血泪教训）\n\n**反模式**（实测踩坑）：\n1. ❌ 凭先验下结论：\"这 provider 没有缓存\"——短实验（131 token）不命中就误判无前缀缓存，实际是短 prompt 阈值效应\n2. ❌ 只查 .env 单层配置——预算有多层 min 链（全局\u002Fprovider\u002F模型窗口），真实压制点在 provider 级\n3. ❌ 以为 .env LLM_MODEL 就是实际运行模型——session model_override 会覆盖（配额降级残留）\n4. ❌ refresh_config 后以为预算已生效——provider 级 history_budget_chars 热重载不作用于运行中引擎，必须重启\n5. ❌ 忽略时间戳时区——event_logs 是 UTC，本地是 CST(+8)，统计先对齐\n\n## 标准流程（5 步）\n\n### Step 1: 缓存类型区分实验（先验证机制）\n\n用**长 prompt（>3000 token，建议 20+ 条消息）**发 3 个请求：\n- A. warm（初始序列）→ 期望 0 命中\n- B. 完全同 payload 重发 → 验证**精确缓存**\n- C. 前缀 + 追加 1 条 → 验证**前缀缓存**（关键！追加命中率应 ~97%）\n\n```python\n# 非流式 + usage 完整字段（流式需 stream_options.include_usage）\nr = httpx.post(url, json={\"model\": model, \"messages\": msgs}, timeout=120)\nu = r.json().get(\"usage\", {})\nprint(u.get(\"cached_tokens\"), u.get(\"prompt_tokens\"))\n```\n\n**判定**：B 全命中 = 精确缓存存在；C 命中（仅新增部分未命中）= **前缀缓存存在**——追加不破坏命中，**修改已提交序列（压缩\u002F重排）必断点**。\n\n### Step 2: TTL 排除实验（排除次要因素）\n\n同 payload 间隔 30s\u002F60s\u002F120s\u002F180s\u002F300s 重发，看 cached_tokens：\n- 全部命中 → TTL ≥ 5 分钟，排除 TTL 因素（会话内调用间隔通常 \u003C60s）\n- 超时后 miss → TTL 是因素，需控制调用节奏\n\n### Step 3: 预算链定位（查真实生效值）\n\n```\neffective_budget = min(\n  显式 runtime\u002Fhistory override（如有）,\n  显式全局 HISTORY_MAX_CHARS（如有）,\n  provider 级 history_budget_chars（如有）,\n  当前实际路由模型的物理输入预算（context - output reserve + safety margin）\n)\n```\n\n`HISTORY_MAX_CHARS` 未配置时**没有一层隐式 100K\u002F200K cap**；不要为了“补齐三层”主动加它。\n\n**真相源是 event_logs 的 request.meta**（每轮含 model\u002Fbudget\u002Fhistory_chars\u002Freasoning_chars\u002Fprovider_visible_chars），不是 .env：\n```python\n# 查每轮真实 budget\nreqs = [(json.loads(l)['ts'], json.loads(l)['payload']) for l in open(log) if 'request.meta' in l]\nfor ts, p in reqs[-5:]:\n    print(ts[11:19], p.get('model'), p.get('budget'),\n          p.get('history_chars'), p.get('reasoning_chars'), p.get('provider_visible_chars'))\n```\n\n**注意**：request.meta 里 model 字段才是实际运行模型（可能被 session model_override 覆盖）；budget 才是真正生效预算（min 链结果）。先查 model 再查对应 provider 的预算配置。\n\n**三字符字段含义（务必一起看，别只看 history_chars）**：`history_chars` = 本轮提交的 message content 字符数（**不含 reasoning_content**）；`reasoning_chars` = 本轮重新提交的历史 reasoning_content 字符数；`provider_visible_chars` = 更接近实际 provider 输入的可见结构规模（messages + tool schemas，不含传输头\u002F凭据）。**注意：`history_chars` 是遥测口径、不含 reasoning_content，单独看会低估实际输入规模**——本地实测过 history_chars≈50K、reasoning_chars≈41K 的场景：按 history_chars 看 budget 看似够，但真实提交体积还要加上 reasoning 历史重发。压缩器预算判定其实已含 reasoning_content（`history.py::_wire_size` 口径），所以问题出在\"遥测口径低估\"而非\"压缩器看不见 reasoning\"。**排查输入体积\u002F窗口压力时，以 `provider_visible_chars` 为主要观察量；排查前缀稳定性时，看 `request.usage` 的 `prefix_changed` \u002F `stable_prefix_fp` \u002F `prefix_change_reason` \u002F `cache_prefix_epoch`，并结合 `cache_hit_rate` \u002F `uncached_prompt_tokens`。`history_chars` 与 `reasoning_chars` 用于拆分输入来源。**\n\n### Step 4: 修复（只改被证据证明是压制点的那一层）\n\n1. `data\u002Fproviders.json`：仅本地慢模型\u002F已证实 endpoint 性能问题才设 `history_budget_chars`\n2. `.env`：`HISTORY_MAX_CHARS` 是可选 operator 全局 cap；无明确目的优先保持未配置\n3. `adjust_strategy history_budget`：运行时临时 override，只在当前任务确有需要时使用\n\n**历史量估算**：session 总字符 vs 实际 provider payload 不是一回事；以 `request.meta` \u002F `request.usage` 为准。字符↔token 只能估算，当前 generic 估算约 0.6 chars\u002Ftoken，不能拿它当 provider tokenizer 的精确事实。\n\n### Step 5: 重启 + 验证\n\n`bash scripts\u002Frestart_system.sh restart`（回 y 确认）→ 触发一次调用 → **request.meta budget 变为新值**才算生效（热重载对 provider 预算无效）。\n\n## 压缩友好策略（根因修复）\n\n命中率 = 稳定期占比（压缩轮必 miss 一次，物理必然）。优化方向：\n- **留缓冲**：压缩目标从\"裁到预算 100%\"改为\"预算×0.6-0.7\"（留 40% 增长空间 → 稳定期从几轮延长到几十轮）\n- **锚定**：system + 注入不参与压缩（前缀稳定锚）\n- **放大预算**：预算 > 会话历史总量 → 不压缩 → 纯追加（命中 ~97%）\n\n## 归因与恢复（2026-08-17 补充，EVO-20260817-5b991577）\n\n**先归因再告警**——低命中分两类，处置完全不同：\n- **破坏型**（窗口内锚点前移 >0）：前缀被压缩\u002F注入破坏 → 告警 + 拦截（强制保留锚点头部恢复稳定）\n- **设计型**（锚点未前移）：命中率 = 设计运行点（小窗口下前缀占比 ~9% → 命中率天然 6-8%，物理决定）→ **只观察不告警不拦截**\n\n**恢复条件用可达成信号**：拦截期锚点不再前移连续 N 轮即解除；加超时兜底（N 轮未恢复 → 恢复失败短消息 + 解除，每进程一次防刷屏）。**禁止用绝对命中率阈值做恢复判定**（如 ≥80%——设计型 8% 永远达不到 → 永久拦截空转死锁）。\n\n**注入漂移排查**（实测高发）：协调通道 inbox（data\u002Finterop\u002Flfl_to_dsh\u002Fpending\u002F）消息滞留 → 每轮注入 system 段 → 前缀每轮漂移 → 命中率持续低。检查：`ls data\u002Finterop\u002Flfl_to_dsh\u002Fpending\u002F | wc -l`，有堆积即按协议归档（notify 自动归档已上线，coordinate\u002Ftask 人工处理）。\n\n**命中率数字不是目标，成本才是——但必须用**实测价目**核算，勿凭直觉。**\"小窗口命中占比小但总成本低\"的直觉被实测推翻（2026-08-17 教训）：高 miss 占比下全价 miss 才是成本大头。**成本核算（真实 tokens 聚合 + 当前 provider 价目）按 cache-cost skill 执行，勿在本技能内重复维护价格\u002F成本案例。\n\n## 反模式清单\n\n- ❌ 短 prompt 实验（\u003C3000 token）下缓存结论\n- ❌ 只改 .env 不查 provider 级\u002F只改 provider 级不查实际运行 model\n- ❌ refresh 后不重启就宣称生效\n- ❌ 压缩轮被断点就断言\"缓存坏了\"——这是物理必然，看稳定期占比\n- ❌ 统计事件时忽略 UTC vs 本地时区\n- ❌ 用绝对命中率阈值做恢复判定（设计型低命中 → 死锁）\n- ❌ 不区分破坏型\u002F设计型就告警（设计型会误报 + 永久拦截空转）\n- ❌ 只查 .env 不查 interop pending 注入（注入漂移是高频根因）\n\n## 实测参考（2026-08-16 本环境）\n\n| 项 | 值 |\n|---|---|\n| 前缀追加命中率 | 97.3%（9472\u002F9735） |\n| 修复前命中率 | ~1%（每轮压缩） |\n| 修复后 | 99.2%（长 run 稳定期） |\n| TTL | ≥300s（实测 5 分钟全命中） |\n| 模型 | kimi\u002Fk3、deepseek-v4-flash（窗口均 1M token） |\n","# LLM 前缀缓存命中排查（cache-hit-debug）\n\n用户\u002F自检发现缓存命中率异常低（面板 cache_hit_rate ~1% 级别）或想降低 prompt 成本时，按以下流程系统排查。**核心：先实验验证机制，再查配置链，最后改+重启验证。**\n\n## 为什么需要这个 skill（血泪教训）\n\n**反模式**（实测踩坑）：\n1. ❌ 凭先验下结论：\"这 provider 没有缓存\"——短实验（131 token）不命中就误判无前缀缓存，实际是短 prompt 阈值效应\n2. ❌ 只查 .env 单层配置——预算有多层 min 链（全局\u002Fprovider\u002F模型窗口），真实压制点在 provider 级\n3. ❌ 以为 .env LLM_MODEL 就是实际运行模型——session model_override 会覆盖（配额降级残留）\n4. ❌ refresh_config 后以为预算已生效——provider 级 history_budget_chars 热重载不作用于运行中引擎，必须重启\n5. ❌ 忽略时间戳时区——event_logs 是 UTC，本地是 CST(+8)，统计先对齐\n\n## 标准流程（5 步）\n\n### Step 1: 缓存类型区分实验（先验证机制）\n\n用**长 prompt（>3000 token，建议 20+ 条消息）**发 3 个请求：\n- A. warm（初始序列）→ 期望 0 命中\n- B. 完全同 payload 重发 → 验证**精确缓存**\n- C. 前缀 + 追加 1 条 → 验证**前缀缓存**（关键！追加命中率应 ~97%）\n\n```python\n# 非流式 + usage 完整字段（流式需 stream_options.include_usage）\nr = httpx.post(url, json={\"model\": model, \"messages\": msgs}, timeout=120)\nu = r.json().get(\"usage\", {})\nprint(u.get(\"cached_tokens\"), u.get(\"prompt_tokens\"))\n```\n\n**判定**：B 全命中 = 精确缓存存在；C 命中（仅新增部分未命中）= **前缀缓存存在**——追加不破坏命中，**修改已提交序列（压缩\u002F重排）必断点**。\n\n### Step 2: TTL 排除实验（排除次要因素）\n\n同 payload 间隔 30s\u002F60s\u002F120s\u002F180s\u002F300s 重发，看 cached_tokens：\n- 全部命中 → TTL ≥ 5 分钟，排除 TTL 因素（会话内调用间隔通常 \u003C60s）\n- 超时后 miss → TTL 是因素，需控制调用节奏\n\n### Step 3: 预算链定位（查真实生效值）\n\n```\neffective_budget = min(\n  显式 runtime\u002Fhistory override（如有）,\n  显式全局 HISTORY_MAX_CHARS（如有）,\n  provider 级 history_budget_chars（如有）,\n  当前实际路由模型的物理输入预算（context - output reserve + safety margin）\n)\n```\n\n`HISTORY_MAX_CHARS` 未配置时**没有一层隐式 100K\u002F200K cap**；不要为了“补齐三层”主动加它。\n\n**真相源是 event_logs 的 request.meta**（每轮含 model\u002Fbudget\u002Fhistory_chars\u002Freasoning_chars\u002Fprovider_visible_chars），不是 .env：\n```python\n# 查每轮真实 budget\nreqs = [(json.loads(l)['ts'], json.loads(l)['payload']) for l in open(log) if 'request.meta' in l]\nfor ts, p in reqs[-5:]:\n    print(ts[11:19], p.get('model'), p.get('budget'),\n          p.get('history_chars'), p.get('reasoning_chars'), p.get('provider_visible_chars'))\n```\n\n**注意**：request.meta 里 model 字段才是实际运行模型（可能被 session model_override 覆盖）；budget 才是真正生效预算（min 链结果）。先查 model 再查对应 provider 的预算配置。\n\n**三字符字段含义（务必一起看，别只看 history_chars）**：`history_chars` = 本轮提交的 message content 字符数（**不含 reasoning_content**）；`reasoning_chars` = 本轮重新提交的历史 reasoning_content 字符数；`provider_visible_chars` = 更接近实际 provider 输入的可见结构规模（messages + tool schemas，不含传输头\u002F凭据）。**注意：`history_chars` 是遥测口径、不含 reasoning_content，单独看会低估实际输入规模**——本地实测过 history_chars≈50K、reasoning_chars≈41K 的场景：按 history_chars 看 budget 看似够，但真实提交体积还要加上 reasoning 历史重发。压缩器预算判定其实已含 reasoning_content（`history.py::_wire_size` 口径），所以问题出在\"遥测口径低估\"而非\"压缩器看不见 reasoning\"。**排查输入体积\u002F窗口压力时，以 `provider_visible_chars` 为主要观察量；排查前缀稳定性时，看 `request.usage` 的 `prefix_changed` \u002F `stable_prefix_fp` \u002F `prefix_change_reason` \u002F `cache_prefix_epoch`，并结合 `cache_hit_rate` \u002F `uncached_prompt_tokens`。`history_chars` 与 `reasoning_chars` 用于拆分输入来源。**\n\n### Step 4: 修复（只改被证据证明是压制点的那一层）\n\n1. `data\u002Fproviders.json`：仅本地慢模型\u002F已证实 endpoint 性能问题才设 `history_budget_chars`\n2. `.env`：`HISTORY_MAX_CHARS` 是可选 operator 全局 cap；无明确目的优先保持未配置\n3. `adjust_strategy history_budget`：运行时临时 override，只在当前任务确有需要时使用\n\n**历史量估算**：session 总字符 vs 实际 provider payload 不是一回事；以 `request.meta` \u002F `request.usage` 为准。字符↔token 只能估算，当前 generic 估算约 0.6 chars\u002Ftoken，不能拿它当 provider tokenizer 的精确事实。\n\n### Step 5: 重启 + 验证\n\n`bash scripts\u002Frestart_system.sh restart`（回 y 确认）→ 触发一次调用 → **request.meta budget 变为新值**才算生效（热重载对 provider 预算无效）。\n\n## 压缩友好策略（根因修复）\n\n命中率 = 稳定期占比（压缩轮必 miss 一次，物理必然）。优化方向：\n- **留缓冲**：压缩目标从\"裁到预算 100%\"改为\"预算×0.6-0.7\"（留 40% 增长空间 → 稳定期从几轮延长到几十轮）\n- **锚定**：system + 注入不参与压缩（前缀稳定锚）\n- **放大预算**：预算 > 会话历史总量 → 不压缩 → 纯追加（命中 ~97%）\n\n## 归因与恢复（2026-08-17 补充，EVO-20260817-5b991577）\n\n**先归因再告警**——低命中分两类，处置完全不同：\n- **破坏型**（窗口内锚点前移 >0）：前缀被压缩\u002F注入破坏 → 告警 + 拦截（强制保留锚点头部恢复稳定）\n- **设计型**（锚点未前移）：命中率 = 设计运行点（小窗口下前缀占比 ~9% → 命中率天然 6-8%，物理决定）→ **只观察不告警不拦截**\n\n**恢复条件用可达成信号**：拦截期锚点不再前移连续 N 轮即解除；加超时兜底（N 轮未恢复 → 恢复失败短消息 + 解除，每进程一次防刷屏）。**禁止用绝对命中率阈值做恢复判定**（如 ≥80%——设计型 8% 永远达不到 → 永久拦截空转死锁）。\n\n**注入漂移排查**（实测高发）：协调通道 inbox（data\u002Finterop\u002Flfl_to_dsh\u002Fpending\u002F）消息滞留 → 每轮注入 system 段 → 前缀每轮漂移 → 命中率持续低。检查：`ls data\u002Finterop\u002Flfl_to_dsh\u002Fpending\u002F | wc -l`，有堆积即按协议归档（notify 自动归档已上线，coordinate\u002Ftask 人工处理）。\n\n**命中率数字不是目标，成本才是——但必须用**实测价目**核算，勿凭直觉。**\"小窗口命中占比小但总成本低\"的直觉被实测推翻（2026-08-17 教训）：高 miss 占比下全价 miss 才是成本大头。**成本核算（真实 tokens 聚合 + 当前 provider 价目）按 cache-cost skill 执行，勿在本技能内重复维护价格\u002F成本案例。\n\n## 反模式清单\n\n- ❌ 短 prompt 实验（\u003C3000 token）下缓存结论\n- ❌ 只改 .env 不查 provider 级\u002F只改 provider 级不查实际运行 model\n- ❌ refresh 后不重启就宣称生效\n- ❌ 压缩轮被断点就断言\"缓存坏了\"——这是物理必然，看稳定期占比\n- ❌ 统计事件时忽略 UTC vs 本地时区\n- ❌ 用绝对命中率阈值做恢复判定（设计型低命中 → 死锁）\n- ❌ 不区分破坏型\u002F设计型就告警（设计型会误报 + 永久拦截空转）\n- ❌ 只查 .env 不查 interop pending 注入（注入漂移是高频根因）\n\n## 实测参考（2026-08-16 本环境）\n\n| 项 | 值 |\n|---|---|\n| 前缀追加命中率 | 97.3%（9472\u002F9735） |\n| 修复前命中率 | ~1%（每轮压缩） |\n| 修复后 | 99.2%（长 run 稳定期） |\n| TTL | ≥300s（实测 5 分钟全命中） |\n| 模型 | kimi\u002Fk3、deepseek-v4-flash（窗口均 1M token） |\n",{},"main","57f220f344f02e6abf6eb55434077d104c209804","skills\u002Fcache-hit-debug",0,"https:\u002F\u002Fgithub.com\u002Fdeyi2026\u002Fllm-first-loop","https:\u002F\u002Fgithub.com\u002Fdeyi2026","2026-11-15 10:23:32",{"source":7,"skillName":5,"commands":30,"prompt":40,"zipAvailable":41},[31,34,37],{"tool":32,"command":33},"npx","npx skills add deyi2026\u002Fllm-first-loop --skill cache-hit-debug",{"tool":35,"command":36},"bunx","bunx skills add deyi2026\u002Fllm-first-loop --skill cache-hit-debug",{"tool":38,"command":39},"pnpm","pnpm dlx skills add deyi2026\u002Fllm-first-loop --skill cache-hit-debug","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdeyi2026\u002Fllm-first-loop\u002Fblob\u002Fmain\u002Fskills\u002Fcache-hit-debug\u002FSKILL.md",true,[],[44,51,58,65,72,79],{"skillNo":45,"name":46,"nameZh":6,"description":47,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":48,"categories":49,"keywords":50,"publishedAt":17},"01M7EJ01AM5PZXYNM9GBF6CW12","security-audit","Audit project for security issues.","https:\u002F\u002Fgithub.com\u002Fdeyi2026\u002Fllm-first-loop\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fvendor_gemini_demo\u002Fskills\u002Fsecurity-audit\u002FSKILL.md",[],[],{"skillNo":52,"name":53,"nameZh":6,"description":54,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":17},"01M7EJ00CD2JXGVB0JETXGEX43","metrics","Collect project metrics.","https:\u002F\u002Fgithub.com\u002Fdeyi2026\u002Fllm-first-loop\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fvendor_codex_demo\u002Fskills\u002Fmetrics\u002FSKILL.md",[],[],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":17},"01M7EHZZD7DVVTSECGF5HHHQZ5","lint","Lint the repo using project config.","https:\u002F\u002Fgithub.com\u002Fdeyi2026\u002Fllm-first-loop\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fvendor_claude_demo\u002Fskills\u002Flint\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":17},"01M7EHZYGGYKDZDEHVF4YSD22X","report","值班报告生成","https:\u002F\u002Fgithub.com\u002Fdeyi2026\u002Fllm-first-loop\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fstd_plugin_demo\u002Fskills\u002Freport\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":17},"01M7EHZVX0V6ER3X3017K47RK4","deploy","标准部署流程（多行 YAML frontmatter 演示）","https:\u002F\u002Fgithub.com\u002Fdeyi2026\u002Fllm-first-loop\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fstd_plugin_demo\u002Fskills\u002Fdeploy\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":17},"01M7EHZRENGPKXXFBA3YJ1QF1S","web-self-restart-triage","https:\u002F\u002Fgithub.com\u002Fdeyi2026\u002Fllm-first-loop\u002Fblob\u002Fmain\u002Fskills\u002Fweb-self-restart-triage\u002FSKILL.md",[],[]]