skills/xts-generator/SKILL.md
--- name: xts-generator description: Generate OpenHarmony XTS (Compatibility Test Suite) test cases from API documentation. Use when generating or modifying XTS test files (.ets) for OpenHarmony API testing, including: (1) Creating new test files from API documentation, (2) Adding test cases for new methods, (3) Generating tests for enum types, (4) Creating optional parameter combination tests, (5) Writing exception/boundary test cases. This skill enforces strict type safety (no `any`/`unknown`)
npx skillsauth add openharmonyinsight/openharmony-skills skills/xts-generatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Generate OpenHarmony XTS test cases following strict coding standards and test patterns.
When generating XTS test cases, consult these references:
From Markdown API documentation (js-apis-{module}.md), extract:
For each API method, generate test cases following these scenarios:
| Scenario | Number | Description |
|----------|--------|-------------|
| Normal | 0100 | Required - Normal/expected call |
| Null | 0200 | Exception - null parameter |
| Undefined | 0201 | Exception - undefined parameter |
| Optional combos | 0500+ | For N optional params, generate 2^N tests |
| Enum | 0900+ | One test per enum type |
| File path | 2000+ | For file APIs with path parameter |
| File URI | 2100+ | For file APIs with URI parameter |
SUB_{子系统缩写}_{模块名}_{方法名}_{场景}_{序号}
Examples:
SUB_MM_MechanicManager_on_0100 - Normal callSUB_MM_MechanicManager_on_Null_0200 - Null parameterSUB_MM_MechanicManager_EnumType_0900 - Enum test// CORRECT - Explicit types
let result: string = methodName(param);
let callback: Callback = (data: DataType) => { };
// FORBIDDEN
let result = methodName(param); // No type
let data: any = result; // any type
let value: unknown = param; // unknown type
let x = result as any; // as any
// CORRECT - One error code only
catch (error) {
expect(error.code == 401).assertTrue();
}
// FORBIDDEN - Multiple error codes
expect(error.code == 401 || error.code == 402).assertTrue();
expect(error.code == 401 && error.code == 402).assertTrue();
All comments, logs, and JSDoc must be in English.
/**
* @tc.number SUB_MM_ModuleName_methodName_0100
* @tc.name SUB_MM_ModuleName_methodName_0100
* @tc.desc Test normal call scenario for methodName
* @tc.size MediumTest
* @tc.type Function
* @tc.level Level 0
*/
it('SUB_MM_ModuleName_methodName_0100', TestType.FUNCTION | Size.MEDIUMTEST | Level.LEVEL0, async () => {
console.info("-----------------SUB_MM_ModuleName_methodName_0100 begin-----------------");
try {
let result: ReturnType = moduleName.methodName(param1, param2);
expect(result != null).assertTrue();
} catch (error) {
console.error('failed, code is ' + error.code + ', message is ' + error.message);
expect(error.code == errorCode).assertTrue();
}
console.info("-----------------SUB_MM_ModuleName_methodName_0100 end-----------------");
});
Generated .ets test file with:
any/unknowntesting
--- name: ohos-req-value-decision description: Use after review meeting to record decision and route to next step. Triggers: 评审决策纪要, 评审结论回流, value decision, 评审接纳, 评审不接纳, 评审退回, 下次重新上会. Do NOT use for feature baseline (ohos-req-feature-baseline), review gate checks (ohos-req-review-gate), or IR generation (ohos-req-feature-to-ir). metadata: author: openharmony scope: common stage: requirements capability: value-decision version: 0.3.0 status: draft tags: - sdd - requirements
development
Use when converting an OpenHarmony requirement document, spec, or design proposal into an OpenHarmony review slide deck (需求评审 / 需求变更评审 / 设计评审 PPTX) — produces the fixed OpenHarmony-branded review-deck structure (OH logo on every page) with architecture/flow diagrams and field tables. Triggers on "需求评审PPT", "需求变更评审", "把需求文档转成评审PPT", "spec转评审PPT", "requirement/spec to review deck". NOT for arbitrary or generic slide decks unrelated to OpenHarmony requirement/design review.
testing
Use when performing the Phase 0 Step 0.5 Review Ready Gate on a 04-feature.md, especially when the user says "evaluate gate", "review readiness", "feature ready?", "should we generate IR", or when the ohos-req-intake-orchestration main session needs a structured Ready / Conditional Ready / Not Ready judgment instead of doing the check inline. Reads 01-04, runs seven fixed checks plus a conditional-items check, and returns a machine-readable JSON summary plus a human-readable table that the main session can route on. Do NOT use for feature baseline generation (ohos-req-feature-baseline), value decision recording (ohos-req-value-decision), or IR generation (ohos-req-feature-to-ir).
testing
--- name: ohos-req-requirement-intake description: Use when importing an OHOS requirement into Phase 0.1, especially for 01-requirement.md, requirement intake, background, user value, scenarios, scope, FR/NFR, affected modules, or priority. Triggers: 需求导入, 01-requirement, 需求基线, RR单号. Do NOT use for feasibility analysis (ohos-req-feasibility-analysis), architecture decision (ohos-req-arch-decision), or feature baseline (ohos-req-feature-baseline). metadata: author: openharmony scope: common