Stats
Actions
Tags
From testany-bot
Decomposes test scenarios into Testany platform cases, selects executors, and generates registrable scripts, metadata, and ZIP packages.
How this skill is triggered — by the user, by Claude, or both
Slash command
/testany-bot:testany-case-writingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
将传统测试场景拆解为 **Testany platform cases**，并生成可注册到 Testany 平台的脚本、metadata 和 ZIP 包。
将传统测试场景拆解为 Testany platform cases，并生成可注册到 Testany 平台的脚本、metadata 和 ZIP 包。
用户输入: $ARGUMENTS
testany-case 作为推荐注册入口，把 testany-pipeline 作为推荐编排入口。按以下优先级选择输入模式：
Testany Automation Handoff
testany-engTestany Automation Handoff.status = ready | partial如果输入来自 Test Spec，优先参考：
../../../testany-eng/references/testany-automation-handoff-contract.mdTestany Automation Handoff section 中的 scenario_groupssource_case_ids、recommended_executor、platform_case_strategy若输入 Test Spec 仍是 draft / in_review：
testany-eng 的 /test-reviewer在开始之前，先按 automation-model.md 理解对象边界：
Plan / Manual Trigger / Gatekeeper，作用于 pipeline，而不是 case。重要结论：
test-spec、Testany Automation Handoff、用户自然语言、现有测试设计文档testany-casetestany-pipelinetestany-trigger如果输入来自 Test Spec，先检查：
approvedTestany Automation HandoffTestany Automation Handoff.status 是 ready、partial 还是 not_planned处理规则：
ready：把 handoff 当作第一优先输入partial：把 handoff 当作基线，并集中追问 open_questionsnot_planned：默认不要继续；只有用户明确要求覆盖该决定时才继续优先收集以下信息：
test-spec、Testany Automation Handoff、用户口述，还是已有测试文档必须先判断一个传统测试场景在 Testany 平台上应拆成几个 platform cases。
若上游已经给出 Testany Automation Handoff：
scenario_groupsrecommended_executorplatform_case_strategy优先拆成多个 platform cases 的情况：
expect: fail可以保持为单个 platform case 的情况：
每个 platform case 至少要产出：
namedescriptioncase_labelsexecutorpath 或 commandenvironment_variablestype=output 的输出变量完成 case package 后，必须显式说明：
source_case_idstestany-pipeline 继续编排强制规则：
testany-casetestany-pipelinetestany-trigger对每个 platform case 给出：
source_case_idssingle-case runnable?：是否只是单个原子步骤pipeline required：默认 yesdependencies：A -> B -> Crelay map：例如 LOGIN.AUTH_TOKEN -> SUBSCRIBE.AUTH_TOKENbranching：是否存在 whenFailed / expect: failtestany-casetestany-pipelinePlatform case 类型
├─ API 调用 / Python 优先 → PyRes ✓
├─ API 调用 / 不想写代码 → Postman
├─ UI / E2E 步骤 → Playwright
└─ Java 项目测试 → Maven 或 Gradle
根据选择的 Executor，参考对应模板：
| Executor | 模板文件 | 适用场景 |
|---|---|---|
| PyRes | pyres.md | Python API 测试（推荐） |
| Postman | postman.md | 快速 API 验证 |
| Playwright | playwright.md | UI/E2E 测试 |
| Maven/Gradle | maven.md | Java 项目测试 |
注意：
executor是后端严格字符串。本 skill 涉及的取值为：pyres,postman,playwright,maven,gradle（平台还支持python,jmeter）。
| 类型 | 用途 | 示例 |
|---|---|---|
env | 输入/普通配置（包括 relay 输入） | API_BASE_URL, AUTH_TOKEN |
output | Relay 输出 | ACCESS_TOKEN, USER_ID |
约束（与平台校验一致）：
type仅支持env与outputname必须以大写字母开头，只能包含大写字母、数字、下划线；同一 case 内必须唯一name/value不能为空或仅空白字符；如需表达“空值”，请显式填-- 敏感凭证请使用 Secure key reference 绑定，并在代码中通过
TESTANY_SECRETS_SERVICE获取
Relay 是 pipeline 层编排 + case 层输出配置 的组合能力。只有同时满足两端约束才有效。
type: output 的变量TESTANY_OUTPUT_RELAY_SERVICEtype: env 的变量testany-pipeline 在 pipeline YAML 中配置 relay.key 与 relay.refKey如果你已经识别出 relay 需求，必须在输出中明确告诉下游：
testany-pipeline 进行 relay 编排交付时必须告诉用户：
testany-pipeline/testany-case 和 /testany-pipelinesource_case_ids 与 scenario_groups如果本地 references 不足以解决问题，请查阅 Testany 文档中心；当本 skill 的示例与文档不一致时，以文档为准：
npx claudepluginhub testany-io/testany-agent-skills --plugin testany-botRegisters prepared Testany platform case packages and manages CRUD operations on metadata, scripts, and lifecycle via remote API calls. For handling reusable automation steps post-case-writing.
Generates, evaluates, audits, and normalizes QA test cases to RAVN standards with four modes: generate, evaluate, audit, and normalize.
Generates BDD/Gherkin test cases from acceptance criteria using ISTQB techniques (equivalence partitioning, BVA, decision tables). Supports direct text, PRD files, Jira stories, and OpenAPI contracts.