What makes qa-test-case-design notable?

1.2K downloads. Trust evidence available

How should qa-test-case-design be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

qa-test-case-design

当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability. Skill: qa-test-case-design Owner: kokxi Summary: 当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability. Tags: la

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.2k

Updated

Oct 11, 2026

Version

1.8.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.2K downloadsadoption · observed Oct 11, 2026
Latest release: 1.8.0release · observed Sep 29, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s170jw3s1atcj5jwhqb4r7v7eh8912kp:qa-test-case-design

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-test-case-design/snapshot"

Documentation

CLAWHUB

147,357 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: qa-test-case-design
description: >-
  当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排，产出全项目统一的 9 列标准格式用例。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。
  触发场景：设计测试用例、用例评审、用例覆盖、测试用例设计、用例模板、用例规范、用例格式、需要编写或规范测试用例时。 Use when the user asks about: designing structured test cases with P0-P3 prioritization, the canonical 9-column format, coverage strategy, and requirement traceability.
license: MIT
allowed-tools: Read Grep Glob
metadata:
  display-name: "Test Case Design"
  version: "1.8.0"
  when-to-use: "用户说\"设计测试用例\"、\"用例评审\"、\"用例覆盖\"、\"测试用例设计\"、\"用例模板\"、\"用例规范\"、\"用例格式\"、需要测试用例结构指导、需要编写或规范测试用例时"
  related-skills: "{\"upstream\":[\"qa-req-deconstruction\",\"qa-boundary-deep-dive\",\"qa-scenario-tree\"],\"downstream\":[\"qa-test-skills\",\"qa-expert-review\",\"qa-regression-testing\"]}"
  references: "[\"assets/case-table.md\",\"references/output-template-full.md\",\"references/design-methods.md\",\"references/coverage-and-quality.md\",\"references/review-standards.md\"]"
  input-format: "{\"required\":[{\"name\":\"需求描述\",\"type\":\"string\",\"description\":\"功能需求的详细说明\"}],\"optional\":[{\"name\":\"场景分析\",\"type\":\"object\",\"description\":\"来自qa-scenario-tree的场景树\"},{\"name\":\"边界条件\",\"type\":\"object\",\"description\":\"来自qa-boundary-deep-dive的边界分析结果\"},{\"name\":\"业务背景\",\"type\":\"string\",\"description\":\"业务目标和用户角色\"}]}"
  output-format: "{\"traceability\":[\"每个用例带唯一ID：TC_{模块缩写}_{功能缩写}_{三位序号}（如 TC_API_LOGIN_001）——不使用场景后缀\",\"关联需求ID：REQ-{需求模块缩写}-{序号}\",\"关联场景ID：SC-{场景模块缩写}-{序号}\"],\"structure\":[{\"test_case_table\":\"测试用例表：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）——全项目唯一标准，见 references/output-template-full.md\"},\"用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\",\"测试步骤：协议/接口/规则/计算类必填（含 method+path+关键参数）；UI/业务流程类可留空并标注「由执行人按实际系统补充」\",\"子功能并入「功能模块」用 模块/子功能 表示，不单设列；无「实际结果」列——那是 qa-execution-observation 的执行记录字段\",\"覆盖率：标注口径（基于现有需求/上游分析产出），禁止\\\"全覆盖/100%\\\"绝对化表述；缺失模块标注\\\"未覆盖+原因\\\"\"]}"
  error-recovery-guidance: "{\"on_failure\":\"用例设计遗漏维度时回退到边界分析和场景树补充\",\"retry_behavior\":\"补充上游后重新设计用例\"}"
  categories: "[\"Development\",\"Testing\"]"
  depth-requirement: "{\"reference_value\":\"见 references/output-template-full.md；用例总数不低于需求点的 3 倍\",\"minimum\":\"9 列齐全、编号唯一且合格式、P0-P3 占比达标、覆盖率标注口径\"}"
---

> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

# 测试用例设计专项

## 核心原则

测试用例设计的核心——明确"测什么"，而非"怎么测"。

> **重要限制**：禁止读取代码。测试用例必须基于需求文档，不得读取代码实现。
> 确保验证"系统应该做什么"，而非"系统如何实现"。

> **上游未完成就不要开始**：没有充分输入（需求解构 / 场景树 / 边界清单）时，
> 生成的用例一定是泛泛的。先补上游，再做本步。

## 1. 九列标准格式（本技能是全项目格式定义者）

| # | 列名 | 必填 | 要点 |
|---|------|------|------|
| 1 | 用例编号 | ✅ | `TC_{模块缩写}_{功能缩写}_{三位序号}`，同批不重号 |
| 2 | 测试类型 | ✅ | 按所属技能维度：功能/安全/异常/性能/契约/兼容性 |
| 3 | 功能模块 | ✅ | 必要时 `模块/子功能` 两级（子功能并入本列） |
| 4 | 测试标题 | ✅ | 动词开头，点明验证点 |
| 5 | 用例级别 | ✅ | P0/P1/P2/P3，占比见下 |
| 6 | 预置条件 | ✅ | 环境+数据+权限+状态，具体到可复现 |
| 7 | 测试步骤 | ⚠️ | **协议/规则/计算类必填**；UI/业务流程类可留空 |
| 8 | 预期结果 | ✅ | 可量化：状态码 / 返回结构 / 数据状态 / 副作用 |
| 9 | 风险等级 | ✅ | 高（资损/越权/数据错误

_meta.json

{
  "ownerId": "kn71y9b23csfx0ykgm55d5m9x5891zt8",
  "slug": "qa-test-case-design",
  "version": "1.8.0",
  "publishedAt": 1790655443725
}

references/coverage-and-quality.md

# 测试覆盖策略与质量标准

## 覆盖维度

```
测试覆盖：
├─ 功能覆盖
│   ├─ 主流程覆盖：核心业务流程是否完整测试
│   ├─ 分支流程覆盖：各种条件分支路径是否覆盖
│   ├─ 异常场景覆盖：错误输入、异常操作是否测试
│   ├─ 边界条件覆盖：输入范围边界、数量边界是否测试
│   ├─ 退出流程覆盖：退出登录、注销、超时退出等场景
│   └─ 状态转换覆盖：系统状态变化是否测试
│
├─ 数据覆盖
│   ├─ 有效数据覆盖：正常数据是否测试
│   ├─ 无效数据覆盖：异常数据是否测试
│   ├─ 边界数据覆盖：边界值数据是否测试
│   ├─ 特殊数据覆盖：特殊字符、超长数据是否测试
│   ├─ 格式校验覆盖：邮箱、手机号、身份证等格式验证
│   └─ 注入测试覆盖：SQL注入、XSS攻击等安全测试
│
├─ 字段级验证覆盖（每个表单字段必须测试）
│   ├─ 长度边界：1位、最大长度、最大长度+1
│   ├─ 格式校验：正则表达式验证（邮箱、手机号、身份证等）
│   ├─ 注入测试：SQL注入、XSS攻击、命令注入
│   ├─ 特殊字符：空格、特殊符号、Unicode字符
│   ├─ 空值处理：必填字段为空、选填字段为空
│   └─ 默认值：字段默认值是否正确
│
├─ 权限覆盖
│   ├─ 角色权限覆盖：不同角色权限是否测试
│   ├─ 越权访问覆盖：越权操作是否拦截
│   ├─ 数据权限覆盖：数据隔离是否验证
│   ├─ 功能权限覆盖：功能访问控制是否测试
│   ├─ CSRF防护覆盖：跨站请求伪造防护是否测试
│   └─ 路径遍历覆盖：目录遍历攻击防护是否测试
│
├─ 集成覆盖
│   ├─ 模块集成覆盖：模块间协作是否测试
│   ├─ 接口集成覆盖：接口调用是否测试
│   ├─ 数据集成覆盖：数据流转是否测试
│   └─ 异常集成覆盖：异常处理是否测试
│
└─ 非功能覆盖
    ├─ 性能覆盖：响应时间、吞吐量、并发性能是否测试
    ├─ 兼容性覆盖：浏览器、操作系统、设备兼容性是否测试
    ├─ 可用性覆盖：用户体验、易用性是否测试
    ├─ 安全性覆盖：数据加密、传输安全是否测试
    └─ 可靠性覆盖：稳定性、容错性是否测试
```

### 覆盖率评估

| 覆盖率类型 | 计算方式 | 目标值 |
|------------|----------|--------|
| 需求覆盖率 | 已测需求点 / 总需求点 × 100% | ≥95% |
| 功能覆盖率 | 已测功能点 / 总功能点 × 100% | ≥90% |
| 用例覆盖率 | 已执行用例 / 总用例 × 100% | ≥100% |
| 缺陷覆盖率 | 已修复缺陷 / 总缺陷 × 100% | ≥90% |

## 质量保证标准

### 用例质量指标

| 指标 | 计算方式 | 目标值 |
|------|----------|--------|
| 用例有效性 | 有效用例数 / 总用例数 × 100% | ≥95% |
| 用例执行率 | 已执行用例数 / 总用例数 × 100% | ≥100% |
| 用例通过率 | 通过用例数 / 已执行用例数 × 100% | ≥98% |
| 缺陷发现率 | 缺陷数 / 用例数 × 100% | 持续优化 |

### 交付质量标准

- 用例总数不低于需求点的3倍（包含异常场景）
- P0+P1用例占比不低于60%
- 每条用例平均预期结果3-5条
- 无空洞描述，预期结果均可客观验证
- 符合企业测试管理规范格式要求
- 测试步骤留空，由用户根据实际系统补充

references/design-methods.md

# 用例设计方法参考

## 常用设计方法

| 方法 | 适用场景 | 说明 | 必用场景 |
|------|----------|------|----------|
| 等价类划分法 | 输入域测试 | 将输入域划分为有效/无效等价类，减少冗余用例 | 所有输入字段 |
| 边界值分析法 | 边界测试 | 针对边界情况设计专项测试，发现常见错误 | 所有有边界限制的字段 |
| 场景法 | 业务流程测试 | 基于用户业务流程构建端到端测试场景 | 核心业务流程 |
| 判定表驱动法 | 多条件组合 | 穷举所有条件组合可能性 | **必须使用**：多条件组合场景 |
| 错误推测法 | 经验驱动 | 基于历史缺陷数据和开发经验预测潜在问题 | **必须使用**：异常场景覆盖 |
| 风险驱动测试 | 风险优先 | 优先覆盖高风险区域和高频使用场景 | 高风险功能 |
| 状态转换法 | 状态机测试 | 测试状态机的合法/非法转换 | 有状态变化的功能 |
| 因果图法 | 复杂条件组合 | 分析输入条件与输出结果的因果关系 | **必须使用**：复杂条件依赖关系 |
| 正交试验法 | 多因素多水平 | 用最少的试验覆盖最多的因素组合 | **必须使用**：多因素兼容性测试 |
| 功能图法 | 功能组合测试 | 分析功能点的输入输出关系，生成功能测试用例 | **必须使用**：功能点组合覆盖 |

### 方法应用要点

**等价类划分法**：有效等价类（正常业务数据范围）、无效等价类（异常/边界/特殊数据）。划分依据：业务规则、数据类型、用户角色。示例：用户年龄输入（1-120有效，<1或>120无效）。

**边界值分析法**：数值边界（最小值、最小值+1、最大值-1、最大值）、字符串边界（空、1字符、最大长度、最大长度+1）、日期边界（当天、前一天、后一天）。示例：密码长度8位（测试7位、8位、9位）。

**场景法**：主成功场景（正常业务流程）、扩展场景（分支流程）、异常场景（错误处理流程）。示例：电商下单（浏览→加购→结算→支付→完成）。

**判定表驱动法**：条件桩（所有输入条件）、动作桩（所有可能输出）、规则（条件组合与动作对应关系）。示例：登录（用户名正确/错误 × 密码正确/错误 → 不同结果）。

**错误推测法**：基于经验（历史缺陷/常见错误模式）、基于直觉（测试人员经验判断）、基于领域知识（业务规则边界）。示例：输入框输入特殊字符/超长字符串/SQL注入语句。

**因果图法**：原因（输入条件）、结果（输出结果）、关系（与/或/非逻辑）、约束（条件间依赖）。示例：优惠券使用条件（金额≥100且有券 → 可使用）。

**正交试验法**：因素（测试变量）、水平（取值）、用例（最少组合覆盖最多因素）。示例：兼容性测试（3浏览器×3系统×3分辨率 → 正交表选9组）。

**功能图法**：功能点（系统功能）、输入（条件）、输出（结果）、组合（调用关系）。示例：电商系统（登录→浏览→加购→结算→支付→功能组合测试）。

## 复杂场景覆盖

| 场景类型 | 测试重点 | 示例 |
|----------|----------|------|
| 页面跳转测试 | 跳转目标、参数传递、权限校验 | 列表跳详情页、菜单跳转、外部链接跳转 |
| 路由参数测试 | 参数缺失、非法、越界处理 | URL参数传递、query参数、path参数 |
| 跨页面联动 | 数据传递、状态同步、缓存一致性 | 订单页与用户页关联、购物车与结算页联动 |
| 并发场景测试 | 多人同时操作、数据竞争 | 同时下单、库存并发扣减 |
| 异常兜底测试 | 服务降级、熔断、重试机制 | 接口超时、服务不可用、网络异常 |

### 页面跳转测试深度覆盖

**测试要点**：跳转触发点、跳转目标页、跳转条件、异常跳转。检查：正常跳转目标正确、参数传递完整、权限校验拦截正确、404处理、空状态、浏览器回退、返回按钮、面包屑导航、外部跳转新标签页、循环跳转检测。

### 路由参数测试深度覆盖

**测试要点**：参数定义（query/path/hash）、格式（数据类型/长度限制）、传递方式（URL/session/cookie/localStorage）、验证（缺失/非法/越界/安全）。检查：参数存在性、类型、长度、格式、安全（SQL注入/XSS）、边界、组合、编码。

### 跨页面联动测试深度覆盖

**测试要点**：数据依赖（页面间数据关系）、状态同步（操作后更新）、缓存策略（刷新机制）、业务流程（完整闭环）。检查：数据传递正确、关联页面状态更新、缓存策略合理、消息通知跳转正确、业务闭环完整、多页面数据一致、操作反馈同步。

## 常用测试方法速查

**等价类划分示例**：年龄输入框（有效[1,120]，无效<1/>120/非数字）；状态下拉（有效[启用/禁用/冻结]，无效其他）。

**边界值分析示例**：文件上传10MB（9MB/10MB/10.1MB）；文本框200字符（199/200/201字）；列表分页（第1页/最后1页/超出最大页码）。

**判定表示例**：

| 条件 | A(有优惠券) | B(满100元) | C(可用) | 结果 |
|------|-------------|------------|---------|------|
| 1 | Y | Y | Y | 可以使用 |
| 2 | Y | Y | N | 不可用（已过期） |
| 3 | Y | N | Y | 不可用（不满足门槛） |
| 4 | N | Y/Y | Y/Y | 不适用 |

references/output-template-full.md

# 测试用例 9 列标准格式（权威定义）

> **本文件是全项目测试用例格式的唯一真源。** 其他技能（`qa-api-testing`、`qa-agent-testing`、
> `qa-regression-testing` 等）产出用例时以本定义为准；有冲突以本文件为准。
> 校验工具：`python scripts/validate_testcase_table.py <用例文件>`

## 1. 九列定义

| # | 列名 | 必填 | 填写要求 | 常见错误 |
|---|------|------|---------|---------|
| 1 | 用例编号 | ✅ | `TC_{模块缩写}_{功能缩写}_{三位序号}`，同批内不重号 | 用 `TC_USER_LOGIN_001_NORMAL` 四段式；用 `AGENT-001` |
| 2 | 测试类型 | ✅ | 按所属技能维度填写：功能/安全/异常/性能/契约/兼容性；API 类补安全与契约 | 写"正常用例""异常用例" |
| 3 | 功能模块 | ✅ | 业务模块，必要时用 `模块/子功能` 两级（**子功能并入本列，不单设列**） | 只写"系统""后端" |
| 4 | 测试标题 | ✅ | 动词开头，点明验证点 | 写"测试登录" |
| 5 | 用例级别 | ✅ | P0/P1/P2/P3，占比见 §3 | 全标 P0 |
| 6 | 预置条件 | ✅ | 环境 + 数据 + 权限 + 状态，具体到可复现 | 只写"环境正常" |
| 7 | 测试步骤 | ⚠️ 见 §4 | 协议类必填；实现相关类可留空 | 全留空（丢了可执行性） |
| 8 | 预期结果 | ✅ | 可量化：状态码 / 返回结构 / 数据状态 / 副作用 | 写"正确""正常" |
| 9 | 风险等级 | ✅ | 高（资损/越权/数据错误/安全）/ 中（体验与稳定性）/ 低 | 留空或全标高 |

> **为什么没有"实际结果"列**：那是**执行阶段**的记录字段，由 `qa-execution-observation` 的
> 观察记录承载，不属于设计阶段的用例定义。设计模板塞执行字段会导致执行时被回填污染设计产物。
>
> **为什么没有"子功能"列**：并入「功能模块」用 `模块/子功能` 表示，信息不丢且不增加列宽。
> 9 列是 `validate_testcase_table.py` 与 `测试用例.csv` 的硬约束，不可增减。

## 2. 编号规则

```
TC_{模块缩写}_{功能缩写}_{三位序号}
```

- 模块缩写：业务模块，2-10 位大写字母或数字（`API` / `CART` / `LOGIN` / `ORDER`）
- 功能缩写：功能点，2-10 位（`LOGIN` / `CREATE` / `REFUND`）
- 三位序号：同批内从 `001` 连续递增

示例：
- `TC_API_LOGIN_001` — API 模块 / 登录功能 / 第 1 条
- `TC_CART_ADD_007` — 购物车 / 添加商品 / 第 7 条
- `TC_ORDER_REFUND_003` — 订单 / 退款 / 第 3 条

> **不使用场景后缀**（如 `_NORMAL` / `_JUMP`）。场景类别信息应写进「测试类型」与「测试标题」，
> 塞进 ID 会让 ID 失去稳定的"用例"语义，也破坏与 `SC-{模块缩写}-{序号}` 场景 ID 的对应关系。

## 3. 级别与占比

| 级别 | 含义 | 适用场景 |
|------|------|---------|
| P0 | 关键 | 核心业务流程、主流程验证、资损/安全相关 |
| P1 | 重要 | 主要功能、重要分支流程 |
| P2 | 一般 | 次要功能、异常场景 |
| P3 | 可选 | 边缘场景、极端异常 |

**占比约束**：P0 ≤ 20% / P1 ≤ 40% / P2 ≤ 30% / P3 ≤ 10%

**小规模例外**：用例总数 < 10 条时上述配额在数学上无法成立（20% 不足 1 条）。
此时加 `--no-quota` 跳过校验，并在报告中注明「小规模用例集，按每维至少 1 条覆盖」。
**不要为凑比例编造用例或随意拉高/压低级别。**

## 4. 「测试步骤」该留空还是该填

这是历史上最容易产生分歧的一列，裁决如下：

| 用例类型 | 步骤 | 理由 |
|---------|------|------|
| **协议 / 接口类**（API、gRPC、WebSocket、Webhook、数据库协议） | **必填**，含 method + path + 关键参数 | 步骤由协议契约决定，不依赖实现细节，AI 能准确写出来 |
| **配置 / 规则 / 计算类**（配置项、金额计算、权限矩阵） | **必填** | 同上，规则本身是确定的 |
| **UI / 业务流程类**（页面跳转、交互流程） | **可留空**，标注「由执行人按实际系统补充」 | 同一"登录"功能不同系统实现完全不同，AI 强写必然与实际不符，反而增加修正成本 |

> 历史版本曾一刀切要求"测试步骤留空"，导致 API 类用例丢失了可执行性——
> 而 API 的 method/path 恰恰是**规格的一部分**，不是实现细节。
> 现按类型区分：协议类必填，实现相关类可留空。

## 5. 两种产出形态

### A. 表格形态（默认，批量评审/流转用）

```markdown
| 用例编号 | 测试类型 | 功能模块 | 测试标题 | 用例级别 | 预置条件 | 测试步骤 | 预期结果 | 风险等级 |
|---------|---------|---------|---------|---------|---------|---------|---------|---------|
| TC_API_LOGIN_001 | 功能测试 | 认证/登录 | 正确凭证登录成功 | P0 | 账号 u1 已就绪，接口文档已提供 | POST /api/login，body {"user":"u1","pass":"***"} | 返回 200，响应含 token；调 /api/profile 有效；无堆栈泄露 | 高 |
| TC_API_LOGIN_002 | 安全测试 | 认证/登录 | 伪造 Token 被拒 | P0 | 已知合法 token 与签名算法 | 改 1 个字符后请求 /api/profile | 返回 401；响应不含内部信息与用户数据 | 高 |
```

### B. 展开块（单条用例评审/执行时用）

```markdown
### TC_API_LOGIN_001 — 正确凭证登录成功

- **测试类型**：功能测试
- **功能模块**：认证/登录
- **用例级别**：P0
- **预置条件**：账号 u1 已就绪；接口文档已提供
- **测试步骤**：POST

Github ReposUpdated 1d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.