[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MXH21VR3005K6R49RPCPC7":3,"skill-same:01M6MXH21VR3005K6R49RPCPC7":57},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":26,"linkOnly":27,"markdownContent":28,"markdownBody":28,"frontMatter":29,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":6,"ownerHtmlUrl":35,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":36,"install":37,"resources":50},"01M6MXH21VR3005K6R49RPCPC7","test-writer",null,"miniidealab\u002Fopenlogos","miniidealab","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F4251156?v=4","01M6MX6BM454XESZCRPBQQHKRT","FredHuang","01M6MX6BR4417H4QA658D4GW9X",581,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Flogos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fskills\u002Ftest-writer\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25],"test","test writer","writer","2026-11-10 10:12:30",false,"# Skill: Test Writer\n\n> 基于时序图、API 规格和 DB 约束，为每个业务场景设计单元测试用例和场景测试用例。适用于所有项目类型（API 服务、CLI 工具、前端应用、库等），是代码生成前的必要前置步骤。\n\n## 触发条件\n\n- 用户要求设计测试用例或测试方案\n- 用户提到 \"Phase 3 Step 4a\"、\"Step 4a\"、\"测试先行\"、\"测试设计\"\n- 已有场景时序图，需要在写代码前设计测试\n- 用户指定某个场景编号（如 S01）需要设计测试\n\n## 前置依赖\n\n- `logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F2-scenario-implementation\u002F` 中包含场景时序图（**必需**）\n- `logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F3-deployment\u002F` 中包含部署方案（如项目需要部署则必需）\n- `logos\u002Fresources\u002Fapi\u002F` 中包含 API 规格（有则读取，无则跳过——非 API 项目可能没有）\n- `logos\u002Fresources\u002Fdatabase\u002F` 中包含 DB DDL（有则读取，无则跳过）\n- `logos\u002Fresources\u002Fprd\u002F1-product-requirements\u002F` 中包含需求文档（用于追溯验收条件）\n\n**不可跳过**：无论项目类型如何，Step 4a（本 Skill）都必须执行。若部署方案声明需要部署，本 Skill 必须一并设计部署后冒烟测试。\n\n## 核心能力\n\n1. 从 API 字段约束（类型、格式、长度、枚举）中提取单元测试用例\n2. 从 DB 约束（UNIQUE、CHECK、NOT NULL、FK）中提取单元测试用例\n3. 从业务规则和 EX 异常用例中的单点错误处理提取单元测试用例\n4. 从时序图 Step 序列提取场景测试用例（主路径）\n5. 从 EX 异常用例提取场景测试用例（异常路径）\n6. 从部署方案提取 smoke 测试用例（仅需要部署的项目）\n7. 从 Phase 1\u002F2 验收条件反向校验测试覆盖完整性\n\n## 执行步骤\n\n### Step 1: 加载场景上下文\n\n读取以下文件建立完整上下文：\n\n- 场景时序图（`logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F2-scenario-implementation\u002F`）\n- 部署方案（`logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F3-deployment\u002F`）—— 如果项目需要部署\n- API YAML（`logos\u002Fresources\u002Fapi\u002F`）—— 如果存在\n- DB DDL（`logos\u002Fresources\u002Fdatabase\u002F`）—— 如果存在\n- Phase 1 需求文档（验收条件）\n- Phase 2 产品设计文档（交互级验收条件）\n\n确认当前场景的：\n- **Step 数量**：时序图中有多少个 Step\n- **EX 数量**：有多少个异常用例\n- **API 端点**：涉及哪些端点及其字段约束\n- **DB 表**：涉及哪些表及其约束\n\n### Step 2: 设计单元测试用例\n\n从三类来源提取单元测试用例：\n\n#### 2a: API 字段约束\n\n逐个检查 API 端点的 `requestBody` 和 `parameters`：\n\n- `type` → 类型错误用例（传入错误类型）\n- `format`（email、uuid、date-time）→ 格式校验用例\n- `minLength` \u002F `maxLength` → 边界值用例（刚好达到、超出 1 位）\n- `required` → 必填缺失用例\n- `enum` → 枚举值用例（合法值 + 非法值）\n- `minimum` \u002F `maximum` → 数值范围用例\n\n#### 2b: DB 约束\n\n逐个检查相关表的约束：\n\n- `UNIQUE` → 重复插入用例\n- `NOT NULL` → 空值插入用例\n- `CHECK` → 违反检查条件的用例\n- `FOREIGN KEY` → 引用不存在记录的用例\n- `DEFAULT` → 不传值时默认值验证\n\n#### 2c: 业务规则\n\n从时序图 Step 说明和 EX 异常用例中提取单点业务逻辑：\n\n- 权限检查（未登录、无权限）\n- 状态机转换（只有特定状态才能执行操作）\n- 限流 \u002F 频控规则\n- 数据计算逻辑（金额计算、折扣规则）\n\n**每个单元测试用例格式**：\n\n| 字段 | 说明 |\n|------|------|\n| ID | `UT-{场景编号}-{序号}`，如 `UT-S01-01` |\n| 描述 | 测试什么行为 |\n| 来源 | 约束出处（如 `auth.yaml → register → email: format:email`） |\n| 前置条件 | 测试前需要的状态 |\n| 输入 | 具体输入值 |\n| 预期输出 | 期望的返回值或错误信息 |\n\n### Step 3: 设计场景测试用例\n\n从两类来源提取场景测试用例：\n\n#### 3a: 主路径（时序图 Step 序列）\n\n将时序图的完整 Step 1 → Step N 视为一次端到端代码调用链：\n\n- 确定场景的入口和出口\n- 标注每个 Step 之间的数据传递（前一步输出作为后一步输入）\n- 验证最终状态（数据库记录、返回值）\n\n#### 3b: 异常路径（EX 异常用例）\n\n将每个 EX 异常用例展开为场景测试用例：\n\n- 标注异常在哪个 Step 触发\n- 验证异常触发后的处理逻辑（错误返回、补偿\u002F回滚）\n- 验证异常未影响其他数据的完整性\n\n**每个场景测试用例格式**：\n\n| 字段 | 说明 |\n|------|------|\n| ID | `ST-{场景编号}-{序号}`，如 `ST-S01-01`；无法自动化的用例加 `[manual]` 后缀，如 `ST-S01-05 [manual]` |\n| 描述 | 测试什么场景流程 |\n| 覆盖 Steps | 覆盖时序图的哪些 Step（如 `Step 1→6`）或哪个 EX（如 `EX-2.1`） |\n| 前置条件 | 测试前需要的状态和数据 |\n| 操作序列 | 按 Step 顺序的操作列表 |\n| 预期结果 | 最终状态（返回值 + 数据库状态 + 副作用） |\n\n#### 3c: `[manual]` 标记规则\n\n以下类型的 ST 用例**必须**在 ID 后追加 `[manual]` 标记，`openlogos verify` 会将其从覆盖率计算中排除，不计入 `defined_count`，不出现在 `uncovered_cases`：\n\n- 需要真实 TTY \u002F PTY 渲染（如 CLI 交互式提示、颜色输出、光标控制、进度条）\n- 需要跨窗口或多进程协作（如打开新终端窗口、进程间通信）\n- 需要人工视觉验证（截图对比、UI 渲染效果、字体\u002F颜色感知）\n- 依赖外部硬件或不可模拟的环境（摄像头、蓝牙、特定操作系统 GUI）\n\n**判断标准**：如果该用例在 CI 无头环境中无法稳定运行并自动断言结果，就应加 `[manual]`。\n\n#### 3d: 部署后冒烟测试（需要部署时）\n\n当部署方案存在且声明需要部署时，必须设计 smoke 测试用例。冒烟测试验证“部署后的环境是否可用”，不替代 UT\u002FST\u002FAPI 编排测试。\n\n从部署方案中提取以下用例：\n\n- 健康检查：服务进程、HTTP health endpoint、CLI version 或桌面应用启动检查\n- 核心入口：主页、登录页、主 API、主命令\n- 数据库迁移：关键表\u002F字段存在、迁移版本正确、初始化数据可读\n- 静态资源：前端 bundle、图片、CSS、字体或下载资源可访问\n- 配置与密钥：必要环境变量存在且没有使用测试占位值\n- 关键链路：最小可用用户路径，例如登录、创建一条核心记录、读取结果\n- 日志与监控：部署后没有阻断性错误\n\n**每个 smoke 用例格式**：\n\n| 字段 | 说明 |\n|------|------|\n| ID | `SMOKE-{模块}-{序号}`，如 `SMOKE-core-01` |\n| 描述 | 验证什么部署后行为 |\n| 来源 | 部署方案章节或检查项 |\n| 目标环境 | local \u002F staging \u002F production |\n| 前置条件 | 部署完成、迁移完成、必要配置存在 |\n| 操作 | 执行的命令、请求或访问动作 |\n| 预期结果 | 返回码、页面状态、日志、数据库状态 |\n\n**同步生成 code 阶段任务要求**：\n\n只要本轮新增或修改 `SMOKE-*` 用例，后续 `tasks.md` 的 `[code]` section 必须包含 smoke runner \u002F reporter \u002F dispatcher 闭环任务。测试设计阶段需要在交付说明中明确提醒 change-writer\u002Fcode-implementor：\n\n- 实现或更新 `scripts\u002Fsmoke-*.sh`、`scripts\u002Fsmoke-*.js` 或等效 smoke runner，且 runner 必须覆盖新增或修改的 `SMOKE-*` ID。\n- smoke runner 必须写入 `logos\u002Fresources\u002Fverify\u002Fsmoke-results.jsonl`，或写入 `logos.config.json.smoke.result_path` 指定路径。\n- `logos.config.json.smoke.command` 必须能执行新增 runner；推荐接入统一 `scripts\u002Frun-smoke.js` smoke dispatcher 自动发现 `scripts\u002Fsmoke-*`。\n- code 阶段完成前必须运行 smoke 覆盖预检或等效检查，确认新增 `SMOKE-*` 不在 uncovered cases 中。\n\n### Step 4: 覆盖度校验\n\n反向校验测试用例是否覆盖了所有关键约束：\n\n- [ ] Phase 1 每个正常验收条件至少对应 1 个 ST 用例\n- [ ] Phase 1 每个异常验收条件至少对应 1 个 ST 或 UT 用例\n- [ ] 每个 EX 异常用例至少对应 1 个 ST 用例\n- [ ] API 每个 `required` 字段至少 1 个 UT 用例\n- [ ] DB 每个 `UNIQUE` \u002F `CHECK` 约束至少 1 个 UT 用例\n- [ ] 如需要部署，部署方案中的每个部署后检查项至少对应 1 个 SMOKE 用例\n\n如有未覆盖项，补充用例或向用户说明理由。\n\n### Step 5: 验收条件追溯\n\n将 Phase 1 需求文档中的每个 GIVEN\u002FWHEN\u002FTHEN 验收条件提取出来，为每条分配一个追溯 ID，并关联到覆盖该条件的测试用例 ID。\n\n#### 验收条件 ID 规则\n\n- 格式：`{场景编号}-AC-{两位序号}`，如 `S01-AC-01`、`S01-AC-02`\n- 按需求文档中出现的顺序编号，正常和异常条件统一编号\n- 同一场景的 AC ID 必须连续且唯一\n\n#### 追溯表填写规则\n\n1. 从需求文档读取当前场景的所有验收条件（正常 + 异常）\n2. 为每条验收条件分配 AC ID\n3. 找到覆盖该条件的测试用例 ID（可以是 UT 或 ST），填入「覆盖用例」列\n4. 每个 AC 至少关联 1 个测试用例；如果无法覆盖，在「覆盖用例」列注明原因\n\n`openlogos verify` 会解析此追溯表，将 AC → 用例 ID → 运行结果三层联动，生成完整的验收追溯报告。\n\n### Step 6: 输出测试用例规格文档\n\n按场景输出 Markdown 格式的测试用例规格文档。若需要部署，同时输出 smoke 测试用例规格文档。\n\n### Step 7: 引导后续操作\n\n根据项目类型引导用户进入下一步：\n\n- **涉及 API** → 「继续进入 Step 4b 设计 API 编排测试？」\n- **不涉及 API** → 「测试设计已完成，建议进入代码生成：对我说『按 S01 的规格帮我实现』」\n\n## 输出规范\n\n- **文件格式**：Markdown\n- **存放位置**：`logos\u002Fresources\u002Ftest\u002F`\n- **命名规则**：`\u003Cmodule>-{场景编号}-test-cases.md`（如 `core-S01-test-cases.md`；从 `logos-project.yaml` 的 `modules[]` 读取当前模块，默认为 `core`）\n- 每个文件包含：单元测试用例（按来源分组）+ 场景测试用例（主路径 + 异常路径）\n- **Smoke 存放位置**：`logos\u002Fresources\u002Ftest\u002Fsmoke\u002F`\n- **Smoke 命名规则**：`\u003Cmodule>-smoke-test-cases.md`\n- 用例 ID 全局唯一：`UT-{场景编号}-{序号}` \u002F `ST-{场景编号}-{序号}` \u002F `SMOKE-{module}-{序号}`\n\n### 文档结构模板\n\n```markdown\n# {场景编号}: {场景名称} — 测试用例\n\n## 一、单元测试用例\n\n### 1.1 {分组名称}（来源：{约束出处}）\n\n| ID | 描述 | 来源 | 前置条件 | 输入 | 预期输出 |\n|----|------|------|---------|------|---------|\n| UT-S01-01 | ... | ... | ... | ... | ... |\n\n## 二、场景测试用例\n\n### 2.1 主路径：{场景名称}\n\n| ID | 描述 | 覆盖 Steps | 前置条件 | 操作序列 | 预期结果 |\n|----|------|-----------|---------|---------|---------|\n| ST-S01-01 | ... | Step 1→6 | ... | ... | ... |\n\n### 2.2 异常路径\n\n| ID | 描述 | 覆盖 EX | 前置条件 | 触发条件 | 预期结果 |\n|----|------|--------|---------|---------|---------|\n| ST-S01-02 | ... | EX-2.1 | ... | ... | ... |\n\n### 2.3 人工验证用例（[manual]）\n\n> 以下用例需要真实 TTY\u002FPTY 渲染或人工视觉验证，无法在 CI 中自动断言，标记为 [manual]。\n> `openlogos verify` 不会将其计入覆盖率，也不会报告为未覆盖。\n\n| ID | 描述 | 覆盖 Steps | 验证方式 |\n|----|------|-----------|---------|\n| ST-S01-05 [manual] | 交互式提示颜色和光标渲染正确 | Step 2 | 人工在真实终端观察 |\n\n## 三、覆盖度校验\n\n- [x] Phase 1 正常验收条件：全部覆盖\n- [x] Phase 1 异常验收条件：全部覆盖\n- [x] EX 异常用例：全部覆盖\n- [x] API required 字段：全部覆盖\n- [x] DB UNIQUE\u002FCHECK 约束：全部覆盖\n\n## 四、验收条件追溯\n\n| AC ID | 验收条件 | 覆盖用例 |\n|-------|---------|---------|\n| S01-AC-01 | 正常：全新项目初始化 — 创建完整目录结构 | ST-S01-01 |\n| S01-AC-02 | 正常：显式项目名与配置文件不一致时确认 | ST-S01-02 |\n| S01-AC-03 | 异常：项目已初始化 — 显示错误提示 | ST-S01-03, UT-S01-05 |\n```\n\n### Smoke 文档结构模板\n\n```markdown\n# {module}: 部署后冒烟测试用例\n\n## 一、冒烟测试范围\n\n| 环境 | 覆盖范围 | 说明 |\n|------|----------|------|\n| staging | 健康检查、核心 API、迁移检查 | launch 前必跑 |\n\n## 二、冒烟测试用例\n\n| ID | 描述 | 来源 | 目标环境 | 前置条件 | 操作 | 预期结果 |\n|----|------|------|----------|----------|------|----------|\n| SMOKE-core-01 | 健康检查接口可访问 | 部署方案：部署后检查 | staging | 服务已部署 | GET \u002Fhealth | 200 OK |\n\n## 三、覆盖度校验\n\n- [x] 健康检查：已覆盖\n- [x] 核心入口：已覆盖\n- [x] 数据库迁移：已覆盖\n- [x] 静态资源：已覆盖\n- [x] 关键链路：已覆盖\n```\n\n## 用例 ID 合约\n\n用例 ID（`UT-S01-01`、`ST-S01-01`）是设计文档与运行时的**绑定合约**：\n\n- 在 test-cases.md 中定义的 ID，必须在生成的测试代码中被原样使用\n- 测试代码的 reporter 会把每个用例的 ID 和运行结果写入 JSONL 文件\n- `openlogos verify` 通过 ID 将运行结果映射回测试用例规格，自动判定验收\n- `SMOKE-*` 由 smoke 测试脚本写入 `smoke-results.jsonl`，供 `openlogos smoke` 判定\n- 修改用例 ID 时必须同步修改对应测试代码或 smoke 脚本中的 ID\n\n详细的 JSONL 格式定义和各语言 reporter 代码模板见 `logos\u002Fspec\u002Ftest-results.md`。\n\n## 实践经验\n\n- **测试用例是设计文档，不是代码**：本 Skill 产出的是 Markdown 格式的测试用例规格，具体的测试代码在 Step 5 代码生成阶段由 AI 基于此规格实现\n- **先单元后场景**：单元测试用例覆盖单个函数的正确性，场景测试覆盖跨模块串联——先确保积木正确，再验证积木拼接\n- **不要遗漏 DB 约束**：很多 Bug 来自数据库层面的约束违反，DB 约束是单元测试用例的重要来源\n- **场景测试关注数据传递**：Step 间的数据传递（前一步输出 → 后一步输入）是最容易出错的地方\n- **EX 异常用例必须有对应的场景测试**：时序图中标注的每个 EX 都应该在场景测试中有体现\n- **边界值优先**：单元测试用例优先覆盖边界值（刚好合法、刚好非法），而不是随机值\n- **与 test-orchestrator 互补**：本 Skill 设计代码层面的测试（函数调用级），test-orchestrator 设计 API 层面的测试（HTTP 请求级）。二者共同覆盖\"测试金字塔\"的不同层级\n- **用例 ID 是跨阶段合约**：ID 贯穿 test-cases.md → 测试代码 → test-results.jsonl → acceptance-report.md，任何一处不一致都会导致 `openlogos verify` 报告不完整\n\n## 推荐提示词\n\n以下提示词可以直接复制给 AI 使用：\n\n- `帮我设计测试用例`\n- `帮我设计 S01 的单元测试和场景测试`\n- `帮我给所有 P0 场景设计测试用例`\n- `帮我检查 S01 的测试覆盖度`\n\n## ⚠️ 收尾步骤（强制）：更新 resource_index\n\n完成本 Skill 的所有测试用例文档产出后，**必须**将新生成的文件追加写入 `logos\u002Flogos-project.yaml` 的 `resource_index` 字段：\n\n```yaml\nresource_index:\n  # ...已有条目...\n  - path: logos\u002Fresources\u002Ftest\u002Fcore-S01-test-cases.md\n    desc: S01 \u003C场景名称>测试用例。涉及 UT-S01（单元测试）与 ST-S01（场景测试）的实现与验收时必读。\n  # 每个场景的测试用例文件均需单独一条\n```\n\n**不执行此步骤将导致 code-implementor 无法感知测试用例规格，AI 在生成测试代码时无法与用例 ID 对齐，最终 `openlogos verify` 将报告覆盖度不足。**\n\n## S39 delta 模式：触达场景的完整 UT\u002FST 与唯一测试 delta\n\n### 强制适用\n\n所有 on-touch-v1 触达场景都必须有 UT\u002FST 规格；测试类别不能 SKIP。API 编排由 test-orchestrator 另行补充，但不能替代本 Skill 的单元\u002F场景测试。\n\n### 输入事实源\n\n读取 effective requirement、feature、scenario、architecture、API、DB 与当前 change 已产 deltas。测试不得基于旧主文档平行猜测。现有测试代码可证明存量覆盖，但不能替代本次新增验收规格。\n\n### MODIFY\n\n- 测试目标存在时，在同一个 canonical target delta 中加入\u002F修改所有相关 UT\u002FST；\n- MODIFIED 测试表必须携既有 ID 全量结构，遵守 S37；新增章节可同文件 ADDED；\n- 多场景共享测试文件时合并一 task\u002F一 delta；\n- 不把“补历史测试”与“新增测试”拆成两份 delta。\n\n### CREATE\n\n目标缺失时返回完整测试规格，至少包含：\n\n1. 场景\u002F需求来源与测试边界；\n2. 真实且全局不冲突的 `UT-\u003Cscenario>-\u003Cid>` 与 `ST-\u003Cscenario>-\u003Cid>`；\n3. 主路径、异常、边界、权限\u002F并发\u002F幂等中适用项；\n4. 输入\u002Ffixture、操作、精确期望；\n5. requirement\u002Fscenario\u002FAPI\u002FDB 追溯；\n6. OpenLogos reporter 要求：实现结果写 `logos\u002Fresources\u002Fverify\u002Ftest-results.jsonl`；\n7. 覆盖度与不可由其它层替代的说明。\n\n禁止占位 ID、通配族名、TODO、只有标题无表格。真实 ID 必须在 delta 阶段定稿，供 merge 后 slice-planner 使用。\n\n### baseline-on-touch 必测矩阵\n\n- canonical target 去重与 mode；\n- effective view；\n- CREATE 类别完整度；\n- API\u002FDB 适用与 SKIP；\n- seed required\u002F安全 partial\u002Fseeded 均不阻断；未终结 journal 无法恢复时必须以 `baseline_commit_in_progress` 在任何资源读取前硬阻断；\n- adopted skip 冲突；\n- AMBIGUOUS 停在现有 plan-exit；\n- 无 JIT\u002Fverified\u002Fbaseline warning 回归；\n- task 每文件立即勾选与 plan\u002Fspec\u002Fmerge 共享判据。\n\n### 输出所有权\n\n本 Skill 返回测试表、真实 ID 清单与 reporter\u002Frunner 影响给 change-writer；change-writer 写目标唯一 delta。若新增\u002F修改 smoke 测试，还必须提示部署方案与 runner\u002Freporter\u002Fdispatcher 实现影响，不能只补规格。\n\n### 完成检查\n\n- 全部验收\u002F异常分支至少有一个真实 ID；\n- ID 与现有主规格、当前 change 其它 deltas 无冲突；\n- CREATE 文档自足；MODIFY 守恒；\n- 不使用 seed coverage\u002Fverified 作为测试通过条件。\n",{},"master","abf55fdedadaeb660f928aa7258b9ec35d4ab003","logos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fskills\u002Ftest-writer",10,"https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos","https:\u002F\u002Fgithub.com\u002Fminiidealab","2026-10-18 11:36:11",{"source":7,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add miniidealab\u002Fopenlogos --skill test-writer",{"tool":43,"command":44},"bunx","bunx skills add miniidealab\u002Fopenlogos --skill test-writer",{"tool":46,"command":47},"pnpm","pnpm dlx skills add miniidealab\u002Fopenlogos --skill test-writer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Flogos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fskills\u002Ftest-writer\u002FSKILL.md",true,[51],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"SKILL.en.md","REFERENCE","参考文档",12041,"https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Flogos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fskills\u002Ftest-writer\u002FSKILL.en.md",[58,102,108,117,125,134],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":81,"publishedAt":26},"01M6MXX45142DGRFD9ZYPT5YC9","ui-ux-pro-max","UI\u002FUX design intelligence. 67 styles, 96 palettes, 57 font pairings, 25 charts, 13 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn\u002Fui). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI\u002FUX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient. Integrations: shadcn\u002Fui MCP for component search and examples.","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fui-ux-pro-max\u002FSKILL.md",[64,67,70,73,78],{"categoryNo":65,"categoryName":66,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":68,"categoryName":69,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":71,"categoryName":72,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":79,"categoryName":80,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000033","数据分析师",[82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101],"ui ux","pro","max","ui ux pro max","ui","ux","projects","mode","card","app","tsx","fix","improve","Tailwind","Charts","Animation","design","actions","MCP","search",{"skillNo":103,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":107,"publishedAt":26},"01M6MXWY8HJV93BBR8FPNJXAMV","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Ftest-writer\u002FSKILL.md",[106],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[25,24,23],{"skillNo":109,"name":110,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":114,"publishedAt":26},"01M6MXWSAMN9AD3T8F6N099ZGY","test-orchestrator","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Ftest-orchestrator\u002FSKILL.md",[113],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[115,116,23],"orchestrator","test orchestrator",{"skillNo":118,"name":119,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":26},"01M6MXWN29FY7K9ASMFRSPWQCN","slice-planner","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fslice-planner\u002FSKILL.md",[],[123,124],"slice planner","planner",{"skillNo":126,"name":127,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":26},"01M6MXWFR1C1V66NSRTAM1FZPR","scenario-architect","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fscenario-architect\u002FSKILL.md",[],[131,132,133],"architect","scenario","scenario architect",{"skillNo":135,"name":136,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":26},"01M6MXWD6ZCGPT4FDT580S8K96","project-init","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fproject-init\u002FSKILL.md",[],[140,141,142],"project init","init","project"]