[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MXVDHTDPJ9V2DR2B03SDPD":3,"skill-same:01M6MXVDHTDPJ9V2DR2B03SDPD":61},{"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":27,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":32,"frontMatter":33,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":40,"install":41,"resources":54},"01M6MXVDHTDPJ9V2DR2B03SDPD","code-implementor",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\u002Fskills\u002Fcode-implementor\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[28,29],"code","code implementor","2026-11-10 10:12:30",false,"# Skill: Code Implementor\n\n> 基于完整规格链（时序图、API YAML、DB DDL、测试用例规格）生成业务代码和测试代码。确保代码与规格严格一致，嵌入 OpenLogos reporter，按场景分批交付闭环产物。\n\n## 触发条件\n\n- 用户要求实现代码、生成代码或编写代码\n- 用户提到 \"Phase 3 Step 5\"、\"代码生成\"、\"帮我实现 S01\"\n- 测试用例设计已完成（`logos\u002Fresources\u002Ftest\u002F` 非空），需要开始编码\n- 用户指定某个场景编号（如 S01）需要实现\n\n## 前置依赖\n\n- `logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F2-scenario-implementation\u002F` 中包含场景时序图（**必需**）\n- `logos\u002Fresources\u002Fapi\u002F` 中包含 API 规格（有则读取）\n- `logos\u002Fresources\u002Fdatabase\u002F` 中包含 DB DDL（有则读取）\n- `logos\u002Fresources\u002Ftest\u002F` 中包含测试用例规格（**必需**）\n- `logos\u002Flogos-project.yaml` 中包含 `tech_stack`（**必需**）\n\n如果时序图或测试用例目录为空，提示用户先完成 Phase 3 Step 1（scenario-architect）和 Step 4a（test-writer）。\n\n## 核心能力\n\n1. 加载完整规格上下文，建立实现基准\n2. 规划分批策略，按场景或模块拆分大任务\n3. 生成与 API YAML 严格一致的业务代码（路由、状态码、错误码、字段）\n4. 生成与 DB DDL 严格对齐的数据访问代码（表名、列名、类型、约束）\n5. 生成与 test-cases.md 中 ID 完全对齐的测试代码\n6. 在测试代码中嵌入 OpenLogos reporter（输出到 `test-results.jsonl`）\n7. 每批完成后执行自检，确保规格一致性\n\n## 与 test-writer 和 code-reviewer 的关系\n\n本 Skill 处于三者链条的中间位置：\n\n- **test-writer**（Step 4a）：设计测试用例**规格文档**（Markdown），定义 UT\u002FST ID——是\"出卷人\"\n- **code-implementor**（Step 5，本 Skill）：将所有规格转化为**可运行的业务代码和测试代码**——是\"答卷人\"\n- **code-reviewer**（Step 5 之后）：拿着规格**审计已生成的业务代码**，输出审查报告——是\"阅卷人\"\n\ntest-writer 不写代码；code-implementor 不设计用例；code-reviewer 不修改代码。三者形成 **设计 → 执行 → 审查** 闭环。\n\n## 执行步骤\n\n### Step 1: 加载规格上下文\n\n**在写任何一行代码之前**，必须读取以下文档建立完整上下文：\n\n| 文档 | 路径 | 用途 |\n|------|------|------|\n| 技术架构 | `prd\u002F3-technical-plan\u002F1-architecture\u002F` | 整体结构、框架、设计模式 |\n| 场景时序图 | `prd\u002F3-technical-plan\u002F2-scenario-implementation\u002F` | 实现蓝图——Step 序列即代码调用链 |\n| API 规格 | `logos\u002Fresources\u002Fapi\u002F*.yaml` | 端点契约——路由、方法、状态码、字段定义 |\n| DB DDL | `logos\u002Fresources\u002Fdatabase\u002F*.sql` | 数据层契约——表结构、约束、索引 |\n| 测试用例规格 | `logos\u002Fresources\u002Ftest\u002F*-test-cases.md` | 验证目标——UT\u002FST ID、预期输入输出 |\n| 编排测试 | `logos\u002Fresources\u002Fscenario\u002F*.json` | 端到端验证目标（API 项目） |\n| 项目配置 | `logos\u002Flogos-project.yaml` | `tech_stack`、`external_dependencies` |\n| 源码位置 | `logos\u002Flogos.config.json` → `sourceRoots` | 业务代码和测试代码的输出根目录 |\n\n读取完成后，确认以下信息：\n- 本次实现涉及哪些场景（S01、S02...）\n- 涉及哪些 API 端点和 DB 表\n- 对应的 UT\u002FST 用例总数\n- 技术栈确认（语言、框架、测试框架）\n- 源码输出目录确认（读取 `sourceRoots.src` 和 `sourceRoots.test`，若不存在则默认 `src\u002F` 和 `test\u002F`）\n- verify 预跑配置确认：`verify.pre_run_command`、`verify.regression_command` 或 `verify.incremental_command` 至少存在一个；若缺失则需要在实现前补齐或明确诊断\n\n### Step 2: 规划分批策略\n\n> ⚠️ **适用范围（必读）**：本 Step 的「六维打分 + 分批 \u002F 切片判定」**仅适用于 initial 阶段**——首轮从 0 到 1 开发，没有变更提案、没有 `tasks.md`，需由实现者自行按场景 \u002F 子模块分批。\n>\n> **launched 变更下本 Step 不适用**：切片数量已由 **`slice-planner`** 在 **merge 之后**的 `slice` 段（`ready-to-implement`）用**六维打分 + 垂直\u002F横向判别器 + 删后续证伪门**写进 `tasks.md` 的 `[code]` section（每个未勾行 = 一片，是唯一事实源；见 `skills\u002Fslice-planner\u002FSKILL.md`）。code-implementor 在 launched 下**不得重新打分、不得自行分批**，必须**逐行消费 `[code]` 切片**——做哪一片、做几片，一律以 `[code]` 为准（具体执行见下方「Step 2 补充」的激活门）。\n\n**（以下仅 initial）只有大任务才拆批；大任务 = 切片评分 8 分及以上。每批必须闭环。**\n\n在规划分批前，先按 6 个维度打分（每项 0\u002F1\u002F2，总分 0-12）：\n\n| 维度 | 0 分 | 1 分 | 2 分 |\n|---|---|---|---|\n| 影响范围 | 1 个文件或局部函数 | 2-5 个相关文件 | 跨模块 \u002F 跨服务 \u002F 跨端 |\n| 行为复杂度 | 单一路径 bugfix | 2-3 个分支 | 多场景 \u002F 状态机 \u002F 异步流程 |\n| 契约变化 | 无 | CLI\u002FAPI 输出小改 | API\u002FDB\u002Fflow\u002F兼容契约变更 |\n| 测试规模 | 1-3 个用例 | 4-8 个用例 | 9+ 个用例或多类测试矩阵 |\n| 风险等级 | 易回滚 | 有兼容性风险 | 涉数据、安全、部署、迁移 |\n| 不确定性 | 原因明确 | 1 个待验证假设 | 多个未知点 \u002F 需要探索 |\n\n判定规则：\n- **0-7 分：不是大任务，必须单批 \u002F 单切片实现**，不得把测试、reporter、golden baseline 拆成独立批次。\n- **8 分及以上：定义为大任务，需要拆批 \u002F 切片实现**。\n- **无法垂直闭环时仍单批**：即使达到 8 分，如果拆不出独立可验证的垂直闭环，保留单批并说明原因。\n\n1. **拆分维度**：按场景（S01、S02）或按模块（auth、projects）拆分\n2. **批前声明**：每批开始前，列出本批覆盖的 UT\u002FST case ID 清单，确保与 `logos\u002Fresources\u002Ftest\u002F*.md` 可追溯\n3. **闭环要求**：每批必须同时交付三要素——业务代码 + 测试代码 + reporter\n4. **不得延迟测试**：不允许\"先写完所有业务代码，最后统一补测试\"\n\n输出格式示例：\n\n```markdown\n## 本批次范围\n\n- 场景：S01（用户注册）\n- 端点：POST \u002Fapi\u002Fauth\u002Fregister, POST \u002Fapi\u002Fauth\u002Fverify-email\n- DB 表：users, profiles\n- 覆盖用例：UT-S01-01 ~ UT-S01-08, ST-S01-01 ~ ST-S01-03\n```\n\n### Step 2 补充：切片循环驱动模型（change-flow-redesign）\n\n> 自 change-flow-redesign 起，launched `implement` 默认以**切片循环**推进（场景 S31）。`tasks.md` 的 `[code]` section 每个未勾行 = 一个切片，由宿主（如 RunLogos driver）逐片驱动；Step 2 的\"分批策略\"在 launched 下即对齐这些切片。\n\n> ? **激活前提（最高优先级，必读）**：下列「每轮只实现一片」的纪律，**仅当 `openlogos next` 实际返回了 `next_node.slice`（即宿主 \u002F driver 正逐片注入「只做这一片」的上下文）时才适用**。\n>\n> **若你并未被逐片注入**——例如手动执行、没有 driver 驱动循环、或所用 `openlogos` CLI 不支持切片循环（\u003C 0.11，`next` 不输出 `next_node.slice` \u002F `slice_state`）——则**必须在本次实现里把整个 `[code]` section 的所有未勾切片一次性全部实现完**（每片仍各自闭环：业务代码 + 该片 UT\u002FST + reporter），全部完成后再交 `verify`。\n>\n> **严禁**在没有逐片注入的情况下，自行把单个 `[code]` 行当作「第一个切片」、实现完就停下等下一轮。**为什么**：切片只 scope `code` 的上下文注入、**不 scope verify**（verify 永远全量回归）；只做完一片就跑全量 verify 必然飘红（其余切片的测试尚不存在 \u002F 不过），循环无法出环，会直接死锁在 `verify-failed`。\n\n切片循环下的实现纪律（**仅在上述激活前提满足、即宿主正逐片注入时适用**）：\n\n1. **每轮只实现一片**：宿主读 `openlogos next` 的 `next_node.slice` \u002F `slice_state.current` 注入\"只做这一片 + 该片相关 spec\u002F测试\"的上下文。**逐片注入正是为规避\"一次塞太多导致 AI 失败\"**。\n2. **每片自闭环**：该片的业务代码 + 该片 UT\u002FST 测试 + reporter 同批交付（与既有 Step 2「闭环要求」一致），切片 ID 来自 `[code]` 行标注的 `UT-Sxx-..`\u002F`ST-Sxx-..`。\n3. **verify 跑全量回归，不只跑本片**：`openlogos verify` 始终全量执行——切片只 scope `code` 的上下文注入，**不 scope verify**；这样后做切片若打断先做切片，全量 verify 会飘红、loop 不出环，从模型层杜绝\"局部绿全局红\"。\n4. **绿后才勾该片**：该片相关测试（及全量回归）满足后，由宿主把 `tasks.md` `[code]` 该行勾上——OpenLogos 只派生、不代勾。\n5. **收敛 = 全部切片勾选 ∧ 末轮全量测试绿**（`code_slices_green`）；达 `max_iters`（默认 30）仍未达成升级 `gate:implement:loop-exhausted`（`skippable:false`，默认不放行未完成大功能）。\n6. **修哪片由 verify 失败输出决定**：`next_node.slice` 提示的是\"下一个**未建**切片\"，不是\"该修哪片\"；回归飘红时具体修复目标由全量 verify 失败信息判断，归宿主\u002F实现者，引擎不代判。\n\n> 非 launched（initial 单模块默认 \u002F initial 多模块）不默认激活切片循环，沿用既有\"按场景\u002F子模块分批\"策略。\n\n### Step 3: 生成业务代码\n\n按时序图 Step 序列逐步实现业务逻辑，**严格遵守以下规格一致性规则**：\n\n#### API 一致性（必须遵守）\n\n| 规则 | 说明 |\n|------|------|\n| 路由路径 | 代码中的路由必须与 API YAML 的 `paths` 完全一致 |\n| HTTP 方法 | GET\u002FPOST\u002FPUT\u002FDELETE 必须匹配 |\n| 请求体字段 | 代码必须读取 YAML `requestBody.schema` 中定义的所有 `required` 字段 |\n| 字段验证 | `type`、`format`（email\u002Fuuid）、`minLength` 等约束必须在代码中实现验证 |\n| 响应字段 | 返回的 JSON 字段名和类型必须与 YAML `responses.schema` 一致 |\n| HTTP 状态码 | 正常和错误情况的状态码必须与 YAML 定义一致（不能把 201 写成 200） |\n| 错误响应格式 | 必须遵循统一的 `{ code, message, details? }` 格式 |\n\n#### DB 一致性（必须遵守）\n\n| 规则 | 说明 |\n|------|------|\n| 表名和列名 | 代码中引用的表名、列名必须与 DDL 一致（无拼写错误、大小写差异） |\n| 字段类型 | 传入的值类型必须与 DDL 定义匹配（如金额字段用分而非元） |\n| 约束遵守 | NOT NULL 字段必须有值；UNIQUE 字段必须处理冲突；CHECK 约束的枚举值需有对应常量 |\n| 事务使用 | 多表写操作必须包裹在事务中 |\n| 参数化查询 | 禁止字符串拼接 SQL，必须使用参数化查询 |\n\n#### 异常处理（必须遵守）\n\n- 时序图中的每个 EX 异常用例必须在代码中有对应的错误处理分支\n- 外部服务调用（DB、第三方 API）必须有超时和错误处理\n- 不允许空 catch 块（静默吞异常）\n- 多步写入失败时需要有补偿\u002F回滚机制\n\n### Step 4: 生成测试代码\n\n#### 测试 ID 契约\n\n测试代码中的用例 ID 必须与 `test-cases.md` 中定义的 **完全一致**：\n\n- `UT-S01-01` 在测试代码中必须原封不动使用，不允许改名、缩写或重排序\n- 这些 ID 是跨阶段契约：test-cases.md → 测试代码 → test-results.jsonl → acceptance-report.md\n\n#### OpenLogos Reporter 嵌入（强制前置）\n\n> ⚠️ **Reporter 是第零步，不是最后一步。** 在写任何测试用例代码之前，必须先创建共享 reporter 工具文件。没有 reporter，`openlogos verify` 无法读取结果，Gate 3.5 永远无法通过。\n\n**第一步：创建共享 reporter 文件**\n\n在测试目录下创建共享 reporter 工具文件（根据 `tech_stack` 选择语言），所有测试文件统一从这里 import，不要在每个测试文件里重复内联：\n\n```\n\u003CsourceRoots.test>\u002F\n└── helpers\u002F\n    └── reporter.ts   ← 先建这个，再写测试用例\n```\n\nreporter 模板见 `logos\u002Fspec\u002Ftest-results.md`。核心要求：\n\n- 输出路径：`logos\u002Fresources\u002Fverify\u002Ftest-results.jsonl`\n- 格式：JSONL（每行一个 JSON 对象）\n- 每个用例输出：`{ \"id\": \"UT-S01-01\", \"status\": \"pass\"|\"fail\"|\"skip\", ... }`\n- 首次运行 truncate 文件，后续 append\n- 写入前确保 `logos\u002Fresources\u002Fverify\u002F` 目录存在\n\n**第二步：在每个测试文件顶部 import reporter**\n\n```typescript\nimport { reportResult } from '.\u002Fhelpers\u002Freporter';\n```\n\n**第三步：每个测试用例用 try\u002Fcatch 包裹并调用 reportResult**\n\n```typescript\nit('UT-S01-01: ...', () => {\n  const start = Date.now();\n  try {\n    \u002F\u002F 测试逻辑\n    reportResult('UT-S01-01', 'pass', undefined, Date.now() - start);\n  } catch (e) {\n    reportResult('UT-S01-01', 'fail', String(e), Date.now() - start);\n    throw e;\n  }\n});\n```\n\nPlaywright E2E 测试使用 `test.afterEach` + fixture 捕获结果，参见 `logos\u002Fspec\u002Ftest-results.md` 中的 Playwright 模板。\n\n#### Smoke Runner \u002F Reporter 闭环（强制）\n\n如果本批实现新增或修改了 `logos\u002Fresources\u002Ftest\u002Fsmoke\u002F*.md`，或当前活跃提案的 `deltas\u002Ftest\u002Fsmoke\u002F` 中存在新增\u002F修改的 `SMOKE-*` 用例，必须在同一批代码中同步交付 smoke 可执行验收：\n\n1. 提取本提案新增或修改的 `SMOKE-*` 用例 ID，逐项列入本批覆盖清单。\n2. 实现或更新 `scripts\u002Fsmoke-*.sh`、`scripts\u002Fsmoke-*.js` 或等效 smoke runner；runner 必须执行真实检查，不能只伪造 pass 记录。\n3. smoke runner 必须将每个新增 `SMOKE-*` 的执行结果写入 `logos\u002Fresources\u002Fverify\u002Fsmoke-results.jsonl`，或写入 `logos.config.json.smoke.result_path` 指定路径。\n4. 确保 `logos.config.json.smoke.command` 能执行新增 runner；推荐使用统一 `scripts\u002Frun-smoke.js` smoke dispatcher 自动发现并顺序运行 `scripts\u002Fsmoke-*`。\n5. 完成后运行 smoke runner、`openlogos smoke --format json`，或等效 smoke 覆盖预检；如出现 `smoke_runner_missing`、`smoke_reporter_missing`、`smoke_cases_uncovered`，不得标记 `[code]` 任务完成。\n\n#### 测试代码结构\n\n- 单元测试：每个 UT 用例对应一个独立的测试函数\n- 场景测试：每个 ST 用例对应一个端到端流程测试\n- 测试数据：每个测试准备独立的测试数据，测试后清理，确保幂等性\n\n### Step 5: 自检\n\n每批代码完成后，执行以下自检（相当于 code-reviewer 的前置轻量版本）：\n\n- [ ] API 路由路径和 HTTP 方法与 YAML 一致\n- [ ] HTTP 状态码（正常 + 异常）与 YAML 一致\n- [ ] 错误响应格式遵循 `{ code, message }` 规范\n- [ ] DB 操作的表名、列名与 DDL 一致\n- [ ] 多表写操作已使用事务\n- [ ] 批前声明的所有 UT\u002FST ID 在测试代码中都存在\n- [ ] **共享 reporter 文件已创建**（`\u003Ctest>\u002Fhelpers\u002Freporter.ts` 或等效路径）\n- [ ] **每个测试文件都已 import reporter**，无遗漏\n- [ ] **每个测试用例都有 try\u002Fcatch + reportResult 调用**，无遗漏\n- [ ] 运行测试后 `logos\u002Fresources\u002Fverify\u002Ftest-results.jsonl` 已生成且非空\n- [ ] 若本批新增或修改 `SMOKE-*`：smoke runner \u002F reporter \u002F dispatcher 已实现，`smoke-results.jsonl` 覆盖新增 ID，且 smoke 覆盖预检无 `smoke_runner_missing` \u002F `smoke_reporter_missing` \u002F `smoke_cases_uncovered`\n- [ ] 无硬编码敏感信息（密码、密钥、测试数据）\n\n如果发现不一致，**立即修正后再交付**，不要等到 code-reviewer 阶段。\n\n### Step 6: 引导下一步\n\n每批完成后：\n\n1. **提示运行测试**：告诉用户运行测试命令（如 `npm test`、`pytest`）\n2. **提示检查结果**：确认 `logos\u002Fresources\u002Fverify\u002Ftest-results.jsonl` 已生成\n3. **所有批次完成后**：引导用户运行 `openlogos verify` 执行 Gate 3.5 验收\n4. **更新 sourceRoots**：如果实际使用的源码目录与 `logos.config.json` 中的 `sourceRoots` 不同，更新配置文件以反映实际路径。例如，如果业务代码放在 `app\u002F` 而非默认的 `src\u002F`，将 `sourceRoots.src` 更新为 `[\"app\"]`\n5. **自动写入 `verify.pre_run_command`**：检查 `logos.config.json` 是否已有 `verify.pre_run_command`、`verify.regression_command` 或 `verify.incremental_command` 字段。若没有，根据 `logos-project.yaml` 的 `tech_stack` 推断默认命令并写入，确保后续 `openlogos verify` 能自动跑全量测试：\n\n   | tech_stack 关键词 | 写入命令 |\n   |---|---|\n   | vitest | `npx vitest run` |\n   | jest | `npx jest` |\n   | pytest | `pytest` |\n   | go test | `go test .\u002F...` |\n   | cargo test | `cargo test` |\n   | 无法推断 | 提示用户手动在 `logos.config.json` 的 `verify.pre_run_command` 字段填写测试命令 |\n\n   **为什么必须配置**：`openlogos-reporter` 每次运行测试时会清空 `test-results.jsonl`，若只跑部分场景的测试，JSONL 将缺少其他场景的结果，导致 `openlogos verify` 覆盖率不足而失败。配置预跑命令后，`openlogos verify` 会在读取 JSONL 前自动执行全量测试，确保覆盖率完整。若项目明确使用两阶段模型，也可写入 `verify.regression_command` 与 `verify.incremental_command`，并保证阶段结果不会互相覆盖。\n\n6. **写入实现清单**：在 `logos\u002Fresources\u002Fimplementation\u002F` 目录下创建实现清单文件（如 `implementation-manifest.md`），记录本次实现覆盖的场景、端点、用例 ID 等信息，标记 Phase 3-4 完成\n\n如果用户希望审查代码质量，引导使用 `code-reviewer` Skill。\n\n## 输出规范\n\n- **业务代码**：输出到 `sourceRoots.src` 指定的目录（默认 `src\u002F`，以 `logos.config.json` 配置为准）\n- **测试代码**：输出到 `sourceRoots.test` 指定的目录（默认 `test\u002F`，以 `logos.config.json` 配置为准）\n- **Reporter**：嵌入测试代码中（非独立文件）\n- **JSONL 结果**：`logos\u002Fresources\u002Fverify\u002Ftest-results.jsonl`\n- **实现清单**：`logos\u002Fresources\u002Fimplementation\u002Fimplementation-manifest.md`（所有批次完成后创建）\n\n## 实践经验\n\n- **规格一致性是第一优先级**：代码必须与 API YAML \u002F DB DDL 严格对齐——大部分生产 Bug 来自代码与规格的细微不一致\n- **先写业务代码后写测试是允许的**，但必须在同一批次内完成，不允许拆到不同批次\n- **Reporter 不要忘记**：这是 `openlogos verify` 能自动验收的关键——没有 reporter 就没有自动化验收\n- **不要发明用例 ID**：测试代码中的 ID 必须来自 test-cases.md，不允许自行新增或改名\n- **不要跳过异常处理**：时序图中标注的每个 EX 用例必须在代码中有对应分支\n- **自检比返工便宜**：Step 5 的 5 分钟自检可以避免 code-reviewer 阶段 30 分钟的返工\n- **分批粒度**：单批次不宜过大（一个场景是合适的粒度），也不宜过小（一个 API 端点太碎）\n\n## 推荐提示词\n\n以下提示词可以直接复制给 AI 使用：\n\n- `帮我实现 S01 的代码`\n- `基于规格文档帮我生成 S01 的业务代码和测试代码`\n- `执行 Phase 3 Step 4，按场景分批实现`\n- `帮我实现 S01，确保与 API YAML 和 DB DDL 一致`\n- `Please execute Phase 3 Step 4 for S01. Deliver business code + test code + OpenLogos reporter in each batch.`\n",{},"master","abf55fdedadaeb660f928aa7258b9ec35d4ab003","skills\u002Fcode-implementor",9,"https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos","https:\u002F\u002Fgithub.com\u002Fminiidealab","2026-10-18 11:36:11",{"source":7,"skillName":5,"commands":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add miniidealab\u002Fopenlogos --skill code-implementor",{"tool":47,"command":48},"bunx","bunx skills add miniidealab\u002Fopenlogos --skill code-implementor",{"tool":50,"command":51},"pnpm","pnpm dlx skills add miniidealab\u002Fopenlogos --skill code-implementor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fcode-implementor\u002FSKILL.md",true,[55],{"path":56,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":60},"SKILL.en.md","REFERENCE","参考文档",11147,"https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fcode-implementor\u002FSKILL.en.md",[62,104,114,123,131,140],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":83,"publishedAt":30},"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",[68,71,74,77,80],{"categoryNo":69,"categoryName":70,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":72,"categoryName":73,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":75,"categoryName":76,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":78,"categoryName":79,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师",{"categoryNo":81,"categoryName":82,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000033","数据分析师",[84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103],"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":105,"name":106,"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":107,"categories":108,"keywords":110,"publishedAt":30},"01M6MXWY8HJV93BBR8FPNJXAMV","test-writer","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Ftest-writer\u002FSKILL.md",[109],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[111,112,113],"writer","test writer","test",{"skillNo":115,"name":116,"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":117,"categories":118,"keywords":120,"publishedAt":30},"01M6MXWSAMN9AD3T8F6N099ZGY","test-orchestrator","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Ftest-orchestrator\u002FSKILL.md",[119],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[121,122,113],"orchestrator","test orchestrator",{"skillNo":124,"name":125,"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":126,"categories":127,"keywords":128,"publishedAt":30},"01M6MXWN29FY7K9ASMFRSPWQCN","slice-planner","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fslice-planner\u002FSKILL.md",[],[129,130],"slice planner","planner",{"skillNo":132,"name":133,"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":134,"categories":135,"keywords":136,"publishedAt":30},"01M6MXWFR1C1V66NSRTAM1FZPR","scenario-architect","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fscenario-architect\u002FSKILL.md",[],[137,138,139],"architect","scenario","scenario architect",{"skillNo":141,"name":142,"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":143,"categories":144,"keywords":145,"publishedAt":30},"01M6MXWD6ZCGPT4FDT580S8K96","project-init","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fproject-init\u002FSKILL.md",[],[146,147,148],"project init","init","project"]