agentleFS
Sign inStart free
LambdaTestLambdaTest/agent-skills/hyperexecute-skill/SKILL.md

hyperexecute-skill

Skill387 starsChanged 3 days agoMITView on GitHub

Operates HyperExecute end-to-end for TestMu AI/LambdaTest cloud test execution: analyze projects, create YAML, validate locally, run CLI jobs, debug failures, and wire CI. Use when the user mentions HyperExecute, hyperexecute.yaml, HyperExecute CLI, autosplit, matrix execution, LambdaTest grid, cloud test runs, CI test orchestration, or migrating Playwright/Cypress/Selenium/Pytest/WebdriverIO tests to HyperExecute.

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 4 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run hyperexecute analyze when the CLI is available.

    line 25
  2. Very specific:

    Create or repair hyperexecute.yaml from the analyze output, project test commands, and templates in reference/.

    line 26
  3. Very specific:

    Run node scripts/doctor.js --config hyperexecute.yaml and node scripts/validate-config.js hyperexecute.yaml.

    line 27
  4. Distinctive:

    Ask before a real cloud job unless the user has explicitly opted into an autonomous HyperExecute session.

    line 29
  5. Distinctive:

    Treat the official HyperExecute CLI as the source of truth for analyze, validation, execution, logs, reports, and artifacts.

    line 34
  6. Very specific:

    Use LT_USERNAME and LT_ACCESS_KEY from local environment variables or CI secrets.

    line 35
  7. Very specific:

    Use --job-secret-file only for extra job-scoped secrets, preferably outside the repo or ignored by .gitignore/.hyperexecuteignore.

    line 36
  8. Distinctive:

    Prefer template-driven YAML over generator scripts because test commands, paths, and payload boundaries are project-specific.

    line 37
  9. Distinctive:

    Run safe local checks automatically.

    line 38

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

HyperExecute Operator

Quick Start

  1. Locate the HyperExecute CLI. If missing, ask before downloading it unless the user explicitly approved an autonomous HyperExecute session.
  2. Run hyperexecute analyze when the CLI is available; use local inspection only as fallback.
  3. Create or repair hyperexecute.yaml from the analyze output, project test commands, and templates in reference/.
  4. Run node scripts/doctor.js --config hyperexecute.yaml and node scripts/validate-config.js hyperexecute.yaml.
  5. Validate with the official CLI: ./hyperexecute --user "$LT_USERNAME" --key "$LT_ACCESS_KEY" --config hyperexecute.yaml --validate.
  6. Ask before a real cloud job unless the user has explicitly opted into an autonomous HyperExecute session.
  7. For failures, download logs/artifacts/reports and use reference/troubleshooting.md.

Operating Rules

  • Treat the official HyperExecute CLI as the source of truth for analyze, validation, execution, logs, reports, and artifacts.
  • Use LT_USERNAME and LT_ACCESS_KEY from local environment variables or CI secrets; never hardcode credentials in YAML or docs.
  • Use --job-secret-file only for extra job-scoped secrets, preferably outside the repo or ignored by .gitignore/.hyperexecuteignore.
  • Prefer template-driven YAML over generator scripts because test commands, paths, and payload boundaries are project-specific.
  • Run safe local checks automatically; run real HyperExecute cloud jobs only after confirmation unless the user opted into autonomous mode.
  • In autonomous mode, validate first, run, inspect output, download logs/artifacts when useful, and retry only for actionable config/environment fixes.

Workflow

  • First run: analyze project, author YAML, run helper checks, run CLI validate, then request confirmation for the cloud job.
  • Debug: reproduce the failing CLI command, add --verbose when useful, 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, and keep downloaded artifacts available for failed jobs.
  • Performance: tune autosplit, concurrency, cache keys, retries, smart ordering, and matrix/hybrid scope after one successful run.

Helper Scripts

  • scripts/doctor.js: checks CLI readiness, credentials, config presence, and optional official validation.
  • scripts/validate-config.js: lightweight config linting for common mistakes before official CLI validation.
  • scripts/build-command.js: prints safe validate/run/debug/download commands using environment variable references.
  • scripts/summarize-artifacts.js: summarizes downloaded logs, reports, and artifacts for triage.

References

  • CLI usage and flags: reference/cli.md
  • YAML patterns: reference/yaml-patterns.md
  • Framework recipes: reference/frameworks.md
  • CI/CD integration: reference/ci-cd.md
  • Security rules: reference/security.md
  • Troubleshooting: reference/troubleshooting.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free