Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

Começar

record-bug-fix-memory

Estrelas4

Forks1

Atualizado2 de julho de 2026 às 05:14

当用户要求在 bug 已经定位并修复后，记录排错经验、事故结论、AI 记忆更新、复盘摘要或本地 MCP 记忆时使用。这个技能只负责沉淀 "发生了什么、为什么会发生、如何修好、以后要记住什么"，不要把它用于实际修复 bug。

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

ruan-cat

ruan-cat/monorepo

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	record-bug-fix-memory
description	当用户要求在 bug 已经定位并修复后，记录排错经验、事故结论、AI 记忆更新、复盘摘要或本地 MCP 记忆时使用。这个技能只负责沉淀 "发生了什么、为什么会发生、如何修好、以后要记住什么"，不要把它用于实际修复 bug。
template-version	2.0.0
metadata	{"author":"openspec","version":"1.0","generatedBy":"1.1.1"}

记录 Bug 修复记忆

1. 概述

使用这个技能，把已经完成的排错结果沉淀成可复用的长期记忆。

目标是保存根因、有效修复路径、错误假设和验证证据，让后续 agent 不再重复同样的弯路。

核心原则：记录决策链，不记录流水账。

2. 存储架构

本技能采用双层存储架构：

SKILL.md：只放流程指导 + 案例摘要索引（保持精简，不超过 150 行流程指导）
独立案例文件：每条详细事故记录写成独立的 YYYY-MM-DD-{slug}.md 文件，与 SKILL.md 同目录

禁止将完整事故记录正文内嵌到 SKILL.md 中。SKILL.md 中只保留摘要索引。

2.1. 目录结构

.agents/skills/fix-bug/record-bug-fix-memory/
├── SKILL.md                              # 流程指导 + 摘要索引
├── 2026-03-28-unocss-color-safelist.md   # 详细案例
├── 2026-03-29-nitro-dual-runtime.md      # 详细案例
└── ...                                   # 更多案例文件

2.2. 案例文件命名规范

格式：YYYY-MM-DD-{slug}.md
slug 使用小写英文 + 短横杠，简明描述事故主题
示例：2026-03-28-unocss-config-driven-color-safelist.md

2.3. 案例文件必填结构

# YYYY-MM-DD {事故简述}

## 1. 问题现象

{从用户视角看，哪里坏了}

## 2. 实际根因

{真正出错的地方}

## 3. 关键误导点

{哪个错误假设或误导信号浪费了时间}

## 4. 有效修复

{真正解决问题的改动}

## 5. 验证方式

{证明修复成功的证据}

## 6. 后续约束

{未来 agent 必须先检查什么、避免什么}

2.4. 摘要索引格式（写在 SKILL.md 的"案例索引"章节中）

### {事故简述}（YYYY-MM-DD）

- 详细案例：`YYYY-MM-DD-{slug}.md`
- 适用场景：{一句话描述触发条件}
- 关键约束：{一句话核心教训}

3. 何时使用

在以下场景使用这个技能：

用户要求更新 AI 记忆文档、记录经验教训、补充事故记录、编写复盘摘要。
bug 已经完成复现，且有效修复路径已经明确。
这条经验是仓库特有知识，应该对未来 agent 可见。
需要把结论同步到本地 MCP 记忆，例如 Memorix。

以下情况不要使用这个技能：

bug 还在调查中，根因没有确认。
用户要求的是修复实现，而不是经验沉淀。
你手里只有猜测、片段证据或临时绕过方案。

4. 前置输入

开始写记忆前，必须能回答下面六个问题：

对用户来说，表面现象是什么？
实际根因是什么？
哪个错误假设或误导信号浪费了时间？
最终是哪一个具体改动修好了问题？
用什么验证证明修复成立？
这条记忆应该写到哪里？

如果有任何一个问题答不上来，先完成排错，不要提前写记忆。

5. 写到哪里

详细案例：写到本技能目录下的独立 md 文件（默认落点）
摘要索引：同步更新 SKILL.md 的"案例索引"章节
跨会话的本地记忆：写到 Memorix，类型用 gotcha、decision 或 problem-solution
仓库级规则：只有当经验会影响整个仓库的未来 agent 时，才同步写入根级 CLAUDE.md、AGENTS.md、GEMINI.md

6. 记录流程

先确认 bug 已经理解清楚并且修复完成。
把结果压缩成 4 到 6 条高信号事实。
创建独立案例文件 YYYY-MM-DD-{slug}.md，按必填结构写入详细内容。
在 SKILL.md 的"案例索引"章节追加一条摘要索引。
如果经验影响整个仓库，同步更新根级 AI 记忆文档。
用同样的结论更新 Memorix，并选对记忆类型。
- 如果当前会话没有实际暴露 Memorix MCP 工具，就必须明确告诉用户"本会话无法写入 Memorix"，不能因为仓库文档声明"可用"就假定真的已经拿到工具。
回读一遍文本，删掉瞬时噪音、猜测和低价值命令历史。
如果用户还要求提交 commit，把提交动作交给单独的 git 工作流处理。

7. 写入经验时必须保留的额外信息

如果这次 bug 与仓库已有事故模式相似，写记忆时不要遗漏下面这些额外信息：

这次问题是否打破了某个"用户已确认稳定"的基线
是否存在"不要乱改"的配置
首个可信信号来自哪里，是终端日志、浏览器 console、网络请求，还是构建输出
这次修复属于哪一类：依赖实例统一、废弃 API 清理、导入路径修正、类型断言补齐、构建配置兜底、依赖入口兼容、模板层覆盖、样式层补齐、还是启动前置准备
这次是否存在误导性很强的假象
最终验证是否基于 fresh 进程、fresh 日志和 fresh 页面，而不是历史缓存

8. 验证证据写法

未来写事故记录时，优先记录可重复验证的证据，而不是模糊措辞。

好的写法：pnpm exec tsc --noEmit 输出中相关错误为 0
好的写法：fresh dev.stderr 为空
好的写法：修复文件均无类型错误输出
好的写法：pnpm install 后依赖版本一致，peer dependency 无冲突
不好的写法：应该没问题了
不好的写法：看起来像是好了

9. 不要写成什么

把根级 AI 记忆经验吸收到技能里，不等于把技能写成修复手册。下面这些内容不应该成为这个技能的主体：

大段命令执行流水
与当前仓库无关的泛化 debug 理论
逐条罗列所有试错过程
把某一次临时绕过方案包装成永久规则
用"必须执行这些命令"代替"应该记录哪些结论"

10. 好记忆的特征

解释清楚"为什么会坏"，而不是只写跑了什么命令
明确指出第一条可信线索，说明它如何打破错误假设
用可复用的方式描述最终修复
写出未来 agent 可以重复执行的验证动作
让下一次排错明显更短

11. 常见错误

根因还没确认，就开始写猜测性结论
写成很长的 debug 日记，而不是可复用结论
仓库级经验写到了错误的位置
没把导致绕路的错误假设写出来
把修复说明和记忆沉淀混在一起
忘了同步本地 MCP 记忆
只因为仓库记忆文件声明"有 Memorix"，就跳过当前会话工具可用性核对
把完整事故记录正文写进 SKILL.md 而不是独立案例文件

12. 边界

这个技能只负责记忆沉淀和总结。

它不能替代调试、实现、测试和修复工作流。如果 bug 还没修好，先使用合适的调试或实现技能，等结果稳定后再回到这个技能做经验沉淀。

13. 案例索引

此章节在初始化时为空。随着项目中实际的 bug 修复经验积累，按照第 2.4 节的格式逐步补充摘要索引。详细案例内容写入同目录下的独立 md 文件，不要写在这里。

14. 本仓库落点覆盖

本仓库的 bug 经验优先记录在当前技能目录：.agents/skills/fix-bug/record-bug-fix-memory/*.md
根级 CLAUDE.md、AGENTS.md、GEMINI.md 只在用户明确要求同步 AI 记忆文档时才更新

Mais deste repositório

mesmo repositório

init-release-base-relizy-and-bumpp

ruan-cat/monorepo

Use when 需要为 pnpm monorepo 从零接入 relizy + bumpp 组合发版方案，或处理 init relizy、init bumpp、接入发版、monorepo 发版初始化、relizy + bumpp、 relizy.config、bump.config、changelog.config、独立版本、GitHub Release 自动化。

2026-07-134

cleanup-agent-team-node-processes

ruan-cat/monorepo

当 Windows 或 PowerShell 的 agent team 会话结束后，出现疑似孤儿 node 进程、可证明归属当前 run 的残留 MCP 或开发服务器子进程、残留 Node 监听器，或多代理自动化后的 Node 进程归属不清时使用。 Use when Windows or PowerShell agent-team sessions leave suspected orphan node processes, stale MCP or dev-server children provably owned by the current run, lingering Node listeners, or unclear Node ownership after multi-agent automation.

2026-07-114

do-long-task

ruan-cat/monorepo

当复杂开发、修复、重构、迁移、验证或 OpenSpec change 需要跨可恢复 checkpoint 持续推进、需要在上下文丢失后恢复，或需要把进度与失败记录写入持久文件时使用；当用户要求生成 Claude Code `/goal`、Codex `/goal` 或 do-long-task 长任务提示词时也使用。不要用于一次性短改、问答、简单格式化、changeset、发版日志或纯计划讨论。 Use when a complex development, fix, refactor, migration, verification, or OpenSpec change must be advanced across resumable checkpoints, recovered after context loss, or executed with durable progress and failure notes; also use when the user asks to generate a Claude Code `/goal`, Codex `/goal`, or do-long-task prompt. Do not use for short one-off edits, Q&A, simple formatting, changesets, release notes, or pure planning.

2026-07-114

use-pnpm

ruan-cat/monorepo

Use when 需要处理 pnpm 包管理、workspace 命令、npm/npx/yarn 到 pnpm 的替换、Windows 或 PowerShell pnpm 故障、Corepack 管理的 pnpm、NVM Desktop 切换 Node 后的路径错位、全局包更新、ERR_PNPM_UNEXPECTED_VIRTUAL_STORE、virtual-store-dir 混淆、PNPM_HOME/global-dir/store-dir 诊断，或 pnpm install/update/rebuild 排障；English: handling pnpm package management, workspace commands, npm/npx/yarn replacement, Windows or PowerShell pnpm failures, Corepack-managed pnpm, NVM Desktop Node switches, global package updates, ERR_PNPM_UNEXPECTED_VIRTUAL_STORE, virtual-store-dir confusion, PNPM_HOME/global-dir/store-dir diagnosis, or pnpm install/update/rebuild troubleshooting.

2026-07-114

init-ai-md

ruan-cat/monorepo

初始化和增量更新 AI 记忆文件（CLAUDE.md、AGENTS.md、GEMINI.md）。通过交互式选择和差异对比，智能补全记忆项内容。触发条件：当用户提及初始化记忆文件、更新 CLAUDE.md、同步 AI 记忆、 init-ai-md 等关键词时主动调用。

2026-07-104

use-vercel-deploy-in-monorepo

ruan-cat/monorepo

在 pnpm workspace 组织的 monorepo 或独立仓库中完成 Vercel 部署的辅助型技能。先按"部署形态"分层（monorepo 子包 / 独立仓库），再按框架（Nuxt、Nitro、Vite、UniApp H5）给出模板。覆盖 Root Directory、Output Directory、Build Command、package.json 脚本与 turbo.json 任务链配置，解决 pnpm workspace 依赖解析和产物路径问题。本地配置完成后可排查 vercel.json 覆盖、多项目配置污染和 .vercel/project.json 绑定问题，并结合支持 Vercel MCP 的 AI 客户端检查项目状态与触发部署。

2026-07-094

name	record-bug-fix-memory
description	当用户要求在 bug 已经定位并修复后，记录排错经验、事故结论、AI 记忆更新、复盘摘要或本地 MCP 记忆时使用。这个技能只负责沉淀 "发生了什么、为什么会发生、如何修好、以后要记住什么"，不要把它用于实际修复 bug。
template-version	2.0.0
metadata	{"author":"openspec","version":"1.0","generatedBy":"1.1.1"}

记录 Bug 修复记忆

1. 概述

使用这个技能，把已经完成的排错结果沉淀成可复用的长期记忆。

目标是保存根因、有效修复路径、错误假设和验证证据，让后续 agent 不再重复同样的弯路。

核心原则：记录决策链，不记录流水账。

2. 存储架构

本技能采用双层存储架构：

SKILL.md：只放流程指导 + 案例摘要索引（保持精简，不超过 150 行流程指导）
独立案例文件：每条详细事故记录写成独立的 YYYY-MM-DD-{slug}.md 文件，与 SKILL.md 同目录

禁止将完整事故记录正文内嵌到 SKILL.md 中。SKILL.md 中只保留摘要索引。

2.1. 目录结构

.agents/skills/fix-bug/record-bug-fix-memory/
├── SKILL.md                              # 流程指导 + 摘要索引
├── 2026-03-28-unocss-color-safelist.md   # 详细案例
├── 2026-03-29-nitro-dual-runtime.md      # 详细案例
└── ...                                   # 更多案例文件

2.2. 案例文件命名规范

格式：YYYY-MM-DD-{slug}.md
slug 使用小写英文 + 短横杠，简明描述事故主题
示例：2026-03-28-unocss-config-driven-color-safelist.md

2.3. 案例文件必填结构

# YYYY-MM-DD {事故简述}

## 1. 问题现象

{从用户视角看，哪里坏了}

## 2. 实际根因

{真正出错的地方}

## 3. 关键误导点

{哪个错误假设或误导信号浪费了时间}

## 4. 有效修复

{真正解决问题的改动}

## 5. 验证方式

{证明修复成功的证据}

## 6. 后续约束

{未来 agent 必须先检查什么、避免什么}

2.4. 摘要索引格式（写在 SKILL.md 的"案例索引"章节中）

### {事故简述}（YYYY-MM-DD）

- 详细案例：`YYYY-MM-DD-{slug}.md`
- 适用场景：{一句话描述触发条件}
- 关键约束：{一句话核心教训}

3. 何时使用

在以下场景使用这个技能：

用户要求更新 AI 记忆文档、记录经验教训、补充事故记录、编写复盘摘要。
bug 已经完成复现，且有效修复路径已经明确。
这条经验是仓库特有知识，应该对未来 agent 可见。
需要把结论同步到本地 MCP 记忆，例如 Memorix。

以下情况不要使用这个技能：

bug 还在调查中，根因没有确认。
用户要求的是修复实现，而不是经验沉淀。
你手里只有猜测、片段证据或临时绕过方案。

4. 前置输入

开始写记忆前，必须能回答下面六个问题：

对用户来说，表面现象是什么？
实际根因是什么？
哪个错误假设或误导信号浪费了时间？
最终是哪一个具体改动修好了问题？
用什么验证证明修复成立？
这条记忆应该写到哪里？

如果有任何一个问题答不上来，先完成排错，不要提前写记忆。

5. 写到哪里

详细案例：写到本技能目录下的独立 md 文件（默认落点）
摘要索引：同步更新 SKILL.md 的"案例索引"章节
跨会话的本地记忆：写到 Memorix，类型用 gotcha、decision 或 problem-solution
仓库级规则：只有当经验会影响整个仓库的未来 agent 时，才同步写入根级 CLAUDE.md、AGENTS.md、GEMINI.md

6. 记录流程

先确认 bug 已经理解清楚并且修复完成。
把结果压缩成 4 到 6 条高信号事实。
创建独立案例文件 YYYY-MM-DD-{slug}.md，按必填结构写入详细内容。
在 SKILL.md 的"案例索引"章节追加一条摘要索引。
如果经验影响整个仓库，同步更新根级 AI 记忆文档。
用同样的结论更新 Memorix，并选对记忆类型。
- 如果当前会话没有实际暴露 Memorix MCP 工具，就必须明确告诉用户"本会话无法写入 Memorix"，不能因为仓库文档声明"可用"就假定真的已经拿到工具。
回读一遍文本，删掉瞬时噪音、猜测和低价值命令历史。
如果用户还要求提交 commit，把提交动作交给单独的 git 工作流处理。

7. 写入经验时必须保留的额外信息

如果这次 bug 与仓库已有事故模式相似，写记忆时不要遗漏下面这些额外信息：

这次问题是否打破了某个"用户已确认稳定"的基线
是否存在"不要乱改"的配置
首个可信信号来自哪里，是终端日志、浏览器 console、网络请求，还是构建输出
这次修复属于哪一类：依赖实例统一、废弃 API 清理、导入路径修正、类型断言补齐、构建配置兜底、依赖入口兼容、模板层覆盖、样式层补齐、还是启动前置准备
这次是否存在误导性很强的假象
最终验证是否基于 fresh 进程、fresh 日志和 fresh 页面，而不是历史缓存

8. 验证证据写法

未来写事故记录时，优先记录可重复验证的证据，而不是模糊措辞。

好的写法：pnpm exec tsc --noEmit 输出中相关错误为 0
好的写法：fresh dev.stderr 为空
好的写法：修复文件均无类型错误输出
好的写法：pnpm install 后依赖版本一致，peer dependency 无冲突
不好的写法：应该没问题了
不好的写法：看起来像是好了

9. 不要写成什么

把根级 AI 记忆经验吸收到技能里，不等于把技能写成修复手册。下面这些内容不应该成为这个技能的主体：

大段命令执行流水
与当前仓库无关的泛化 debug 理论
逐条罗列所有试错过程
把某一次临时绕过方案包装成永久规则
用"必须执行这些命令"代替"应该记录哪些结论"

10. 好记忆的特征

解释清楚"为什么会坏"，而不是只写跑了什么命令
明确指出第一条可信线索，说明它如何打破错误假设
用可复用的方式描述最终修复
写出未来 agent 可以重复执行的验证动作
让下一次排错明显更短

11. 常见错误

根因还没确认，就开始写猜测性结论
写成很长的 debug 日记，而不是可复用结论
仓库级经验写到了错误的位置
没把导致绕路的错误假设写出来
把修复说明和记忆沉淀混在一起
忘了同步本地 MCP 记忆
只因为仓库记忆文件声明"有 Memorix"，就跳过当前会话工具可用性核对
把完整事故记录正文写进 SKILL.md 而不是独立案例文件

12. 边界

这个技能只负责记忆沉淀和总结。

它不能替代调试、实现、测试和修复工作流。如果 bug 还没修好，先使用合适的调试或实现技能，等结果稳定后再回到这个技能做经验沉淀。

13. 案例索引

此章节在初始化时为空。随着项目中实际的 bug 修复经验积累，按照第 2.4 节的格式逐步补充摘要索引。详细案例内容写入同目录下的独立 md 文件，不要写在这里。

14. 本仓库落点覆盖

本仓库的 bug 经验优先记录在当前技能目录：.agents/skills/fix-bug/record-bug-fix-memory/*.md
根级 CLAUDE.md、AGENTS.md、GEMINI.md 只在用户明确要求同步 AI 记忆文档时才更新