菜单
沉淀与查阅跨模块一致性问题：同一语义在多处被独立实现且实现之间已经漂移（列宽、魔法数字、按 DB 类型复制的组件家族、已有抽象覆盖不全等）。两个时机使用：任务收尾回顾本次读过或改过的代码并把够判据的发现记成篇目； 以及改表格、公共组件、按 DB 类型复制的代码前查阅已有篇目。当用户要求总结、复盘、沉淀经验， 或问「这类问题还有哪些」「以前记过什么」时也使用。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/TencentBlueKing/blueking-dbm --skill codebase-insights命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
审查本地未提交改动（工作区 + 暂存区 + 未跟踪文件），按 DBM 前端约定给出缺陷优先的 P0-P3 报告，覆盖 Vue 3 响应式陷阱、前端安全（XSS、跳转重定向、敏感信息、高危操作鉴权）与 db-manage 模块约定。当用户要求代码审查、code review、review 一下这次改动、看看有没有安全问题、提交前检查时使用。
为一个前端项目生成专属的 `<项目>-frontend-design` 设计规范 skill：从源码反向提炼设计令牌 （间距、字号、色板、尺寸档位）、归纳页面骨架与交互流程，产出可脱离项目独立运行的规范文档与页面骨架资源。 当用户要求生成/新建前端设计规范 skill、沉淀项目排版交互规范、 或提出「给这个项目做一个 xxx-frontend-design」时使用。
生成 frontend_master 待合入 v1.5.0 的 commit 发布计划记录。当用户需要发布计划、 发版记录、核对 frontend_master 还有哪些提交未合入 v1.5.0，或给出 release PR 链接 要求生成 commit 清单时使用。是否已合入的判定逻辑：以 commit msg 尾部的 issue id （如 #19152）在 v1.5.0 历史中是否存在相同 issue id 的提交为准（识别 cherry-pick）。
基于 SOC 职业分类
正在显示 SKILL.md
| name | codebase-insights |
| description | 沉淀与查阅跨模块一致性问题：同一语义在多处被独立实现且实现之间已经漂移（列宽、魔法数字、按 DB 类型复制的组件家族、已有抽象覆盖不全等）。两个时机使用：任务收尾回顾本次读过或改过的代码并把够判据的发现记成篇目； 以及改表格、公共组件、按 DB 类型复制的代码前查阅已有篇目。当用户要求总结、复盘、沉淀经验， 或问「这类问题还有哪些」「以前记过什么」时也使用。 |
| disable-model-invocation | true |
沉淀「同一语义在多处被独立实现、且实现之间已经漂移」这类问题。篇目存在本 skill 的 insights/ 下，一个主题一篇
.md，文件名即主题（kebab-case）。
全程只读代码，不改代码。 记录与修复是两件事，修不修由用户决定。
insights/ 的文字才会传递到下一次每个任务收尾时回顾一次：本次读过或改过的代码里，有没有同一语义被多处独立实现、且取值或写法已经漂移的情况。
满足其一才记：
不记：单点 bug、个人风格偏好、以及 ESLint / Prettier / Stylelint 能自动修的问题。宁可不记，也不要记成流水账——清单一旦注水就没人看了。
ls .agents/skills/codebase-insights/insights/ 看有没有同主题。有就往里补证据，不新开一篇动手改代码前先 ls 一下 insights/，文件名即主题，一眼能判断有没有相关篇目，有就读完再动手，避免在已知有漂移的地方再添一处新取值。
成本只有一次 ls，不要因为「这次改动看起来无关」而跳过——漂移正是从每次都觉得无关开始的。
# <主题>
状态：未处理 | 处理中 | 已修复
## 现象
一段话说清楚这是什么类型的漂移，以及它造成的实际后果（不是「不优雅」，是用户能看到或维护者会踩到的后果）。
## 证据
每条给 `文件:行` 与实际取值。多个来源的同类取值用表格汇总，再补几条最有说服力的具体出处。
## 项目里已有的正确做法
这个项目通常已经有做对的地方，写清是哪里、为什么它是对的、以及它没覆盖到哪。没有正确做法就写「暂无」，不要编。
## 建议方向（未采纳）
给方向和理由，同时写清哪些直觉做法不可行、为什么。标注「未采纳」，避免后来者误以为已成定论。
## 待查证
本篇没覆盖的范围、以及尚未验证的推断。推断不与已核实的证据混写。
文件:行 和实际取值，不写「很多地方都是这样」ls 加自解释的文件名即可。多一层索引就多一处会腐烂的东西