Orchestrate HyperExecute cloud test runs end-to-end

A skill for operating HyperExecute end-to-end for TestMu AI/LambdaTest cloud test execution: analyzing projects, creating YAML config, validating locally, running CLI jobs, debugging failures, and wiring CI. The quick-start flow: locate the HyperExecute CLI (asking before downloading it unless the user has approved an autonomous session), run hyperexecute analyze when the CLI is available (falling back to local inspection otherwise), create or repair hyperexecute.yaml from the analyze output plus project test commands and bundled templates, run the helper scripts doctor.js --config hyperexecute.yaml and validate-config.js hyperexecute.yaml, then validate with the official CLI's --validate flag using LT_USERNAME/LT_ACCESS_KEY - and ask before running a real cloud job unless the user has explicitly opted into autonomous mode. On failure, download logs/artifacts/reports and consult reference/troubleshooting.md. Operating rules: treat the official CLI as the source of truth for analyze/validation/execution/logs/reports/artifacts; source credentials from environment variables or CI secrets, never hardcode them in YAML or docs; use --job-secret-file only for extra job-scoped secrets kept outside the repo or gitignored; prefer template-driven YAML over generator scripts since test commands and paths are project-specific; run safe local checks automatically but gate real cloud jobs on confirmation unless autonomous mode is on, in which case validate first, run, inspect output, download artifacts, and retry only for actionable config/environment fixes. The workflow covers four scenarios: first run (analyze, author YAML, helper checks, CLI validate, confirm before the cloud job), debugging (reproduce the failing command with --verbose, download logs/artifacts/reports, fix one cause at a time), CI (use CI secrets, add a validation stage before execution, set CI=true for quieter logs, keep artifacts available for failed jobs), and performance tuning (autosplit, concurrency, cache keys, retries, smart ordering, matrix/hybrid scope - only after one successful run). Four helper scripts support this: doctor.js checks CLI readiness/credentials/config presence and optionally runs official validation; validate-config.js does lightweight config linting before the official CLI validation; build-command.js prints safe validate/run/debug/download commands using environment-variable references rather than literal secrets; summarize-artifacts.js summarizes downloaded logs/reports/artifacts for triage. Deeper references cover CLI usage/flags, YAML patterns, framework-specific recipes, CI/CD integration, and security rules.

Use it when the user mentions HyperExecute, hyperexecute.yaml, the HyperExecute CLI, autosplit, or matrix execution - for analyzing a project, creating or repairing config, running cloud test jobs, debugging failures, or wiring CI.

Given a test project, it produces a validated hyperexecute.yaml, safe CLI commands for validation/execution/debugging, and (after explicit confirmation for real cloud jobs) downloaded logs, artifacts, and reports for triage.

hyperexecute analyze
./hyperexecute --user "$LT_USERNAME" --key "$LT_ACCESS_KEY" --config hyperexecute.yaml --validate

Uses the official HyperExecute CLI as the source of truth, plus four bundled helper scripts (doctor.js, validate-config.js, build-command.js, summarize-artifacts.js) for local checks before invoking real cloud execution.

QA and DevOps engineers running cloud test execution on LambdaTest's HyperExecute who want project analysis, safe config authoring and local validation, and CI wiring - with cloud jobs and cost-incurring actions always gated behind explicit user confirmation unless autonomous mode is on.