@routerhub/agent-rules 1.5.85 → 1.5.87

package/skills/figma-to-code/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: figma-to-code
+description: >-
+  Figma 设计稿还原为代码 / 实现 Figma 设计。触发场景包括但不限于：
+  「figma」「Figma」「FIGMA」出现时。
+  「实现这个设计」「还原这个设计」「按照设计稿」「按设计稿」「照着设计稿」「根据设计稿」「设计稿还原」「设计还原」「Figma还原」「figma还原」。
+  「把这个页面做出来」「实现这个页面」「还原这个页面」「做这个页面」「写这个页面」「开发这个页面」「切这个页面」「切图」「切页面」。
+  「figma链接」「Figma链接」「设计稿链接」「figma地址」「Figma地址」。
+  「从Figma」「从figma」「看下设计稿」「看下设计」「看设计」「看Figma」。
+  任何提供 Figma URL 或提及 Figma 设计稿并要求生成/实现代码的场景都应触发。
+  使用MCP三步验证法：get_design_context（设计意图）→get_metadata（精确坐标）→坐标反推布局，禁止直接使用get_design_context生成的Tailwind代码。
+---
+
+# Figma 设计还原
+
+将 Figma 设计稿还原为代码，以 Figma 文件为唯一事实源。
+
+## MCP 三步验证法
+
+⚠️ **禁止直接使用 `get_design_context` 生成的代码**。`get_design_context` 的输出是大模型推导的近似值，数值和结构均不可信。
+
+### 第 1 步：`get_design_context` → 获取设计意图
+
+用 `mcp__figma__get_design_context` 了解组件整体结构、颜色、字体、视觉效果。
+⚠️ 仅用于理解设计意图，数值和结构不可信。
+
+### 第 2 步：`get_metadata` → 获取精确坐标（唯一事实源）
+
+用 `mcp__figma__get_metadata` 获取每个节点的真实 x/y/width/height 坐标。
+这是所有尺寸、间距、定位的唯一事实源。
+
+### 第 3 步：坐标反推规则
+
+| 场景 | 反推方法 |
+|------|----------|
+| Section 上下 padding | 子元素 y 坐标 = 上 padding；父级高度 - 子元素 y - 子元素高度 = 下 padding |
+| 元素间距（gap） | 兄弟元素之间的 y 差值（纵向）或 x 差值（横向） |
+| 元素是 flex 还是 absolute | 子元素 x 超出父元素左边界 → absolute；子元素在父元素范围内 → flex |
+| 固定宽度还是自适应 | metadata 有明确 width 值 → 固定宽度；否则 → 自适应 |
+
+## 常见踩坑
+
+1. **`get_design_context` padding 不准** → 以 metadata 坐标为基准重新计算
+2. **按钮被嵌套在文字区域内** → metadata 中同级 x 不同、y 相近 = 横向并排，不应嵌套
+3. **固定宽度容器被改成全宽** → metadata 中有明确 width 的容器不能去掉固定宽度
+4. **装饰图片被当成 flex 子元素** → metadata 中 x 坐标超出父元素范围 = absolute 定位
+
+## 交付验收
+
+- 交付前对照 Figma 做视觉和交互验收
+- 发现无法完全还原的素材、字体、数据或平台限制时，明确说明差异和原因
+- 逐项验证：布局、尺寸、间距、颜色、字体、层级、组件状态、响应式规则
+
+## 代码实现规范
+
+- 所有尺寸单位使用 `rem`（1rem = 16px）
+- 使用 Tailwind CSS utility classes，禁止原生 CSS
+- 禁止硬编码数字，常量/枚举统一定义

package/skills/tdd-workflow/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: tdd-workflow
+description: >-
+  新需求 / 新功能 / 功能开发的 TDD 全流程。触发场景包括但不限于：
+  「新需求」「新功能」「新特性」「新模块」「新增」「添加功能」「加功能」「加个功能」「加一个功能」「做一个功能」「开发一个功能」「实现一个功能」。
+  「帮我开发」「帮我实现」「帮我写」「帮我做」「帮我搞」「帮我弄」「开发一下」「实现一下」「写一下」「做一下」「搞一下」「弄一下」。
+  「需求来了」「有个需求」「来了个需求」「接到需求」「需求是」「要做」「需要做」「需要开发」「需要实现」「需要写」「要开发」「要实现」「要写」「要做」。
+  「功能开发」「功能实现」「业务开发」「业务实现」「代码开发」「代码实现」。
+  「修改代码」「改代码」「改一下」「改一改」「改一版」「改功能」「改一下功能」「修改功能」「调整一下」「调整功能」「优化一下」「重构一下」。
+  「需求文档」「需求分析」「写需求」「需求设计」「方案设计」「设计方案」「出方案」。
+  「开始开发」「开始写」「开始写代码」「开始编码」「开始做」「开工」「动手」「动手吧」「开始吧」「搞起」「开搞」。
+  严格按：需求记录→确认版本→测试先行→基线回归→实现代码→全量回归→上线前回归，七步不可跳过。
+---
+
+# TDD 开发流程
+
+测试驱动开发，每次接收新需求时强制遵循。
+
+## 七步流程
+
+### 第 1 步：需求记录（留痕）
+
+在 `docs/` 目录下新建需求文档（HTML 格式，中文命名），记录：
+- 需求背景
+- 功能范围
+- 验收标准
+- 所属版本号（未说明则归「全量测试」）
+
+### 第 2 步：确认归属版本
+
+明确写入：「归属版本：XXX」或「归属范围：全量测试」。
+
+### 第 3 步：测试先行
+
+⚠️ 先写测试用例，再写业务代码：
+
+| 类型 | 位置 |
+|------|------|
+| Go 后端 | `app/supply/`、`app/controller/` 下写 `_test.go` |
+| 前端 UI | `admin_web/e2e/` 或 `user_web/e2e/` 下写 Playwright E2E |
+| API 接口 | `scripts/regression-api-smoke.js` 加冒烟子命令 |
+
+然后在 `scripts/superpowers-regression-runner.js` 的 `TEST_CASES` 中注册新用例。
+测试用例描述、断言必须使用中文。
+
+**测试用例编写规范**：
+- 先写主流程（happy path），再写边界情况
+- 必须模拟真实用户操作：打开页面 → 查看状态 → 点击/填写 → 提交 → 验证结果
+- 覆盖：新建、编辑、删除、查看/搜索、状态流转、异常操作
+- 每条测试用例必须附带对应步骤的截图
+
+### 第 4 步：跑基线回归
+
+⚠️ 改代码之前，先跑一次全量回归建立基线：
+
+```bash
+pnpm run regression:open
+```
+确认改动前所有已有用例全部通过。
+
+### 第 5 步：实现业务代码
+
+按需求文档和测试用例实现功能，持续跑新增测试用例。
+
+### 第 6 步：跑全量回归
+
+⚠️ 改完代码后跑全量回归，确认：
+- 新增用例全部通过
+- 所有已有用例仍然通过
+
+### 第 7 步：上线前回归
+
+⚠️ 每次部署生产前，必须跑：
+```bash
+node 上线回归测试点.js
+```
+
+## 重要规则
+
+- ⚠️ AI 第一反应不是写代码，而是写需求文档 + 设计测试用例
+- ⚠️ 改动必须有迹可循：需求文档 → 测试用例 → 回归报告 → 代码改动
+- 如果用户说「直接改就行不用测试」，必须提醒测试是安全网
+- 测试用例命名含需求关键词，方便追溯