testany-case

Name: testany-case
Author: TestAny-io

16installs23forks

How to install testany-case?

testany-io/testany-agent-skills/testany-case

$npx -y skills add TestAny-io/testany-agent-skills --skill testany-case

Installs into the current project.

Summary

Testany platform case 注册与 CRUD - 将已准备好的 platform case package 注册到平台，并管理 metadata、脚本与生命周期

Files · 1

View on GitHub

SKILL.md

1	# Testany Platform Case Registration & CRUD
2
3	本 skill 通过 Testany MCP 工具管理 Testany 平台上的 platform cases。
4	所有操作都是对 Testany 平台的远程 API 调用，不涉及本地文件系统。
5
6	关键前提：
7	- Testany `case` 是可复用原子自动化步骤包
8	- Testany 不支持直接执行单条 case
9	- 如果用户要真正执行，后续仍需要 `testany-pipeline`
10
11	用户输入: $ARGUMENTS
12
13	---
14
15	## 宿主能力适配
16
17	- 优先使用宿主提供的结构化提问工具（如 AskUserQuestion）一次性收集缺失信息。
18	- 如果宿主不支持该工具，则用一条普通消息集中提问相同问题；低风险字段可给出默认值建议。
19	- 如果宿主支持 slash command，可推荐相关 workflow 的命令入口；否则直接在当前线程继续对应 workflow。
20
21	---
22
23	## 先统一心智模型
24
25	使用本 skill 前，先按 [automation-model.md](../testany-guide/references/automation-model.md) 理解边界：
26
27	- 上游给出的通常是 traditional test scenario
28	- `testany-case-writing` 负责把它拆成 platform cases，并产出脚本、ZIP 与 decomposition
29	- 本 skill 负责把这些 platform case packages 注册到 Testany 平台
30	- `testany-pipeline` 负责把 platform cases 组装成可执行 pipeline
31	- `testany-trigger` 负责配置 `Plan / Manual Trigger / Gatekeeper`
32
33	重要结论：
34	- 本 skill 的主路径不应该是“现场理解业务场景并写 case”
35	- 本 skill 的主路径应该是“消费上游已准备好的 package / metadata / decomposition，完成平台注册与生命周期管理”
36
37	---
38
39	## 职责
40
41	- 注册 `testany-case-writing` 已产出的 platform case packages
42	- 创建 case shell、补齐 case metadata、上传脚本 ZIP
43	- 查询、更新、批量更新、删除平台上的 platform cases
44	- 在变更后提醒用户检查下游 pipeline 影响面
45	- 在可行时触发 dry run 验证 case 是否 ready
46
47	## 不负责的事情
48
49	- 不负责把传统测试场景拆解成 platform cases；这属于 `testany-case-writing`
50	- 不负责创建或更新 pipeline；这属于 `testany-pipeline`
51	- 不负责配置 Plan / Manual Trigger / Gatekeeper；这属于 `testany-trigger`
52
53	---
54
55	## 操作速查
56
57	\| 用户意图 \| 操作类型 \| 工具 \|
58	\|---------\|---------\|------\|
59	\| 注册新的 platform case \| Create \| `testany_create_case` → `testany_update_case` → `testany_update_case_script` \|
60	\| 查看 case 详情 \| Read \| `testany_get_case` \|
61	\| 查看 case 脚本内容 \| Read \| `testany_get_case_script` \|
62	\| 搜索/列出 cases \| Read \| `testany_list_cases` \|
63	\| 列出我的 cases \| Read \| `testany_list_my_cases` \|
64	\| 更新 metadata / script \| Update \| `testany_update_case` / `testany_update_case_script` \|
65	\| 删除 case \| Delete \| `testany_delete_case` \|
66	\| 批量更新 cases \| Bulk Update \| `testany_bulk_update_cases` \|
67	\| 批量删除 cases \| Bulk Delete \| `testany_bulk_delete_cases` \|
68	\| dry run 验证 \| Validate \| `testany_dry_run_case` → `testany_get_dry_run_result` \|
69	\| 查看 dry run 日志 \| Read \| `testany_get_dry_run_log`（拼接出 logUrl + curlCommand，agent 代为执行） \|
70
71	---
72
73	## Create（注册新的 platform case）
74
75	### Phase 0: 先判断输入模式
76
77	按以下优先级选择输入模式：
78
79	1. Primary：已有 platform case package
80	- 来自 `testany-case-writing`
81	- 已准备好脚本、ZIP、metadata、executor 选择
82	- 最适合本 skill
83
84	2. Secondary：已有脚本/ZIP，但 metadata 不完整
85	- 可以在本 skill 中补齐名称、可见性、labels、case_meta 等字段
86
87	3. Fallback：只想先创建草稿 shell case
88	- 仅当用户明确要求占位、预留 key、先建空壳时使用
89	- 不能把它包装成“已经完成自动化落地”
90
91	如果用户只有传统测试场景，没有脚本、ZIP、decomposition：
92	- 停止直接创建
93	- 切到 `testany-case-writing`
94
95	### Phase 1: 准备可选项
96
97	并行获取：
98	- `testany_filter_case_runtimes`
99	- `testany_get_my_workspaces`
100	- `testany_get_tenant_config`（拿 `deployment_type`，决定 visibility 默认值，见 [case-visibility-policy.md](../testany-guide/references/case-visibility-policy.md)）
101
102	如涉及 labels，先：
103	- `testany_list_labels`
104	- 如缺失再 `testany_create_label`
105
106	### Phase 2: 收集注册所需字段
107
108	优先一次性收集以下内容：
109
110	\| 字段 \| 必填 \| 说明 \|
111	\|------\|------\|------\|
112	\| `name` \| 是 \| platform case 名称 \|
113	\| `runtime_uuid` \| 是 \| 运行环境 UUID，推荐 cloudprime \|
114	\| `is_private` \| 是 \| Global / Private — 受 `deployment_type` 约束，见 [case-visibility-policy.md](../testany-guide/references/case-visibility-policy.md) \|
115	\| `workspace_keys` \| 条件必填 \| `is_private=true` 时必填；详见 policy 文档 \|
116	\| `description` \| 建议 \| 说明该 platform case 的原子职责 \|
117	\| `case_labels` \| 建议 \| 用于目录视图和检索 \|
118	\| `case_meta` \| 条件必填 \| 运行所需配置，具体字段见 executors reference \|
119	\| ZIP / 脚本包 \| 条件必填 \| 若目标是注册 runnable case，通常需要 \|
120
121	收集原则：
122	- 主路径假设用户已经有 package；本 skill 只做“平台注册与补齐元数据”
123	- 如果用户明确只要草稿 case，可暂不上传 ZIP，但必须明确这是占位资产，不可直接执行
124
125	### Phase 3: 创建 shell case
126
127	调用 `testany_create_case`：
128	- `name`
129	- `runtime_uuid`
130	- `is_private`
131	- `workspace_keys`
132
133	### Phase 4: 补齐 metadata / 运行配置
134
135	调用 `testany_update_case` 设置：
136	- `description`
137	- `case_labels`
138	- `environments`
139	- `owned_by`
140	- `case_version`
141	- `case_meta`
142
143	这里的 `case_meta` 后端字段名仍然是 `trigger_method`，但它表示的是 case 级运行入口配置：
144	- `executor`
145	- `trigger_path`
146	- `trigger_command`
147
148	它不等于 `Plan / Manual Trigger / Gatekeeper` 这类 pipeline trigger。
149
150	#### `case_meta.environment_variables`
151
152	case 运行时可见的变量列表，每条有一个 `type`：
153
154	\| type \| 用途 \| 填值方式 \|
155	\|------\|------\|---------\|
156	\| `env`（默认） \| 普通环境变量、relay 输入 \| 填 `value` \|
157	\| `output` \| 供 pipeline 中其他 case relay 消费 \| 填 `value`（运行时由脚本写入） \|
158	\| `secrets` \| 引用 workspace 的 Credential Safe 条目 \| 填 `secret_ref: { workspace_key, credential_safe_key, credential_key }`；禁止填 `value` \|
159
160	关于 `type=secrets`：
161
162	- 声明后，脚本里直接用同名环境变量读取凭证值即可（例：`os.getenv("DB_PASSWORD")`），不需要额外的取值代码或 SDK
163	- 如果用户没有现成的 `credential_safe_key` / `credential_key`，用 `testany_list_credential_safes` → `testany_list_credential_keys` 两步查询（`runtime_uuid` 必须与 case 一致；两个工具返回签名 curl，需 agent 代为执行）。详细流程见 [executors.md 的"查询 credential_safe_key / credential_key"](./references/executors.m

People who liked this also viewed

6 picks

Type

tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026501k181k
test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026175k259k
qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026153k259k
webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026120k163k
playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 202664k338

testany-case

16installs23forks

View on GitHub

How to install testany-case?

testany-io/testany-agent-skills/testany-case

$npx -y skills add TestAny-io/testany-agent-skills --skill testany-case

Installs into the current project.

Summary

Testany platform case 注册与 CRUD - 将已准备好的 platform case package 注册到平台，并管理 metadata、脚本与生命周期

Files · 1

View on GitHub

SKILL.md

1	# Testany Platform Case Registration & CRUD
2
3	本 skill 通过 Testany MCP 工具管理 Testany 平台上的 platform cases。
4	所有操作都是对 Testany 平台的远程 API 调用，不涉及本地文件系统。
5
6	关键前提：
7	- Testany `case` 是可复用原子自动化步骤包
8	- Testany 不支持直接执行单条 case
9	- 如果用户要真正执行，后续仍需要 `testany-pipeline`
10
11	用户输入: $ARGUMENTS
12
13	---
14
15	## 宿主能力适配
16
17	- 优先使用宿主提供的结构化提问工具（如 AskUserQuestion）一次性收集缺失信息。
18	- 如果宿主不支持该工具，则用一条普通消息集中提问相同问题；低风险字段可给出默认值建议。
19	- 如果宿主支持 slash command，可推荐相关 workflow 的命令入口；否则直接在当前线程继续对应 workflow。
20
21	---
22
23	## 先统一心智模型
24
25	使用本 skill 前，先按 [automation-model.md](../testany-guide/references/automation-model.md) 理解边界：
26
27	- 上游给出的通常是 traditional test scenario
28	- `testany-case-writing` 负责把它拆成 platform cases，并产出脚本、ZIP 与 decomposition
29	- 本 skill 负责把这些 platform case packages 注册到 Testany 平台
30	- `testany-pipeline` 负责把 platform cases 组装成可执行 pipeline
31	- `testany-trigger` 负责配置 `Plan / Manual Trigger / Gatekeeper`
32
33	重要结论：
34	- 本 skill 的主路径不应该是“现场理解业务场景并写 case”
35	- 本 skill 的主路径应该是“消费上游已准备好的 package / metadata / decomposition，完成平台注册与生命周期管理”
36
37	---
38
39	## 职责
40
41	- 注册 `testany-case-writing` 已产出的 platform case packages
42	- 创建 case shell、补齐 case metadata、上传脚本 ZIP
43	- 查询、更新、批量更新、删除平台上的 platform cases
44	- 在变更后提醒用户检查下游 pipeline 影响面
45	- 在可行时触发 dry run 验证 case 是否 ready
46
47	## 不负责的事情
48
49	- 不负责把传统测试场景拆解成 platform cases；这属于 `testany-case-writing`
50	- 不负责创建或更新 pipeline；这属于 `testany-pipeline`
51	- 不负责配置 Plan / Manual Trigger / Gatekeeper；这属于 `testany-trigger`
52
53	---
54
55	## 操作速查
56
57	\| 用户意图 \| 操作类型 \| 工具 \|
58	\|---------\|---------\|------\|
59	\| 注册新的 platform case \| Create \| `testany_create_case` → `testany_update_case` → `testany_update_case_script` \|
60	\| 查看 case 详情 \| Read \| `testany_get_case` \|
61	\| 查看 case 脚本内容 \| Read \| `testany_get_case_script` \|
62	\| 搜索/列出 cases \| Read \| `testany_list_cases` \|
63	\| 列出我的 cases \| Read \| `testany_list_my_cases` \|
64	\| 更新 metadata / script \| Update \| `testany_update_case` / `testany_update_case_script` \|
65	\| 删除 case \| Delete \| `testany_delete_case` \|
66	\| 批量更新 cases \| Bulk Update \| `testany_bulk_update_cases` \|
67	\| 批量删除 cases \| Bulk Delete \| `testany_bulk_delete_cases` \|
68	\| dry run 验证 \| Validate \| `testany_dry_run_case` → `testany_get_dry_run_result` \|
69	\| 查看 dry run 日志 \| Read \| `testany_get_dry_run_log`（拼接出 logUrl + curlCommand，agent 代为执行） \|
70
71	---
72
73	## Create（注册新的 platform case）
74
75	### Phase 0: 先判断输入模式
76
77	按以下优先级选择输入模式：
78
79	1. Primary：已有 platform case package
80	- 来自 `testany-case-writing`
81	- 已准备好脚本、ZIP、metadata、executor 选择
82	- 最适合本 skill
83
84	2. Secondary：已有脚本/ZIP，但 metadata 不完整
85	- 可以在本 skill 中补齐名称、可见性、labels、case_meta 等字段
86
87	3. Fallback：只想先创建草稿 shell case
88	- 仅当用户明确要求占位、预留 key、先建空壳时使用
89	- 不能把它包装成“已经完成自动化落地”
90
91	如果用户只有传统测试场景，没有脚本、ZIP、decomposition：
92	- 停止直接创建
93	- 切到 `testany-case-writing`
94
95	### Phase 1: 准备可选项
96
97	并行获取：
98	- `testany_filter_case_runtimes`
99	- `testany_get_my_workspaces`
100	- `testany_get_tenant_config`（拿 `deployment_type`，决定 visibility 默认值，见 [case-visibility-policy.md](../testany-guide/references/case-visibility-policy.md)）
101
102	如涉及 labels，先：
103	- `testany_list_labels`
104	- 如缺失再 `testany_create_label`
105
106	### Phase 2: 收集注册所需字段
107
108	优先一次性收集以下内容：
109
110	\| 字段 \| 必填 \| 说明 \|
111	\|------\|------\|------\|
112	\| `name` \| 是 \| platform case 名称 \|
113	\| `runtime_uuid` \| 是 \| 运行环境 UUID，推荐 cloudprime \|
114	\| `is_private` \| 是 \| Global / Private — 受 `deployment_type` 约束，见 [case-visibility-policy.md](../testany-guide/references/case-visibility-policy.md) \|
115	\| `workspace_keys` \| 条件必填 \| `is_private=true` 时必填；详见 policy 文档 \|
116	\| `description` \| 建议 \| 说明该 platform case 的原子职责 \|
117	\| `case_labels` \| 建议 \| 用于目录视图和检索 \|
118	\| `case_meta` \| 条件必填 \| 运行所需配置，具体字段见 executors reference \|
119	\| ZIP / 脚本包 \| 条件必填 \| 若目标是注册 runnable case，通常需要 \|
120
121	收集原则：
122	- 主路径假设用户已经有 package；本 skill 只做“平台注册与补齐元数据”
123	- 如果用户明确只要草稿 case，可暂不上传 ZIP，但必须明确这是占位资产，不可直接执行
124
125	### Phase 3: 创建 shell case
126
127	调用 `testany_create_case`：
128	- `name`
129	- `runtime_uuid`
130	- `is_private`
131	- `workspace_keys`
132
133	### Phase 4: 补齐 metadata / 运行配置
134
135	调用 `testany_update_case` 设置：
136	- `description`
137	- `case_labels`
138	- `environments`
139	- `owned_by`
140	- `case_version`
141	- `case_meta`
142
143	这里的 `case_meta` 后端字段名仍然是 `trigger_method`，但它表示的是 case 级运行入口配置：
144	- `executor`
145	- `trigger_path`
146	- `trigger_command`
147
148	它不等于 `Plan / Manual Trigger / Gatekeeper` 这类 pipeline trigger。
149
150	#### `case_meta.environment_variables`
151
152	case 运行时可见的变量列表，每条有一个 `type`：
153
154	\| type \| 用途 \| 填值方式 \|
155	\|------\|------\|---------\|
156	\| `env`（默认） \| 普通环境变量、relay 输入 \| 填 `value` \|
157	\| `output` \| 供 pipeline 中其他 case relay 消费 \| 填 `value`（运行时由脚本写入） \|
158	\| `secrets` \| 引用 workspace 的 Credential Safe 条目 \| 填 `secret_ref: { workspace_key, credential_safe_key, credential_key }`；禁止填 `value` \|
159
160	关于 `type=secrets`：
161
162	- 声明后，脚本里直接用同名环境变量读取凭证值即可（例：`os.getenv("DB_PASSWORD")`），不需要额外的取值代码或 SDK
163	- 如果用户没有现成的 `credential_safe_key` / `credential_key`，用 `testany_list_credential_safes` → `testany_list_credential_keys` 两步查询（`runtime_uuid` 必须与 case 一致；两个工具返回签名 curl，需 agent 代为执行）。详细流程见 [executors.md 的"查询 credential_safe_key / credential_key"](./references/executors.m

People who liked this also viewed

6 picks

Type