[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7APHA888AX54SWS1E2ZB9MV":3,"skill-same:01M7APHA888AX54SWS1E2ZB9MV":53},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":31,"commitSha":32,"skillDirectory":33,"forksCount":14,"repositoryHtmlUrl":34,"repositoryHomepageUrl":6,"ownerHtmlUrl":35,"ownerBlogUrl":36,"ownerDescription":37,"updatedAt":38,"install":39,"resources":52},"01M7APHA888AX54SWS1E2ZB9MV","debugging",null,"系统化 bug 定位：根因调查 → 模式分析 → 假设验证 → 修复。 Use when: 遇到 bug、测试失败、unexpected behavior。 Not for: 新功能开发、重构、已知原因的简单修复。 Output: Bug report（5件套）+ 根因 + 修复（含回归测试）。","peps1666\u002FBuildCrew-AI","peps1666","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F128503359?v=4","01M7APD9BQ6NTJ79J9FTB6YZGT","junhao zhou","01M7APD9CD06Q6CCJ22FYVG2AK",0,"MIT","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdebugging\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: debugging\ntips_exempt: existing workspace-navigator execution guidance correction; no new capability or discovery moment\ndescription: >\n  系统化 bug 定位：根因调查 → 模式分析 → 假设验证 → 修复。\n  Use when: 遇到 bug、测试失败、unexpected behavior。\n  Not for: 新功能开发、重构、已知原因的简单修复。\n  Output: Bug report（5件套）+ 根因 + 修复（含回归测试）。\ntriggers:\n  - \"bug\"\n  - \"报错\"\n  - \"test failure\"\n  - \"unexpected behavior\"\n---\n\n# Debugging（系统性调试）\n\n随机尝试修复浪费时间，症状修复掩盖真正问题。\n\n**遇到 bug 先搜（F102 记忆系统）**：`search_evidence(\"{error关键词}\")` 看看历史上有没有类似的坑。\n\n**铁律：没有根因分析，不能提出修复方案。**\n\n## 核心知识\n\n### Runtime Preflight Gate（运行时异常硬门禁）\n\n**如果 bug 涉及 runtime 行为**（前端显示异常、API 返回错误、猫猫行为异常、stream 错误等），**在进入 Phase 1 之前**必须先完成三件套验证：\n\n**手动三件套**（按顺序执行，收集 7 个字段）：\n\n```bash\n# 1. 找到 API 监听进程（绑端口，不用 grep 猜）\nexport API_PORT=\"${API_SERVER_PORT:-3004}\"\nlsof -iTCP:\"$API_PORT\" -sTCP:LISTEN -P -n 2>\u002Fdev\u002Fnull | awk 'NR>1{print \"PORT=\"ENVIRON[\"API_PORT\"], \"PID=\"$2}'\n\n# 2. 进程启动时间\nps -p \u003CPID> -o lstart=\n\n# 3. Runtime worktree HEAD vs 目标 commit\ngit -C \u003Cruntime-worktree> log --oneline -1        # HEAD=\nTARGET_COMMIT=\u003C你预期的commit>\n# 判断进程是否在 commit 之后启动：比较 commit 时间 vs 进程启动时间\n\n# 4. 当前 PID 在最新日志中的行数\ngrep -c \"\u003CPID>\" \u003C最新日志文件路径>                  # LOG_EVIDENCE=\n```\n\n收集到的 7 个字段：\n\n```\nPORT=3004              ← 默认 API 端口（3003=前端），只取 LISTEN PID\nPID=53507              ← 精确到监听进程（排除浏览器等客户端连接）\nSTART_TIME=...         ← 进程启动时间\nHEAD=abc1234 ...       ← runtime worktree HEAD\nTARGET_COMMIT=f78c984  ← 你预期的 commit\nPROCESS_AFTER_TARGET=yes\u002Fno  ← 进程是否在 commit 之后启动\nLOG_EVIDENCE=...       ← 当前 PID 在最新日志中的行数\n```\n\n**这 7 行没拿到之前，唯一允许说的话是\"我还没查完\"。**\n\n以下断言**必须附带 preflight 输出**，否则禁止说出：\n- \"runtime 没更新\" \u002F \"代码没编译\" \u002F \"没重启\" \u002F \"还是旧代码\"\n\n**为什么这是硬门禁**：启动脚本会自动拉代码并编译。\"没更新\"本来就不太可能发生。在没有证据的情况下说\"没更新\" = 把自己的 bug 甩锅给operator。这不是懒，是推卸责任。\n\n> 来源：operator多次纠正（2026-04-05 定为 P0），Maine Coon协助定位根因 + 方案审查。\n\n### 4 阶段流水线\n\n每个阶段必须完成才能进入下一个。\n\n**Phase 1 — 根因调查**（提出任何修复前必须完成）\n\n1. **仔细读错误信息**：不要略过 stack trace，记录行号\u002F文件路径\u002F错误码\n2. **稳定复现**：能稳定触发吗？不能复现 → 收集更多数据，不要猜\n3. **检查最近变更**：git diff、新依赖、配置变更、环境差异\n4. **多组件系统：加诊断桩收集证据**\n   ```\n   对每个组件边界：记录进入的数据、记录输出的数据、验证状态传播\n   先跑一次收集\"哪里断了\"的证据，再分析，再深入那个组件\n   ```\n5. **数据流逆向追踪**：错误值从哪里来？谁传了这个错误值？一直往上追到源头，在源头修，不在症状处修（完整技术见 `root-cause-tracing.md`）\n\n**Phase 2 — 模式分析**\n\n- 在同一代码库找可以工作的类似代码\n- 对照参考实现**完整地读**（不要略读）\n- 逐项列出工作代码和问题代码的差异，不要假设\"这个不重要\"\n\n**Phase 3 — 假设验证**\n\n- 明确写下：\"我认为根因是 X，因为 Y\"\n- 做**最小可能的变更**验证假设（一次一个变量）\n- 通过了 → Phase 4；没过 → 提出新假设，不要在上面叠加更多修复\n\n**Phase 4 — 实现修复**\n\n1. **先写失败测试复现 bug**（参见 `tdd` skill）\n2. 实现针对根因的单一修复\n3. 验证测试通过、无回归\n4. 如果修复无效 → 回 Phase 1，带着新信息重新分析\n\n**⚠️ 3+ 次修复都失败 = 架构问题**\n\n出现以下模式就停下来质疑架构，不要尝试第 4 次修复：\n- 每次修复都在不同地方暴露新的耦合\u002F共享状态\n- 修复需要\"大规模重构\"才能落地\n- 每次修复都在别处制造新症状\n\n停下来和operator讨论是继续修还是重新设计。\n\n### Bug Report 五件套（存档格式）\n\n存放位置：`docs\u002Fbug-report\u002F\u003Cbug-name>\u002Fbug-report.md`\n\n1. **报告人**：谁发现的、怎么发现的\n2. **复现步骤**：期望行为 vs 实际行为\n3. **根因分析**：查了什么、排除了什么、定位过程\n4. **修复方案**：选这个方案的理由、放弃了什么备选\n5. **验证方式**：怎么确认修好了\n\n**五件套是调查完成后的存档格式，不是入口。** 入口是诊断胶囊（见下方「Bug 诊断胶囊」节）。\n\n## 流程\n\n```\n收到 bug \u002F 看到失败\n  ↓\n涉及 runtime？→ 是 → Runtime Preflight Gate（三件套）\n  ↓ 否 \u002F 三件套完成\n填诊断胶囊（8 栏工作模板）← 入口！\n  ↓\nPhase 1: 根因调查（胶囊驱动）\n  ↓ 找到根因？\nPhase 2: 模式分析（对照工作代码）\n  ↓\nPhase 3: 假设验证（最小变更，一次一个）\n  ↓ 假设确认？\nPhase 4: 先写失败测试 → 修复 → 验证\n  ↓ 修复 3 次仍未解决？\n停下来 → 质疑架构 → 找operator讨论\n  ↓ 修复完成\n整理五件套存档（从胶囊提炼）\n```\n\n## Quick Reference\n\n| 阶段 | 关键动作 | 完成标准 |\n|------|----------|----------|\n| 1. 根因调查 | 读错误、复现、加诊断桩、追数据流 | 清楚知道是什么、为什么 |\n| 2. 模式分析 | 找工作代码、完整对照 | 找出差异列表 |\n| 3. 假设验证 | 写下假设、最小变更测试 | 假设确认或新假设 |\n| 4. 实现修复 | 先写失败测试、单一修复、验证 | bug 已解决，测试通过 |\n\n### 立即停止的 Red Flags\n\n听到自己说以下任何一句 → 停下来，回到 Phase 1：\n\n- \"先试试改 X 看看效果\"\n- \"大概是 X，我改一下\"\n- \"不太理解但这个或许能用\"\n- \"跳过测试，我手工验一下\"\n- \"同时改几个地方\"\n- \"再试一次修复\"（已经失败 2 次以上）\n- **\"可能没更新\u002F没编译\u002F没重启\"**（没跑三件套就说 = 推卸责任）\n\n## Common Mistakes\n\n| 错误 | 正确做法 |\n|------|----------|\n| 没有诊断胶囊就直接修 | 先填 8 栏诊断胶囊，再进 Phase 1 |\n| 看到症状就提修复方案 | Phase 1 根因调查必须完成才能提方案 |\n| 多组件系统直接猜原因 | 加诊断桩，收集每层边界的证据 |\n| 修完直接 push，不写测试 | 先写失败测试复现 bug，再修，再验证 |\n| 第 3 次修复还在叠加 | 停下来，质疑架构，找operator |\n| 错误信息略读 | 完整读 stack trace，记录行号和错误码 |\n\n## 和其他 skill 的区别\n\n- **vs `tdd`**：debugging 是**修复性**的（bug 出现后）；TDD 是**预防性**的（写代码前）。交叉点：Phase 4 写失败测试时切换到 TDD 模式\n- **vs `quality-gate`**：debugging 是找到并修复问题；quality-gate 是提交前确认一切正常\n\n## Bug 诊断胶囊\n\nPhase 1 开始时，用 **8 栏诊断胶囊** 结构化调查过程：\n\n> 模板 → [refs\u002Fbug-diagnosis-capsule.md](..\u002Frefs\u002Fbug-diagnosis-capsule.md)\n\n胶囊 8 栏：现象 \u002F 证据 \u002F 问题假设或根因 \u002F 诊断策略 \u002F 超时策略 \u002F 预警策略 \u002F 用户可见交互修正（可选） \u002F 验收\n\n**胶囊是调查过程的工作模板，五件套是 bug report 的存档格式。** 两者互补：先填胶囊驱动调查，再整理五件套存档。\n\n## 补充参考文件\n\n以下参考材料已随 skill 合并归档（原 `systematic-debugging\u002F` 目录），可从 git 历史查阅：\n\n- **`root-cause-tracing.md`** — 从 call stack 深处向上追踪原始触发点的完整技术\n- **`defense-in-depth.md`** — 找到根因后，在多层添加防御性校验\n- **`condition-based-waiting.md`** — 用条件轮询替代任意 timeout\n\n## 运行日志快速查看（F130）\n\n右侧状态面板底部有「运行日志 → 查看日志」按钮：\n- 点击后自动切换到 Workspace 面板，展开到 `packages\u002Fapi\u002Fdata\u002Flogs\u002Fapi\u002F` 并打开最新日志文件\n- 日志格式：Pino JSON（每行一条），文件名 `api.YYYY-MM-DD.SEQ.log`（日轮转，14天保留）\n- 也可以加载 `workspace-navigator`，调用 typed\n  `cat_cafe_workspace_navigate({ path: \"\u003C已确认的绝对日志目录>\", action: \"reveal\", threadId: \"\u003C当前 threadId>\" })`\n- 不要手写匿名 `POST \u002Fapi\u002Fworkspace\u002Fnavigate`：该安全边界要求 session、direct-loopback\n  identity 或已验证的 callback-token \u002F agent-key；第一方 MCP 会携带正确认证\n- 调试时**先看日志**再分析，不要猜\n\n## 下一步\n\n修复完成并通过验证后 → 加载 `quality-gate` 做提交前验收\n","# Debugging（系统性调试）\n\n随机尝试修复浪费时间，症状修复掩盖真正问题。\n\n**遇到 bug 先搜（F102 记忆系统）**：`search_evidence(\"{error关键词}\")` 看看历史上有没有类似的坑。\n\n**铁律：没有根因分析，不能提出修复方案。**\n\n## 核心知识\n\n### Runtime Preflight Gate（运行时异常硬门禁）\n\n**如果 bug 涉及 runtime 行为**（前端显示异常、API 返回错误、猫猫行为异常、stream 错误等），**在进入 Phase 1 之前**必须先完成三件套验证：\n\n**手动三件套**（按顺序执行，收集 7 个字段）：\n\n```bash\n# 1. 找到 API 监听进程（绑端口，不用 grep 猜）\nexport API_PORT=\"${API_SERVER_PORT:-3004}\"\nlsof -iTCP:\"$API_PORT\" -sTCP:LISTEN -P -n 2>\u002Fdev\u002Fnull | awk 'NR>1{print \"PORT=\"ENVIRON[\"API_PORT\"], \"PID=\"$2}'\n\n# 2. 进程启动时间\nps -p \u003CPID> -o lstart=\n\n# 3. Runtime worktree HEAD vs 目标 commit\ngit -C \u003Cruntime-worktree> log --oneline -1        # HEAD=\nTARGET_COMMIT=\u003C你预期的commit>\n# 判断进程是否在 commit 之后启动：比较 commit 时间 vs 进程启动时间\n\n# 4. 当前 PID 在最新日志中的行数\ngrep -c \"\u003CPID>\" \u003C最新日志文件路径>                  # LOG_EVIDENCE=\n```\n\n收集到的 7 个字段：\n\n```\nPORT=3004              ← 默认 API 端口（3003=前端），只取 LISTEN PID\nPID=53507              ← 精确到监听进程（排除浏览器等客户端连接）\nSTART_TIME=...         ← 进程启动时间\nHEAD=abc1234 ...       ← runtime worktree HEAD\nTARGET_COMMIT=f78c984  ← 你预期的 commit\nPROCESS_AFTER_TARGET=yes\u002Fno  ← 进程是否在 commit 之后启动\nLOG_EVIDENCE=...       ← 当前 PID 在最新日志中的行数\n```\n\n**这 7 行没拿到之前，唯一允许说的话是\"我还没查完\"。**\n\n以下断言**必须附带 preflight 输出**，否则禁止说出：\n- \"runtime 没更新\" \u002F \"代码没编译\" \u002F \"没重启\" \u002F \"还是旧代码\"\n\n**为什么这是硬门禁**：启动脚本会自动拉代码并编译。\"没更新\"本来就不太可能发生。在没有证据的情况下说\"没更新\" = 把自己的 bug 甩锅给operator。这不是懒，是推卸责任。\n\n> 来源：operator多次纠正（2026-04-05 定为 P0），Maine Coon协助定位根因 + 方案审查。\n\n### 4 阶段流水线\n\n每个阶段必须完成才能进入下一个。\n\n**Phase 1 — 根因调查**（提出任何修复前必须完成）\n\n1. **仔细读错误信息**：不要略过 stack trace，记录行号\u002F文件路径\u002F错误码\n2. **稳定复现**：能稳定触发吗？不能复现 → 收集更多数据，不要猜\n3. **检查最近变更**：git diff、新依赖、配置变更、环境差异\n4. **多组件系统：加诊断桩收集证据**\n   ```\n   对每个组件边界：记录进入的数据、记录输出的数据、验证状态传播\n   先跑一次收集\"哪里断了\"的证据，再分析，再深入那个组件\n   ```\n5. **数据流逆向追踪**：错误值从哪里来？谁传了这个错误值？一直往上追到源头，在源头修，不在症状处修（完整技术见 `root-cause-tracing.md`）\n\n**Phase 2 — 模式分析**\n\n- 在同一代码库找可以工作的类似代码\n- 对照参考实现**完整地读**（不要略读）\n- 逐项列出工作代码和问题代码的差异，不要假设\"这个不重要\"\n\n**Phase 3 — 假设验证**\n\n- 明确写下：\"我认为根因是 X，因为 Y\"\n- 做**最小可能的变更**验证假设（一次一个变量）\n- 通过了 → Phase 4；没过 → 提出新假设，不要在上面叠加更多修复\n\n**Phase 4 — 实现修复**\n\n1. **先写失败测试复现 bug**（参见 `tdd` skill）\n2. 实现针对根因的单一修复\n3. 验证测试通过、无回归\n4. 如果修复无效 → 回 Phase 1，带着新信息重新分析\n\n**⚠️ 3+ 次修复都失败 = 架构问题**\n\n出现以下模式就停下来质疑架构，不要尝试第 4 次修复：\n- 每次修复都在不同地方暴露新的耦合\u002F共享状态\n- 修复需要\"大规模重构\"才能落地\n- 每次修复都在别处制造新症状\n\n停下来和operator讨论是继续修还是重新设计。\n\n### Bug Report 五件套（存档格式）\n\n存放位置：`docs\u002Fbug-report\u002F\u003Cbug-name>\u002Fbug-report.md`\n\n1. **报告人**：谁发现的、怎么发现的\n2. **复现步骤**：期望行为 vs 实际行为\n3. **根因分析**：查了什么、排除了什么、定位过程\n4. **修复方案**：选这个方案的理由、放弃了什么备选\n5. **验证方式**：怎么确认修好了\n\n**五件套是调查完成后的存档格式，不是入口。** 入口是诊断胶囊（见下方「Bug 诊断胶囊」节）。\n\n## 流程\n\n```\n收到 bug \u002F 看到失败\n  ↓\n涉及 runtime？→ 是 → Runtime Preflight Gate（三件套）\n  ↓ 否 \u002F 三件套完成\n填诊断胶囊（8 栏工作模板）← 入口！\n  ↓\nPhase 1: 根因调查（胶囊驱动）\n  ↓ 找到根因？\nPhase 2: 模式分析（对照工作代码）\n  ↓\nPhase 3: 假设验证（最小变更，一次一个）\n  ↓ 假设确认？\nPhase 4: 先写失败测试 → 修复 → 验证\n  ↓ 修复 3 次仍未解决？\n停下来 → 质疑架构 → 找operator讨论\n  ↓ 修复完成\n整理五件套存档（从胶囊提炼）\n```\n\n## Quick Reference\n\n| 阶段 | 关键动作 | 完成标准 |\n|------|----------|----------|\n| 1. 根因调查 | 读错误、复现、加诊断桩、追数据流 | 清楚知道是什么、为什么 |\n| 2. 模式分析 | 找工作代码、完整对照 | 找出差异列表 |\n| 3. 假设验证 | 写下假设、最小变更测试 | 假设确认或新假设 |\n| 4. 实现修复 | 先写失败测试、单一修复、验证 | bug 已解决，测试通过 |\n\n### 立即停止的 Red Flags\n\n听到自己说以下任何一句 → 停下来，回到 Phase 1：\n\n- \"先试试改 X 看看效果\"\n- \"大概是 X，我改一下\"\n- \"不太理解但这个或许能用\"\n- \"跳过测试，我手工验一下\"\n- \"同时改几个地方\"\n- \"再试一次修复\"（已经失败 2 次以上）\n- **\"可能没更新\u002F没编译\u002F没重启\"**（没跑三件套就说 = 推卸责任）\n\n## Common Mistakes\n\n| 错误 | 正确做法 |\n|------|----------|\n| 没有诊断胶囊就直接修 | 先填 8 栏诊断胶囊，再进 Phase 1 |\n| 看到症状就提修复方案 | Phase 1 根因调查必须完成才能提方案 |\n| 多组件系统直接猜原因 | 加诊断桩，收集每层边界的证据 |\n| 修完直接 push，不写测试 | 先写失败测试复现 bug，再修，再验证 |\n| 第 3 次修复还在叠加 | 停下来，质疑架构，找operator |\n| 错误信息略读 | 完整读 stack trace，记录行号和错误码 |\n\n## 和其他 skill 的区别\n\n- **vs `tdd`**：debugging 是**修复性**的（bug 出现后）；TDD 是**预防性**的（写代码前）。交叉点：Phase 4 写失败测试时切换到 TDD 模式\n- **vs `quality-gate`**：debugging 是找到并修复问题；quality-gate 是提交前确认一切正常\n\n## Bug 诊断胶囊\n\nPhase 1 开始时，用 **8 栏诊断胶囊** 结构化调查过程：\n\n> 模板 → [refs\u002Fbug-diagnosis-capsule.md](..\u002Frefs\u002Fbug-diagnosis-capsule.md)\n\n胶囊 8 栏：现象 \u002F 证据 \u002F 问题假设或根因 \u002F 诊断策略 \u002F 超时策略 \u002F 预警策略 \u002F 用户可见交互修正（可选） \u002F 验收\n\n**胶囊是调查过程的工作模板，五件套是 bug report 的存档格式。** 两者互补：先填胶囊驱动调查，再整理五件套存档。\n\n## 补充参考文件\n\n以下参考材料已随 skill 合并归档（原 `systematic-debugging\u002F` 目录），可从 git 历史查阅：\n\n- **`root-cause-tracing.md`** — 从 call stack 深处向上追踪原始触发点的完整技术\n- **`defense-in-depth.md`** — 找到根因后，在多层添加防御性校验\n- **`condition-based-waiting.md`** — 用条件轮询替代任意 timeout\n\n## 运行日志快速查看（F130）\n\n右侧状态面板底部有「运行日志 → 查看日志」按钮：\n- 点击后自动切换到 Workspace 面板，展开到 `packages\u002Fapi\u002Fdata\u002Flogs\u002Fapi\u002F` 并打开最新日志文件\n- 日志格式：Pino JSON（每行一条），文件名 `api.YYYY-MM-DD.SEQ.log`（日轮转，14天保留）\n- 也可以加载 `workspace-navigator`，调用 typed\n  `cat_cafe_workspace_navigate({ path: \"\u003C已确认的绝对日志目录>\", action: \"reveal\", threadId: \"\u003C当前 threadId>\" })`\n- 不要手写匿名 `POST \u002Fapi\u002Fworkspace\u002Fnavigate`：该安全边界要求 session、direct-loopback\n  identity 或已验证的 callback-token \u002F agent-key；第一方 MCP 会携带正确认证\n- 调试时**先看日志**再分析，不要猜\n\n## 下一步\n\n修复完成并通过验证后 → 加载 `quality-gate` 做提交前验收\n",{"name":5,"triggers":24,"description":29,"tips_exempt":30},[25,26,27,28],"bug","报错","test failure","unexpected behavior","系统化 bug 定位：根因调查 → 模式分析 → 假设验证 → 修复。 Use when: 遇到 bug、测试失败、unexpected behavior。 Not for: 新功能开发、重构、已知原因的简单修复。 Output: Bug report（5件套）+ 根因 + 修复（含回归测试）。\n","existing workspace-navigator execution guidance correction; no new capability or discovery moment","main","e43f83d5ceb309323cae7e0f31e5e48fd816a57d",".claude\u002Fskills\u002Fdebugging","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI","https:\u002F\u002Fgithub.com\u002Fpeps1666","https:\u002F\u002Fwww.cug.edu.cn\u002F","My name is Zhou Junhao, and I am from China University of Geosciences (Wuhan). My major is Resources and Environment, and my research direction is Remote Sensin","2026-08-16 00:25:38",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add peps1666\u002FBuildCrew-AI --skill debugging",{"tool":45,"command":46},"bunx","bunx skills add peps1666\u002FBuildCrew-AI --skill debugging",{"tool":48,"command":49},"pnpm","pnpm dlx skills add peps1666\u002FBuildCrew-AI --skill debugging","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdebugging\u002FSKILL.md",true,[],[54,60,67,74,81,88],{"skillNo":55,"name":56,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M7APYYSHV2SSSRV5Q15JWWPF","plugin-reconcile-skill","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fplugins\u002Ftest-reconcile-plugin-regr\u002Fskills\u002Fplugin-reconcile-skill\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M7APYWAJ119TPF079F2AXWAS","weixin-mp","通过 Limb 体系操作微信公众号：发布文章、上传图片、管理草稿。 Use when: 需要发布内容到微信公众号、查看草稿、检查公众号连接状态。 Not for: 其他平台的发布、纯文本聊天、非公众号相关操作。 Output: 微信公众号操作结果（发布ID、草稿列表、图片URL等）。","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fpackages\u002Fapi\u002Fsrc\u002Fplugins\u002Fweixin-mp\u002Fskills\u002Fweixin-mp\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":19},"01M7APYNNEMBP2T62WT0JT7GNE","writing-skills","创建或修改 Clowder AI skill \u002F MCP tool description 的元技能（含质量标准、范本、发布）。 Use when: 写新 skill、修改现有 skill、写\u002F改 MCP tool description、验证 skill 质量； 或者功能实现中产出了 SKILL.md \u002F cat-cafe-skills\u002F 新目录 \u002F manifest.yaml skill 条目。 Not for: 使用 skill（直接触发对应 skill）。 Output: 新\u002F更新的 SKILL.md + manifest 条目 + symlinks。 GOTCHA: 软硬同重——skill\u002FMCP 质量 = 代码质量；不要写模型已知的通用教程，先过价值门禁。","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fcat-cafe-skills\u002Fwriting-skills\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M7APYHJDXRH9EDP5D3JZHSVN","writing-plans","将 spec\u002F需求拆分为可执行的分步实施计划。 Use when: 有 spec 或需求，准备动手前需要拆分步骤。 Not for: trivial 改动（≤5 行）、已有详细计划。 Output: 分步实施计划（含 TDD 步骤和检查点）。","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fcat-cafe-skills\u002Fwriting-plans\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M7APYD2SSZ6Y6CF5SD3YZ5C0","worktree","为代码、脚本、API 与第一方执行面创建隔离 Git worktree，并配置 Redis 6398；classifier 放行的 co-creation docs direct push 不进入本流程。","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fcat-cafe-skills\u002Fworktree\u002FSKILL.md",[],[],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":19},"01M7APY8R4E7RR2WZVPH9V8WWP","workspace-navigator","猫猫把“打开文档、代码或日志”等模糊意图解析成本地绝对路径或 worktree 相对路径，并返回 applied、queued、blocked 或 unconfirmed 的真实 Workspace 投递状态。","https:\u002F\u002Fgithub.com\u002Fpeps1666\u002FBuildCrew-AI\u002Fblob\u002Fmain\u002Fcat-cafe-skills\u002Fworkspace-navigator\u002FSKILL.md",[],[]]