opentest

name

opentest

description

End-to-end OpenTest QA workflow for turning requirement documents into staged requirement artifacts, Chinese test proposals, Chinese requirement analysis, Chinese test points, executable case JSON with Chinese display fields, Excel exports, execution reports, and archive packages. Use when Codex needs to run or maintain the OpenTest workflow, especially for commands such as doctor, prepare requirement, generate cases, validate cases, generate Excel, generate report, or run the full staged pipeline.

OpenTest

Use this skill to run the OpenTest staged QA workflow as a standalone capability pack.

Start Here

1. Run the workflow from the repository root.
2. Keep generated artifacts under output/<stage>/; do not write helper scripts into output/.
3. Treat scripts/ as deterministic helpers and templates/ as prompt scaffolding.
4. Use .claude/commands/ as compatibility entrypoints only; prefer the guidance in this skill and the reference files below.
5. Before overwriting an existing stage directory, snapshot it into output/98_history/.

Core Workflow

1. Run health checks first. See references/workflow.md.
2. Decide whether the requirement is too large for one pass; split large requirements into smaller packages first.
3. Prepare the selected requirement package into output/00_requirement/.
4. Create and revise the proposal under output/01_proposal/.
5. Produce analysis and stop unless the case-generation gate passes.
6. Generate test points, then executable case JSON with Chinese display fields by priority.
7. Validate after every major case-editing step.
8. Export Excel, generate the report, and archive only after validation passes.

Quality Rules

• Never skip the analysis readiness gate before generating cases.
• Never push an oversized multi-module requirement through the full pipeline in one pass when it should be split first.
• Never mix P0/P1/P2 workflow prefixes with different case priorities.
• Keep .zh-CN.md files as the only Markdown source of truth for downstream stages.
• Preserve IDs, enum values, English JSON keys, and case count when adding Chinese display fields.
• Every executable case must include a non-empty oracle.

Read references/quality-gates.md before case generation, localization, or merge work.

References

• references/workflow.md: stage order, stop conditions, and recommended commands
• references/quality-gates.md: readiness checks, case integrity rules, and localization constraints
• references/artifacts-and-schema.md: output folders, key artifacts, and stable case JSON schema

Deterministic Helpers

• scripts/doctor.ps1
• scripts/opentest.ps1
• scripts/generate_excel.py
• scripts/generate_report.py
• scripts/validate_cases.py
• scripts/archive.py
• scripts/snapshot_stage.py

Run these helpers instead of rewriting the same export, report, validation, or archive logic.

Compatibility

Legacy slash-command prompts remain under .claude/commands/. Keep them aligned with this skill when the workflow changes.

/opentest Usage Modes

Use /opentest as the single workflow entry. In Codex, it is normal that you see only the top-level opentest skill instead of a long list of opentest-* slash commands.

Mode 1: Step-by-Step Mode

Use this mode for daily work, large requirements, or any case where you want to review each stage before continuing.

Recommended sequence:

1. /opentest-doctor
2. /opentest-prepare-requirement <requirement file, folder, or DingTalk link>
3. /opentest-new output/00_requirement/requirement_text.zh-CN.md
4. /opentest-revise-proposal output/01_proposal/test_proposal.zh-CN.md when the proposal still needs tightening
5. /opentest-analysis output/01_proposal/test_proposal.zh-CN.md
6. Stop unless the analysis gate passes:
   • Case Generation Ready: Yes
   • Readiness Score >= 90
7. /opentest-points output/02_analysis/requirement_analysis.zh-CN.md
8. /opentest-generate-cases output/02_analysis/requirement_analysis.zh-CN.md P0
9. /opentest-generate-cases output/02_analysis/requirement_analysis.zh-CN.md P1
10. /opentest-generate-cases output/02_analysis/requirement_analysis.zh-CN.md P2
11. /opentest-generate-cases output/02_analysis/requirement_analysis.zh-CN.md all
12. /opentest-validate-cases output/04_cases/test_cases.json
13. /opentest-generate-excel output/04_cases/test_cases.json output/04_cases/test_cases.xlsx
14. /opentest-report output/04_cases/test_cases.xlsx
15. /opentest-archive

When to prefer this mode:

• The requirement is large or mixed across multiple modules
• You expect proposal or analysis revisions
• You want snapshots and review points at each stage
• You want to generate and validate P0/P1/P2 separately

Mode 2: One-Pass Mode

Use this mode only for small, focused requirements that are already clear and are unlikely to fail the readiness gate.

Recommended sequence:

1. /opentest-doctor
2. Decide quickly whether the requirement should be split first
3. /opentest-run-all <requirement file, folder, or DingTalk link>

What this mode should do:

• prepare the requirement package
• generate proposal and analysis
• stop automatically if the analysis gate fails
• generate test points and cases when the gate passes
• validate merged cases
• export Excel and generate the report

When to prefer this mode:

• Single-module requirement
• Short requirement text
• Stable business flow with low ambiguity
• You want the fastest end-to-end output

Picking The Right Mode

Choose Step-by-Step Mode when quality control matters more than speed. Choose One-Pass Mode when speed matters and the requirement is small enough to stay stable through the full pipeline.

If you are unsure, default to Step-by-Step Mode.