hyperexecute-skill

Name: hyperexecute-skill
Author: LambdaTest

335stars67forks

How to install hyperexecute-skill?

lambdatest/agent-skills/hyperexecute-skill

$npx -y skills add LambdaTest/agent-skills --skill hyperexecute-skill

Installs into the current project.

Summary

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, L

Files · 1

View on GitHub

SKILL.md

1	# HyperExecute Operator
2
3	## Quick Start
4
5	1. Locate the HyperExecute CLI. If missing, ask before downloading it unless the user explicitly approved an autonomous HyperExecute session.
6	2. Run `hyperexecute analyze` when the CLI is available; use local inspection only as fallback.
7	3. Create or repair `hyperexecute.yaml` from the analyze output, project test commands, and templates in `reference/`.
8	4. Run `node scripts/doctor.js --config hyperexecute.yaml` and `node scripts/validate-config.js hyperexecute.yaml`.
9	5. Validate with the official CLI: `./hyperexecute --user "$LT_USERNAME" --key "$LT_ACCESS_KEY" --config hyperexecute.yaml --validate`.
10	6. Ask before a real cloud job unless the user has explicitly opted into an autonomous HyperExecute session.
11	7. For failures, download logs/artifacts/reports and use `reference/troubleshooting.md`.
12
13	## Operating Rules
14
15	- Treat the official HyperExecute CLI as the source of truth for analyze, validation, execution, logs, reports, and artifacts.
16	- Use `LT_USERNAME` and `LT_ACCESS_KEY` from local environment variables or CI secrets; never hardcode credentials in YAML or docs.
17	- Use `--job-secret-file` only for extra job-scoped secrets, preferably outside the repo or ignored by `.gitignore`/`.hyperexecuteignore`.
18	- Prefer template-driven YAML over generator scripts because test commands, paths, and payload boundaries are project-specific.
19	- Run safe local checks automatically; run real HyperExecute cloud jobs only after confirmation unless the user opted into autonomous mode.
20	- In autonomous mode, validate first, run, inspect output, download logs/artifacts when useful, and retry only for actionable config/environment fixes.
21
22	## Workflow
23
24	- First run: analyze project, author YAML, run helper checks, run CLI validate, then request confirmation for the cloud job.
25	- Debug: reproduce the failing CLI command, add `--verbose` when useful, download logs/artifacts/reports, fix one cause at a time.
26	- CI: use CI secrets, add a validation stage before execution, set `CI=true` for quieter logs, and keep downloaded artifacts available for failed jobs.
27	- Performance: tune `autosplit`, `concurrency`, cache keys, retries, smart ordering, and matrix/hybrid scope after one successful run.
28
29	## Helper Scripts
30
31	- `scripts/doctor.js`: checks CLI readiness, credentials, config presence, and optional official validation.
32	- `scripts/validate-config.js`: lightweight config linting for common mistakes before official CLI validation.
33	- `scripts/build-command.js`: prints safe validate/run/debug/download commands using environment variable references.
34	- `scripts/summarize-artifacts.js`: summarizes downloaded logs, reports, and artifacts for triage.
35
36	## References
37
38	- CLI usage and flags: [reference/cli.md](reference/cli.md)
39	- YAML patterns: [reference/yaml-patterns.md](reference/yaml-patterns.md)
40	- Framework recipes: [reference/frameworks.md](reference/frameworks.md)
41	- CI/CD integration: [reference/ci-cd.md](reference/ci-cd.md)
42	- Security rules: [reference/security.md](reference/security.md)
43	- Troubleshooting: [reference/troubleshooting.md](reference/troubleshooting.md)

People who liked this also viewed

6 picks

Type

hyperexecute-skill

335stars67forks

View on GitHub

How to install hyperexecute-skill?

lambdatest/agent-skills/hyperexecute-skill

$npx -y skills add LambdaTest/agent-skills --skill hyperexecute-skill

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# HyperExecute Operator
2
3	## Quick Start
4
5	1. Locate the HyperExecute CLI. If missing, ask before downloading it unless the user explicitly approved an autonomous HyperExecute session.
6	2. Run `hyperexecute analyze` when the CLI is available; use local inspection only as fallback.
7	3. Create or repair `hyperexecute.yaml` from the analyze output, project test commands, and templates in `reference/`.
8	4. Run `node scripts/doctor.js --config hyperexecute.yaml` and `node scripts/validate-config.js hyperexecute.yaml`.
9	5. Validate with the official CLI: `./hyperexecute --user "$LT_USERNAME" --key "$LT_ACCESS_KEY" --config hyperexecute.yaml --validate`.
10	6. Ask before a real cloud job unless the user has explicitly opted into an autonomous HyperExecute session.
11	7. For failures, download logs/artifacts/reports and use `reference/troubleshooting.md`.
12
13	## Operating Rules
14
15	- Treat the official HyperExecute CLI as the source of truth for analyze, validation, execution, logs, reports, and artifacts.
16	- Use `LT_USERNAME` and `LT_ACCESS_KEY` from local environment variables or CI secrets; never hardcode credentials in YAML or docs.
17	- Use `--job-secret-file` only for extra job-scoped secrets, preferably outside the repo or ignored by `.gitignore`/`.hyperexecuteignore`.
18	- Prefer template-driven YAML over generator scripts because test commands, paths, and payload boundaries are project-specific.
19	- Run safe local checks automatically; run real HyperExecute cloud jobs only after confirmation unless the user opted into autonomous mode.
20	- In autonomous mode, validate first, run, inspect output, download logs/artifacts when useful, and retry only for actionable config/environment fixes.
21
22	## Workflow
23
24	- First run: analyze project, author YAML, run helper checks, run CLI validate, then request confirmation for the cloud job.
25	- Debug: reproduce the failing CLI command, add `--verbose` when useful, download logs/artifacts/reports, fix one cause at a time.
26	- CI: use CI secrets, add a validation stage before execution, set `CI=true` for quieter logs, and keep downloaded artifacts available for failed jobs.
27	- Performance: tune `autosplit`, `concurrency`, cache keys, retries, smart ordering, and matrix/hybrid scope after one successful run.
28
29	## Helper Scripts
30
31	- `scripts/doctor.js`: checks CLI readiness, credentials, config presence, and optional official validation.
32	- `scripts/validate-config.js`: lightweight config linting for common mistakes before official CLI validation.
33	- `scripts/build-command.js`: prints safe validate/run/debug/download commands using environment variable references.
34	- `scripts/summarize-artifacts.js`: summarizes downloaded logs, reports, and artifacts for triage.
35
36	## References
37
38	- CLI usage and flags: [reference/cli.md](reference/cli.md)
39	- YAML patterns: [reference/yaml-patterns.md](reference/yaml-patterns.md)
40	- Framework recipes: [reference/frameworks.md](reference/frameworks.md)
41	- CI/CD integration: [reference/ci-cd.md](reference/ci-cd.md)
42	- Security rules: [reference/security.md](reference/security.md)
43	- Troubleshooting: [reference/troubleshooting.md](reference/troubleshooting.md)

People who liked this also viewed

6 picks

Type