From testany-bot
Decomposes test scenarios into Testany platform cases, selects executors, and generates registrable scripts, metadata, and ZIP packages.
npx claudepluginhub testany-io/testany-agent-skills --plugin testany-botThis skill uses the workspace's default tool permissions.
将传统测试场景拆解为 **Testany platform cases**，并生成可注册到 Testany 平台的脚本、metadata 和 ZIP 包。
Registers 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 test cases from PRD documents or user requirements, covering functional, edge case, error handling, and state transition scenarios. For QA planning and test documentation.
Generates production-ready BDD/Gherkin test cases from acceptance criteria, PRD paths, Jira IDs, or interactively using ISTQB techniques. Use for QA test specs.
Share bugs, ideas, or general feedback.
将传统测试场景拆解为 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 的示例与文档不一致时，以文档为准：