testany-case

Testany Platform Case Registration & CRUD

This skill manages platform cases on the Testany platformthrough the Testany MCP tool. All operations are remote API calls to the Testany platform and do not involve the local file system.

Key prerequisites：

Testany case isa reusable atomic automation step package
Testany does not support directly executing a single case
If the user wants to actually execute it, they will still need testany-pipeline

User input: $ARGUMENTS

Host capability adaptation

Preferentially use the structured question tool provided by the host (such as AskUserQuestion) to collect missing information in one go.
If the host does not support that tool, then ask the same questions together in a single ordinary message; for low-risk fields, default value suggestions may be provided.
If the host supports slash command, you may recommend the command entry point of the relevant workflow; otherwise, continue the corresponding workflow directly in the current thread.

First unify the mental model

Before using this skill, first understand the boundaries according to automation-model.md :

What is usually provided upstream is traditional test scenario
testany-case-writing is responsible for splitting it into platform cases, and producing scripts, ZIP, and decomposition
This skill is responsible for registering these platform case packages to the Testany platform
testany-pipeline is responsible for assembling platform cases into executable pipelines
testany-trigger is responsible for configuring Plan / Manual Trigger / Gatekeeper

Important conclusion：

The main path of this skill should not be "understand the business scenario on the spot and write a case"
The main path of this skill should be "consume the package / metadata / decomposition already prepared upstream and complete platform registration and lifecycle management"

Responsibilities

Register testany-case-writing platform case packages already produced
Create case shell, complete case metadata, upload script ZIP
Query, update, batch update, and delete platform cases on the platform
After changes, remind the user to check the impact scope on downstream pipelines
When feasible, trigger a dry run to verify whether the case is ready

Things not in scope

Notresponsible for breaking down traditional test scenarios into platform cases; this belongs to testany-case-writing
Notresponsible for creating or updating pipelines; this belongs to testany-pipeline
Notresponsible for configuring Plan / Manual Trigger / Gatekeeper; this belongs to testany-trigger

Operations quick reference

User intent	Operation type	Tool
Register a new platform case	Create	`testany_create_case` → `testany_update_case` → `testany_update_case_script`
View case details	Read	`testany_get_case`
View case script content	Read	`testany_get_case_script`
Search/list cases	Read	`testany_list_cases`
List my cases	Read	`testany_list_my_cases`
Update metadata / script	Update	`testany_update_case` / `testany_update_case_script`
Delete case	Delete	`testany_delete_case`
Batch update cases	Bulk Update	`testany_bulk_update_cases`
Batch delete cases	Bulk Delete	`testany_bulk_delete_cases`
dry run verification	Validate	`testany_dry_run_case` → `testany_get_dry_run_result`
View dry run logs	Read	`testany_get_dry_run_log`(concatenate logUrl + curlCommand, and the agent executes it on behalf)

Create (register a new platform case)

Phase 0: First determine the input mode

Choose the input mode according to the following priorities:

Primary: already has a platform case package
- From testany-case-writing
- Script, ZIP, metadata, and executor selection are already prepared
- Best suited for this skill
Secondary: already has a script/ZIP, but metadata is incomplete
- Fields such as name, visibility, labels, and case_meta can be completed in this skill
Fallback: only want to create a draft shell case first
- Use only when the user explicitly asks for a placeholder, a reserved key, or to create an empty shell first
- It must not be packaged as "automation implementation already completed"

If the user only has a traditional test scenario, without a script, ZIP, or decomposition:

Stop creating directly
Switch to testany-case-writing

Phase 1: Prepare optional items

Fetch in parallel:

testany_filter_case_runtimes
testany_get_my_workspaces
testany_get_tenant_config(get deployment_type, determine the visibility default, see case-visibility-policy.md）

If labels are involved, first:

testany_list_labels
If missing, then testany_create_label

Phase 2: Collect the fields required for registration

Prefer to collect the following all at once:

Field	Required	Description
`name`	Yes	platform case name
`runtime_uuid`	Yes	Runtime environment UUID, cloudprime recommended
`is_private`	Yes	Global / Private — Constrained by `deployment_type` Constraints, see case-visibility-policy.md
`workspace_keys`	Conditionally required	`is_private=true` Required when ; see the policy documentation for details
`description`	Recommended	Describe the atomic responsibility of this platform case
`case_labels`	Recommended	Used for directory views and search
`case_meta`	Conditionally required	Configuration required for running; see the executors reference for the specific fields
ZIP / script package	Conditionally required	If the goal is to register a runnable case, it is usually needed

Collection principles：

The primary path assumes the user already has a package; this skill only does "platform registration and metadata completion"
If the user explicitly only wants a draft case, the ZIP may be left unuploaded for now, but it must be made clear that this is a placeholder asset and cannot be run directly

Phase 3: Create a shell case

Call testany_create_case：

name
runtime_uuid
is_private
workspace_keys

Phase 4: Complete metadata / runtime configuration

Call testany_update_case to set:

description
case_labels
environments
owned_by
case_version
case_meta

Here, case_meta the backend field name is still trigger_method, but it represents case-level runtime entry configuration：

executor
trigger_path
trigger_command

It is not equivalent to Plan / Manual Trigger / Gatekeeper such pipeline triggers.

`case_meta.environment_variables`

The list of variables visible at case runtime; each entry has a type：

type	Purpose	How to fill in the value
`env`(default)	Ordinary environment variable, relay input	Fill in `value`
`output`	For other cases in the pipeline to consume via relay	Fill in `value`(written by the script at runtime)
`secrets`	Reference a Credential Safe entry in the workspace	Fill in `secret_ref: { workspace_key, credential_safe_key, credential_key }`；ForbiddenFill in `value`

About type=secrets：

After declaration, the script can read the credential value directly using the environment variable of the same name (example:os.getenv("DB_PASSWORD")), without additional value-retrieval code or an SDK
If the user does not have an existing credential_safe_key / credential_key, use testany_list_credential_safes → testany_list_credential_keys two-step query (runtime_uuid must match the case; both tools return a signature curl, which the agent must execute on the user's behalf). For the detailed process, see the "Query credential_safe_key / credential_key" section of executors.md
When reading back a case, each secrets line carries the read-only field status（valid / blocked / invalid) and status_reasons[]
- not valid , report the reason to the user. Common reasons:owner_access_not_satisfied(owner has no access),visibility_not_satisfied(case visibility narrowed),target_not_found_or_unresolvable(safe/key does not exist),secret_ref_malformed(referenced fields incomplete)
Do not pass value / status / status_reasonswhen writing; if passed, the backend will reject it
If testany_update_case / testany_bulk_update_cases / testany_bulk_append_cases returns error code E400002（case_secrets_feature_disabled), explain to the user:the secrets feature of the current workspace may not be enabled, please contact the workspace administrator

Write notes (whole-collection replacement semantics)：environment_variables is a whole-array replacement. If you only want to add or modify a single secret, you must first testany_get_case read out the existing entries, merge them in memory, and then write back; otherwise other env / output / secrets lines will be cleared as well.

For detailed field rules, see:

Phase 5: Upload script ZIP

If the user has already prepared the script package, call testany_update_case_script to upload.

If the script contains the following capabilities, remind the user to complete the corresponding configuration:

Relay output → declare the corresponding case_meta.environment_variables in type=output line
Credential / sensitive value access → declare the case_meta.environment_variables in type=secrets line + secret_ref, and the script can directly read the environment variable of the same name

Phase 6: Optional dry run

If the user requests verification, or required fields have just been completed:

testany_dry_run_case
testany_get_dry_run_result poll until it reaches a terminal state
If troubleshooting is needed (for example, failure, or wanting to see the actual stdout), call testany_get_dry_run_log to get curlCommand , then the agent executes the log retrieval on the user's behalf

Phase 7: Clarify downstream handoff

After creation is complete, you must explicitly state:

This is a registered platform case
If the user wants to form an executable chain, the next step requires testany-pipeline
Even if there is only one case, executing it in Testany still requires a pipeline

Read (query)

Scenario	Tool	Description
Get a single case's details	`testany_get_case`	Pass in the case key
Get the case script content	`testany_get_case_script`	Download the ZIP and return the file content
Search all cases	`testany_list_cases`	Supports filters such as workspace / keyword / page
List my cases	`testany_list_my_cases`	Suitable for personal asset inventory

Update

Updatable fields

Field	Description
`name`	case name
`description`	Atomic responsibility description
`is_private`	Visibility
`workspace_keys`	Workspace list for private cases
`environments`	Environment tags
`case_labels`	Category tags
`case_version`	Version
`owned_by`	Owner
`case_meta`	Runtime Configuration
Script ZIP	via `testany_update_case_script` upload

Update Flow

testany_get_case Get the current configuration
Confirm the fields to modify
testany_update_case Submit the metadata update
If the script needs to be replaced, then testany_update_case_script

Special Constraints for Visibility Changes

is_private / workspace_keys updates are subject to the deployment_type constraint: restricted → global will be rejected under the type=2 tenant (E400001). See case-visibility-policy.md。bulk_update_cases goes through the same set of validations.

The user must be reminded to check the status of downstream pipelines

If any of the following are modified, the user must be prompted to check the related pipelines accordingly:

executor-related configuration
Script entry point or run command
Relay output variables
Input environment variable names
Input/output changes caused by the script's internal behavior

Reason:

Pipelines may depend on this case's relay, ordering, or input/output conventions
Platform cases are reusable assets; case changes may affect multiple pipelines

If the user's next step is to fix these reference relationships, switch to testany-pipeline。

Delete

Single Delete

Before calling testany_delete_case , you must first clearly inform the user:

If this case has already been orchestrated into one or more pipelines, the platform will return 409
The case must first be removed from the related pipelines before it can be deleted
If this case is a Git-imported asset, it may also not be possible to delete it manually

Current Limitations：

If there is no ready-made "used by pipeline" query tool on the MCP side, a complete automatic preflight before deletion is not possible
Therefore, the deletion result should be treated as a "constrained operation that may fail" rather than an unconditional direct delete

If the deletion fails and returns 409：

Clearly explain the reason to the user
Suggest going to testany-pipeline to remove the assembly relationship, then retry

Batch Delete

testany_bulk_delete_cases is also subject to the above constraints:

Any case that has already been assembled into a pipeline will cause the deletion to be blocked
Warn about the risk first, then execute

Labels and Directory View

Testany uses case_labels to implement a virtual directory structure:

A case can have multiple labels
Labels must already exist before they can be referenced on a case

Typical flow:

testany_list_labels
If missing,testany_create_label
testany_update_case / testany_bulk_update_cases / testany_bulk_append_cases

Dry Run (Validation)

A dry run only validates whether the case itself is ready, and does not replace pipeline orchestration validation.

Flow:

testany_dry_run_case —— trigger a dry run and get the dry_run_id
testany_get_dry_run_result —— poll until dry_run_status reaches a terminal state
(when needed)testany_get_dry_run_log —— concatenate logUrl + signed curl, and have the agent execute it on your behalf to pull the logs

dry_run_status shares the same set of numeric values as execution status:

Value	Meaning	Terminal State
-1	NOT_STARTED (queued)	No
0	RUNNING	No
1	SUCCESS	Yes
2	FAILURE	Yes
5	CANCELLED	Yes
99	ERROR	Yes

Common misuse: treating 1 (SUCCESS) as RUNNING and polling continuously. Once you see 1 , you should stop, either report success or call testany_get_dry_run_log to check the output.

Typical uses:

After uploading a new script, confirm the case is runnable
After updating required fields, confirm the configuration is complete
On failure, use testany_get_dry_run_log to check stdout / error stack and determine whether it is a script bug or a configuration bug

Common issue handling

Scenario	Handling
The user only has traditional test scenarios, no package	First go to `testany-case-writing`
The user wants to register multiple atomic steps	Create/update cases one by one according to the package inventory
The user wants to form an executable chain	After the case is registered, continue to `testany-pipeline`
The user wants to delete a case	First remind about pipeline assembly constraints and the 409 risk
The user updated relay / input-output related fields	Remind them to check the related pipeline as well

Return format

After the task is completed, report to the user:

Case Key (e.g. A1B2C3D4）
Case name
The atomic responsibility of the case
Whether the script ZIP has been uploaded
Visibility (Global / Private + workspace list)
Whether a dry run has been performed
Next-step suggestions:
- Registration is complete but not yet executable → go to testany-pipeline
- There is already a pipeline but no execution entry point → go to testany-trigger

About this skill