[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QJB7XNHV3VEEQF4W7FMWF6":3,"skill-same:01M6QJB7XNHV3VEEQF4W7FMWF6":93},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":36,"publishedAt":57,"linkOnly":58,"markdownContent":59,"markdownBody":60,"frontMatter":61,"refName":50,"commitSha":64,"skillDirectory":65,"forksCount":13,"repositoryHtmlUrl":66,"repositoryHomepageUrl":6,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6QJB7XNHV3VEEQF4W7FMWF6","code-change-test-designer",null,"Analyzes code changes and designs comprehensive test cases. Reads diffs, summarizes capability changes, and designs test cases covering main flows and edge cases. Should be used when the user mentions test coverage, designing tests for code changes, or analyzing diff\u002Fcommit for testing purposes. Distinguished from code-review-workflow which provides comprehensive review, this skill focuses on test case design for code changes.","ImaginerLabs\u002Fskill-manager","ImaginerLabs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F214277308?v=4","01M6QGGDPNF15RMMT1RCFDH9FN","01M6QGGDTH5BY64DQ123NR8M33",0,"MIT","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-change-test-designer\u002FSKILL.md",[17,22,25,28,33],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":34,"categoryName":35,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000032","设计师",[37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56],"designer","code change test designer","code","change","test","workflow","commit","diffs","code-review","edge","testing","coverage","diff","main","tests","flows","which","for","phase","design","2026-11-10 10:12:30",false,"---\nname: code-change-test-designer\ndescription: >-\n  Analyzes code changes and designs comprehensive test cases. Reads diffs, summarizes capability changes,\n  and designs test cases covering main flows and edge cases.\n  Should be used when the user mentions test coverage, designing tests for code changes, or analyzing\n  diff\u002Fcommit for testing purposes.\n  Distinguished from code-review-workflow which provides comprehensive review, this skill focuses on\n  test case design for code changes.\ncategory: testing\nboundary:\n  vs_code-review-workflow: \"code-review-workflow provides comprehensive 4-phase review, this skill focuses specifically on test case design for code changes\"\n---\n\n# 代码变更测试用例覆盖分析\n\n## 核心能力\n\n分析任意来源的代码变更（暂存区、工作区、指定 commit、分支对比、文件\u002F目录），识别本次修改的业务意图与能力变化，针对变更代码从**主流程链路**和**边缘情况**两个维度设计测试用例，并输出可执行的测试分析报告。\n\n## 适用场景\n\n- 功能迭代后验证测试覆盖是否充分\n- 重构代码后确认行为一致性\n- Bug 修复后防止回归\n- 新功能上线前的测试设计评审\n- 代码审查时评估测试完整性\n- 任意代码变更的测试设计\n\n---\n\n## 执行流程\n\n### Step 1：确定变更来源并读取 Diff\n\n根据用户意图或上下文，自动识别代码变更来源：\n\n| 场景                  | 检测方式                                 | 命令                            |\n| --------------------- | ---------------------------------------- | ------------------------------- |\n| **暂存区** (staged)   | 用户提到「暂存区」「staged」「准备提交」 | `git diff --staged`             |\n| **工作区** (unstaged) | 用户提到「工作区」「未暂存」「当前修改」 | `git diff`                      |\n| **指定 Commit**       | 用户提到 commit hash 或「某个提交」      | `git show \u003Ccommit>`             |\n| **分支对比**          | 用户提到「分支对比」「branch diff」      | `git diff \u003Cbranch1>..\u003Cbranch2>` |\n| **文件\u002F目录**         | 用户指定具体文件路径                     | 直接读取文件对比                |\n| **直接提供**          | 用户提供 diff 内容                       | 使用提供的 diff                 |\n\n**默认行为**：如果用户未明确指定来源，优先检查暂存区，其次检查工作区。\n\n获取变更内容后，作为后续分析的输入。\n\n### Step 2：梳理本次修改目的与能力变化\n\n精读 diff 内容，向用户清晰说明：\n\n**2.1 修改目的**：从函数命名、注释、变量名、业务逻辑推断核心意图，识别是新增功能、Bug 修复、重构优化还是配置调整。\n\n**2.2 能力变化对比**：\n\n| 维度     | 改动前                | 改动后              |\n| -------- | --------------------- | ------------------- |\n| 新增能力 | —                     | 描述新增的功能\u002F行为 |\n| 删除能力 | 描述被移除的功能\u002F行为 | —                   |\n| 修改行为 | 原有行为描述          | 新行为描述          |\n| 影响范围 | 列出受影响的模块\u002F接口 | —                   |\n\n### Step 3：识别技术栈与测试框架\n\n根据变更文件特征自动识别技术栈：\n\n| 文件特征                            | 技术栈          | 推荐测试框架                 |\n| ----------------------------------- | --------------- | ---------------------------- |\n| `*.tsx` \u002F `*.jsx` + React import    | React           | Jest + React Testing Library |\n| `*.ts` \u002F `*.js`（纯逻辑）           | TypeScript \u002F JS | Jest \u002F Vitest                |\n| `*.vue`                             | Vue             | Vitest + Vue Test Utils      |\n| `*.go`                              | Go              | `testing` 标准库 + testify   |\n| `*.py`                              | Python          | pytest                       |\n| `*.java` \u002F `*.kt`                   | Java \u002F Kotlin   | JUnit 5 + Mockito            |\n| `*.spec.*` \u002F `*.test.*`（已有测试） | 任意            | 沿用现有框架，补充缺失用例   |\n\n### Step 4：设计测试用例\n\n**4.1 主流程链路测试（Happy Path）**\n\n覆盖核心功能的正常执行路径：\n\n- 输入合法数据时，函数\u002F组件的预期输出或行为\n- 关键业务流程的端到端验证\n- 状态变更的正确性\n- 返回值\u002F副作用的准确性\n\n设计原则：每个新增\u002F修改的公共函数至少一条主流程用例，覆盖最常见的业务场景（80% 的使用频率），验证核心输出，不过度断言实现细节。\n\n**4.2 边缘情况测试（Edge Cases）**\n\n| 边缘类型         | 典型场景                                         |\n| ---------------- | ------------------------------------------------ |\n| **空值\u002F缺省**    | `null`、`undefined`、空字符串、空数组、空对象    |\n| **边界值**       | 最大值、最小值、零值、负数、超长字符串           |\n| **异常输入**     | 类型错误、格式非法、超出范围的枚举值             |\n| **并发\u002F竞态**    | 重复调用、快速连续触发、异步操作未完成时再次触发 |\n| **网络\u002FIO 异常** | 接口超时、返回错误码、网络中断、部分数据缺失     |\n| **权限\u002F状态**    | 未登录、无权限、资源不存在、状态机非法跳转       |\n| **副作用**       | 函数调用后是否产生预期外的状态变更或副作用       |\n\n**4.3 回归测试（针对 Bug 修复）**\n\n若本次变更为 Bug 修复，额外设计：\n\n- 复现原始 Bug 的测试用例（确认修复有效）\n- 验证修复不影响相关功能的回归用例\n\n### Step 5：代码层面分析与验证\n\n**5.1 可测性分析**：函数是否为纯函数（易测）或含副作用（需 Mock），是否依赖外部状态\u002F接口，是否存在难以测试的耦合点。\n\n**5.2 Mock 策略**：针对外部依赖给出具体 Mock 方案，参考 `references\u002Ftest-examples.md` 中的 Mock 示例。\n\n**5.3 断言要点**：\n\n- ✅ 断言**行为结果**（返回值、状态变更、DOM 变化）\n- ✅ 断言**副作用**（函数调用次数、调用参数）\n- ❌ 避免断言**内部实现细节**（私有变量、中间状态）\n\n**5.4 静态代码分析验证测试用例**\n\n读取变更文件的**完整源码**（不仅是 diff，而是整个函数\u002F模块的实现），逐条对照 Step 4 设计的测试用例，通过代码逻辑推导验证每条用例的预期结果是否与实现一致，给出验证结论：\n\n| 结论标记 | 含义                                                      |\n| -------- | --------------------------------------------------------- |\n| ✅ 通过  | 代码逻辑与预期一致，该用例在正确实现下应当通过            |\n| ❌ 失败  | 代码逻辑与预期矛盾，该用例会失败，说明存在 Bug 或设计偏差 |\n| ⚠️ 存疑  | 代码逻辑存在歧义、依赖运行时状态或外部 Mock，无法静态确认 |\n\n验证步骤：\n\n1. 使用 `read_file` 读取 diff 中涉及的完整源文件（不只是变更行）\n2. 逐条取出 Step 4 中的测试用例，模拟其输入，在脑中执行代码逻辑\n3. 对比执行结果与用例的预期输出，得出 ✅ \u002F ❌ \u002F ⚠️ 结论\n4. 对 ❌ 用例：说明代码哪一行\u002F哪段逻辑导致失败，并给出修复建议\n5. 对 ⚠️ 用例：说明不确定的原因（如依赖接口返回值、环境变量等）\n\n### Step 6：输出测试报告\n\n按照 `references\u002Foutput-template.md` 中的格式输出完整的测试分析报告。\n\n---\n\n## 可用资源\n\n- `references\u002Ftest-examples.md`：纯函数、异步函数、React 组件的测试代码示例（含 Mock 策略）\n- `references\u002Foutput-template.md`：测试报告的完整 Markdown 输出模板\n\n---\n\n## 注意事项\n\n- **读取完整源码**：Step 5.4 验证阶段需读取完整文件内容（非仅 diff），以确保逻辑推导准确\n- **不修改源代码**：本 Skill 仅做分析与建议，不对源代码进行任何修改\n- **聚焦变更范围**：只针对 diff 中实际变更的代码设计用例，不对未变更代码做全量分析\n- **优先级标注**：P0 为阻断性用例（必须通过），P1 为重要用例，P2 为补充用例\n- **可执行性**：所有测试用例示例代码均基于实际 diff 内容生成，确保可直接参考实现\n- **多来源支持**：灵活应对各种代码变更来源，不局限于 Git 暂存区\n","# 代码变更测试用例覆盖分析\n\n## 核心能力\n\n分析任意来源的代码变更（暂存区、工作区、指定 commit、分支对比、文件\u002F目录），识别本次修改的业务意图与能力变化，针对变更代码从**主流程链路**和**边缘情况**两个维度设计测试用例，并输出可执行的测试分析报告。\n\n## 适用场景\n\n- 功能迭代后验证测试覆盖是否充分\n- 重构代码后确认行为一致性\n- Bug 修复后防止回归\n- 新功能上线前的测试设计评审\n- 代码审查时评估测试完整性\n- 任意代码变更的测试设计\n\n---\n\n## 执行流程\n\n### Step 1：确定变更来源并读取 Diff\n\n根据用户意图或上下文，自动识别代码变更来源：\n\n| 场景                  | 检测方式                                 | 命令                            |\n| --------------------- | ---------------------------------------- | ------------------------------- |\n| **暂存区** (staged)   | 用户提到「暂存区」「staged」「准备提交」 | `git diff --staged`             |\n| **工作区** (unstaged) | 用户提到「工作区」「未暂存」「当前修改」 | `git diff`                      |\n| **指定 Commit**       | 用户提到 commit hash 或「某个提交」      | `git show \u003Ccommit>`             |\n| **分支对比**          | 用户提到「分支对比」「branch diff」      | `git diff \u003Cbranch1>..\u003Cbranch2>` |\n| **文件\u002F目录**         | 用户指定具体文件路径                     | 直接读取文件对比                |\n| **直接提供**          | 用户提供 diff 内容                       | 使用提供的 diff                 |\n\n**默认行为**：如果用户未明确指定来源，优先检查暂存区，其次检查工作区。\n\n获取变更内容后，作为后续分析的输入。\n\n### Step 2：梳理本次修改目的与能力变化\n\n精读 diff 内容，向用户清晰说明：\n\n**2.1 修改目的**：从函数命名、注释、变量名、业务逻辑推断核心意图，识别是新增功能、Bug 修复、重构优化还是配置调整。\n\n**2.2 能力变化对比**：\n\n| 维度     | 改动前                | 改动后              |\n| -------- | --------------------- | ------------------- |\n| 新增能力 | —                     | 描述新增的功能\u002F行为 |\n| 删除能力 | 描述被移除的功能\u002F行为 | —                   |\n| 修改行为 | 原有行为描述          | 新行为描述          |\n| 影响范围 | 列出受影响的模块\u002F接口 | —                   |\n\n### Step 3：识别技术栈与测试框架\n\n根据变更文件特征自动识别技术栈：\n\n| 文件特征                            | 技术栈          | 推荐测试框架                 |\n| ----------------------------------- | --------------- | ---------------------------- |\n| `*.tsx` \u002F `*.jsx` + React import    | React           | Jest + React Testing Library |\n| `*.ts` \u002F `*.js`（纯逻辑）           | TypeScript \u002F JS | Jest \u002F Vitest                |\n| `*.vue`                             | Vue             | Vitest + Vue Test Utils      |\n| `*.go`                              | Go              | `testing` 标准库 + testify   |\n| `*.py`                              | Python          | pytest                       |\n| `*.java` \u002F `*.kt`                   | Java \u002F Kotlin   | JUnit 5 + Mockito            |\n| `*.spec.*` \u002F `*.test.*`（已有测试） | 任意            | 沿用现有框架，补充缺失用例   |\n\n### Step 4：设计测试用例\n\n**4.1 主流程链路测试（Happy Path）**\n\n覆盖核心功能的正常执行路径：\n\n- 输入合法数据时，函数\u002F组件的预期输出或行为\n- 关键业务流程的端到端验证\n- 状态变更的正确性\n- 返回值\u002F副作用的准确性\n\n设计原则：每个新增\u002F修改的公共函数至少一条主流程用例，覆盖最常见的业务场景（80% 的使用频率），验证核心输出，不过度断言实现细节。\n\n**4.2 边缘情况测试（Edge Cases）**\n\n| 边缘类型         | 典型场景                                         |\n| ---------------- | ------------------------------------------------ |\n| **空值\u002F缺省**    | `null`、`undefined`、空字符串、空数组、空对象    |\n| **边界值**       | 最大值、最小值、零值、负数、超长字符串           |\n| **异常输入**     | 类型错误、格式非法、超出范围的枚举值             |\n| **并发\u002F竞态**    | 重复调用、快速连续触发、异步操作未完成时再次触发 |\n| **网络\u002FIO 异常** | 接口超时、返回错误码、网络中断、部分数据缺失     |\n| **权限\u002F状态**    | 未登录、无权限、资源不存在、状态机非法跳转       |\n| **副作用**       | 函数调用后是否产生预期外的状态变更或副作用       |\n\n**4.3 回归测试（针对 Bug 修复）**\n\n若本次变更为 Bug 修复，额外设计：\n\n- 复现原始 Bug 的测试用例（确认修复有效）\n- 验证修复不影响相关功能的回归用例\n\n### Step 5：代码层面分析与验证\n\n**5.1 可测性分析**：函数是否为纯函数（易测）或含副作用（需 Mock），是否依赖外部状态\u002F接口，是否存在难以测试的耦合点。\n\n**5.2 Mock 策略**：针对外部依赖给出具体 Mock 方案，参考 `references\u002Ftest-examples.md` 中的 Mock 示例。\n\n**5.3 断言要点**：\n\n- ✅ 断言**行为结果**（返回值、状态变更、DOM 变化）\n- ✅ 断言**副作用**（函数调用次数、调用参数）\n- ❌ 避免断言**内部实现细节**（私有变量、中间状态）\n\n**5.4 静态代码分析验证测试用例**\n\n读取变更文件的**完整源码**（不仅是 diff，而是整个函数\u002F模块的实现），逐条对照 Step 4 设计的测试用例，通过代码逻辑推导验证每条用例的预期结果是否与实现一致，给出验证结论：\n\n| 结论标记 | 含义                                                      |\n| -------- | --------------------------------------------------------- |\n| ✅ 通过  | 代码逻辑与预期一致，该用例在正确实现下应当通过            |\n| ❌ 失败  | 代码逻辑与预期矛盾，该用例会失败，说明存在 Bug 或设计偏差 |\n| ⚠️ 存疑  | 代码逻辑存在歧义、依赖运行时状态或外部 Mock，无法静态确认 |\n\n验证步骤：\n\n1. 使用 `read_file` 读取 diff 中涉及的完整源文件（不只是变更行）\n2. 逐条取出 Step 4 中的测试用例，模拟其输入，在脑中执行代码逻辑\n3. 对比执行结果与用例的预期输出，得出 ✅ \u002F ❌ \u002F ⚠️ 结论\n4. 对 ❌ 用例：说明代码哪一行\u002F哪段逻辑导致失败，并给出修复建议\n5. 对 ⚠️ 用例：说明不确定的原因（如依赖接口返回值、环境变量等）\n\n### Step 6：输出测试报告\n\n按照 `references\u002Foutput-template.md` 中的格式输出完整的测试分析报告。\n\n---\n\n## 可用资源\n\n- `references\u002Ftest-examples.md`：纯函数、异步函数、React 组件的测试代码示例（含 Mock 策略）\n- `references\u002Foutput-template.md`：测试报告的完整 Markdown 输出模板\n\n---\n\n## 注意事项\n\n- **读取完整源码**：Step 5.4 验证阶段需读取完整文件内容（非仅 diff），以确保逻辑推导准确\n- **不修改源代码**：本 Skill 仅做分析与建议，不对源代码进行任何修改\n- **聚焦变更范围**：只针对 diff 中实际变更的代码设计用例，不对未变更代码做全量分析\n- **优先级标注**：P0 为阻断性用例（必须通过），P1 为重要用例，P2 为补充用例\n- **可执行性**：所有测试用例示例代码均基于实际 diff 内容生成，确保可直接参考实现\n- **多来源支持**：灵活应对各种代码变更来源，不局限于 Git 暂存区\n",{"name":5,"boundary":62,"category":47,"description":7},{"vs_code-review-workflow":63},"code-review-workflow provides comprehensive 4-phase review, this skill focuses specifically on test case design for code changes","b9a52d8e27455bdad953d64928696d028223ea1b","skills\u002Ftesting\u002Fcode-change-test-designer","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager","https:\u002F\u002Fgithub.com\u002FImaginerLabs","2026-04-18 16:27:13",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add ImaginerLabs\u002Fskill-manager --skill code-change-test-designer",{"tool":75,"command":76},"bunx","bunx skills add ImaginerLabs\u002Fskill-manager --skill code-change-test-designer",{"tool":78,"command":79},"pnpm","pnpm dlx skills add ImaginerLabs\u002Fskill-manager --skill code-change-test-designer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-change-test-designer\u002FSKILL.md",true,[83,89],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Foutput-template.md","REFERENCE","参考文档",3446,"https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-change-test-designer\u002Freferences\u002Foutput-template.md",{"path":90,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Ftest-examples.md",6069,"https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-change-test-designer\u002Freferences\u002Ftest-examples.md",[94,122,143,170,195,217],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":104,"publishedAt":57},"01M6QJCB2SD5KHC41ZDQC0GA1T","meeting-minutes","Generate concise, actionable meeting minutes for internal meetings. Includes metadata, attendees, agenda, decisions, action items (owner + due date), and follow-up steps.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fmeeting-minutes\u002FSKILL.md",[100,101],{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":102,"categoryName":103,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000034","行政与办公人员",[105,106,107,108,109,110,111,112,113,114,96,50,115,116,117,118,119,120,121,54],"meeting minutes","meeting","minutes","writing","github","copilot","generate","decisions","meetings","up","agenda","actionable","concise","follow-up","tree","true","action",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":57},"01M6QJC71RRGTGNNFEHJG6S20G","documentation-writer","Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[],[129,130,131,108,109,110,132,133,134,135,136,137,50,138,139,140,141,119,120,142],"documentation","documentation writer","writer","https","quality","technical","technical writer","expert","documentation expert","structure","authoring","software","principles","high",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":156,"publishedAt":57},"01M6QJC0V3C7C4R9768J1AJYWY","doc-coauthoring","Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdoc-coauthoring\u002FSKILL.md",[149,152,153],{"categoryNo":150,"categoryName":151,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":154,"categoryName":155,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000036","内容创作者",[157,158,108,42,159,129,160,161,162,163,164,165,50,166,167,139,168,169,119,54],"doc coauthoring","doc","official","tasks","decision","write","context","proposals","guide","refine","iteration","trigger","co",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":182,"publishedAt":57},"01M6QJBJ0YPVEWGEXZH3PJRRTT","code-review-workflow","Executes comprehensive 4-phase code review: basic review, quality check, bundle analysis, and test coverage. Should be used when the user mentions comprehensive code review, checking code quality, or reviewing staged changes with multi-phase analysis. This is the comprehensive review workflow, distinct from focused skills like frontend-code-review, staged-code-review, or code-change-test-designer.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-review-workflow\u002FSKILL.md",[176,179,180,181],{"categoryNo":177,"categoryName":178,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},[183,184,42,39,185,47,186,41,40,187,45,188,189,48,190,191,192,193,194,55],"code review","review","code review workflow","frontend","code quality","analysis","check","quality check","basic","multi","comprehensive code review","with",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":202,"publishedAt":57},"01M6QJB195WD7DCJWDMKWKB29S","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fmeta-skills\u002Fskill-creator\u002FSKILL.md",[201],{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},[203,204,205,206,159,207,208,209,210,211,188,212,213,214,50,215,216,119,54,197],"skill creator","creator","performance","run evals","variance analysis","create","run","benchmark","Meta","improve","edit","evals","optimize","existing skill",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":224,"publishedAt":57},"01M6QJAKN1XMYCZERA9CGBQPNY","enhanced-skill-creator","Enhances and optimizes existing Skills. Analyzes Skills for trigger accuracy, execution effectiveness, and coverage completeness, then provides optimization recommendations. Should be used when the user mentions optimizing, improving, refactoring, or enhancing Skills. Distinguished from creating new skills — this skill focuses on improving existing ones.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fmeta-skills\u002Fenhanced-skill-creator\u002FSKILL.md",[223],{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},[203,204,225,226,227,211,228,229,230,48,231,168,232,54,233,234],"enhanced skill creator","optimization recommendations","Optimization","execution","refactoring","user","recommendations","completeness","accuracy","Existing"]