deepseeker-code 1.0.53 → 1.0.54

package/dist/builtin/api-test/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: api-test
+description: 后端接口自动测试。当用户要求测接口、验证 API、接口回归、检查接口返回时激活。
+version: 1
+triggers: 接口测试, 测接口, API 测试, 接口回归, 验证接口
+---
+
+# 后端接口自动测试（api-test）
+
+用 http_request 对本地后端做结构化验证，产出用例级汇总表。
+
+## 步骤
+
+1. **提取接口清单**（不要凭空编）：
+   - grep 路由定义定位真实接口：Express/Koa（`router.(get|post|...)`、`app.(get|post|...)`）、Nest（@Controller/@Get 装饰器）、Spring（@GetMapping 等）。
+   - read_file 读控制器确认：方法 + 路径 + 参数（query/body）+ 鉴权方式（header/token/cookie）+ 前置中间件。
+   - 用户点名了接口就只测点名的；没点名则测本次改动涉及的接口，不要全量扫。
+
+2. **准备登录态**：接口要鉴权时，先用 http_request 调登录接口拿 token。凭证来源：用户提供的测试账号或 .env 里的既有测试凭证；禁止硬编码任何真实密码，拿不到凭证就问用户。
+
+3. **逐接口执行用例**（http_request，注意它每次都走审批——把用例组织成尽量少的调用）：
+   - 正常用例：合法参数 → 断言 2xx + 关键业务字段（code/data 结构）。
+   - 边界用例（按需）：缺必填参 → 期望 4xx；错误格式 → 期望 4xx 不崩；伪造/过期 token → 期望 401，不漏鉴权。
+   - 断言看实际响应原文，引用关键字段值作证据，不要只说"返回正常"。
+
+4. **汇总表**：接口 | 用例 | 期望 | 实际（状态码 + 关键字段） | 结论。失败附响应摘录（截前几百字符）与定位建议（参数错？鉴权漏？逻辑 bug？）。
+
+## 硬约束
+- 只测本地环境（localhost/127.0.0.1）。目标 URL 指向外部环境时立即停止并向用户确认。
+- 写操作接口（POST/PUT/DELETE）用低破坏性用例先行：测试数据带明显标记（如 e2e-test- 前缀），禁止删除/修改看起来是真实业务的数据；拿不准就先问用户。
+- 禁止未读路由定义就照前端代码里的 URL 猜接口——前端引用的可能已过期。
+- 接口行为与文档/预期不符时如实报告差异，不要为了"全绿"放宽断言。

package/dist/builtin/browser-test/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: browser-test
+description: 浏览器自动化测前端。当用户要求打开页面验证、点一点看看、E2E 测试、界面交互测试、检查页面报错时激活。
+version: 1
+triggers: 浏览器测试, 打开页面, E2E, 界面测试, 点一下, 页面验证
+---
+
+# 浏览器自动化测试（browser-test）
+
+经 MCP 的 playwright server 驱动真实浏览器验证前端界面。**没有** mcp__playwright__* 独立工具——统一走 `mcp_list_tools` 查目录、`mcp_call(server="playwright", tool=<名>, args={...})` 调用。
+
+## 步骤
+
+1. **前置确认**：目标页面可达的 baseURL（用户给的，或从 dev server 配置读）。服务没起先走 run-stack 流程。若 mcp_list_tools 里没有 playwright 目录：告知用户需在 ~/.deepseeker-code/mcp.json 配置 playwright server，不要硬调。
+
+2. **打开页面**：`browser_navigate`（args: `{url}`）→ 立即 `browser_snapshot`。snapshot 是可访问性树（含每个可交互元素的 ref），**它是你唯一可靠的页面视图**。
+
+3. **交互**：按最新 snapshot 里的 ref 做 `browser_click` / `browser_type` 等。每次动作后重新 snapshot——ref 在页面变化后会失效。
+   - 表单类：先填完所有字段再做提交类动作，减少往返。
+   - 断言依据 snapshot 里的文本内容，不是截图。
+
+4. **取证**：
+   - `browser_console_messages`：收 console error/warning，界面"看着正常"但脚本报错是最常见的隐藏问题。
+   - `browser_network_requests`：找 4xx/5xx 失败请求，前端白屏常是接口挂了。
+
+5. **汇总**：通过/失败结论、复现步骤（做了哪些动作）、console 错误清单、失败请求清单；失败时附 snapshot 相关片段。
+
+## 硬约束
+- mcp_call 每次调用都要用户审批：把动作合并到最少必要次数，禁止无意义的反复 snapshot 或重复 navigate。
+- 禁止臆造 ref 或凭记忆引用旧 snapshot 的 ref；一切以最新 snapshot 为准。
+- 禁止用 browser_take_screenshot 替代 snapshot 做断言（图片读不准 DOM 结构），截图只用于给用户看效果。
+- 页面行为与预期不符时，如实报告差异，不要"再点几下试试"掩盖问题。

package/dist/builtin/build-fix/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: build-fix
+description: 编译报错闭环。当用户要求修编译错误、构建失败、类型报错，或提到 build/tsc/编译不过/type-check 时激活。
+version: 1
+triggers: 编译报错, 构建失败, build, type-check, 编译不过, 类型错误
+---
+
+# 编译报错闭环（build-fix）
+
+目标：把「构建失败」推进到「构建退出码 0」，修复必须以**重跑构建**为唯一验收标准。
+
+## 步骤
+
+1. **探测构建命令**（不要臆造）：
+   - read_file 读 package.json。`scripts` 里有 `type-check` / `vue-tsc` 类脚本时优先用（纯类型检查最快，不打产物）。
+   - 退化顺序：`type-check` → `build` → 按 devDependencies 判定：typescript→`npx tsc --noEmit`；vue 项目→`npx vue-tsc --noEmit`。
+   - Java/Go 等其他语言：读 pom.xml / go.mod 确认后用 `mvn compile` / `go build ./...` 等对应工具链命令。
+
+2. **跑构建**：
+   - 预期几秒内结束的：前台 run_command。注意它对长任务会自动转后台并返回 task_id——收到 task_id 就改用 get_background_output 跟进，不要重复起命令。
+   - 构建结果以输出末尾的系统判定（⟦DSC_EXIT⟧）为准；系统判定失败就是失败，禁止乐观假设成功。
+
+3. **解析错误**：
+   - 从输出中定位**第一条**错误：`file:line:col + 错误码`（TS 形如 `error TS2339`）。同类错误批量列清单，先修共因（往往一个根因引发一串）。
+   - 输出被折叠时只显示头尾若干行——错误通常在尾部，需要全文时用 get_background_output 加大 tail_lines 或重跑定向命令。
+
+4. **逐错误修复**：
+   - read_file 看上下文 → edit_file 修最小必要改动，不顺手重构。
+   - TS/JS 文件改完可用 get_diagnostics 单文件验证（秒级，不用等全量构建）。
+   - .vue 文件 get_diagnostics 不支持：直接以下一步的重跑构建为准；若工具表里有 ide_diagnostics（IDE 宿主）可用它快速确认。
+
+5. **重跑构建验收**：回到步骤 2 重跑，直至退出码 0。最多 5 轮；仍不过说明方向错了，如实向用户汇报已试过什么、卡在哪，不要硬编过。
+
+## 硬约束
+- 禁止未重跑构建就宣称"修好了"；禁止无视系统判定的执行失败警告。
+- 禁止臆造构建命令；scripts 里没有的就按依赖判定，判定不了就问用户。
+- 一次只修一个根因，修完立即重跑验证，不攒一批改完再跑（定位不了回归来源）。

package/dist/builtin/run-stack/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: run-stack
+description: 启动并编排本地服务栈。当用户要求把项目跑起来、启动前后端、起数据库、dev server、看服务日志时激活。
+version: 1
+triggers: 启动服务, 跑起来, dev server, 起前后端, 起数据库, 看日志
+---
+
+# 本地服务栈编排（run-stack）
+
+目标：把项目依赖的服务按序拉起，并向用户汇报每个服务的 task_id、端口与就绪证据。
+
+## 步骤
+
+1. **盘点**（不要假设架构）：
+   - read_file 读 package.json（scripts 里的 dev/serve/start）、docker-compose.yml（有哪些依赖服务）、.env / .env.example（端口、连接串）。
+   - 排出启动顺序：数据库/中间件 → 后端 → 前端。理不清就问用户，不要瞎猜端口。
+
+2. **数据库/中间件**：有 docker-compose.yml 用 `docker compose up -d <服务名>`（前台 run_command，detached 语义天然合适）。启动前先探端口（`netstat -ano | findstr <端口>`）避免撞上已在跑的实例——已在就复用，不要重启。
+
+3. **后端**：`run_in_background` 起 dev 服务 → `get_background_output`（wait_seconds=10~20）看启动日志：
+   - 就绪证据：端口监听字样（"listening on"/"started"/端口号）、无 stack trace。
+   - 失败证据：异常栈、端口占用（EADDRINUSE）——端口占用先报占用进程，不擅自杀。
+
+4. **就绪判定**（自适应）：
+   - 工具表里有 `wait_http_ready`：优先用它探健康端点或首页（免审批、阻塞至就绪或超时，超时回执里带最后状态码可当线索）。
+   - 没有：get_background_output 看日志关键字确认，或 http_request 单次探测首页。
+
+5. **前端**：同步骤 3~4。全栈起来后建议用 browser-test 流程做一次页面冒烟。
+
+6. **汇报**：逐服务列出——task_id、启动命令、端口、就绪证据（日志行或 HTTP 状态）；失败的说明原因与已尝试的动作。
+
+## 硬约束
+- run_in_background 对同命令+同目录有互斥锁，重复启动会被拒：重启前先 stop_background_task 旧任务，或确认它已退出。
+- 禁止杀不是自己起的进程（查占用发现 PID 后，要么向用户确认要么换端口）。
+- 服务"看起来没输出"不等于没在启动：先用 get_background_output 加大 tail_lines / wait_seconds 再下结论。
+- 向用户汇报的端口必须是日志/探测验证过的，禁止报臆断的默认端口。