run-tests
Run a Gradle project's tests by test type or module — unit, integration, or all. Use this skill whenever the user wants to run, re-run, or check the project's tests (e.g. "run the unit tests", "run all tests", "run the integration tests for the vet module", "did the tests pass?").
Savant verdict: Review advised
Security analysis or source-hub review identified patterns requiring attention.
Live evaluation
Not evaluated yet. Workspaces can request a live evaluation.
Security assessment
Scan pending.
Structure
- No license declaredConfirm you may reuse this skill before importing it into your repository.
- The source hub's security checks flagged this skillGen Agent Trust Hub: warn (The skill manages Gradle test execution through the IDE or console. It contains potential security risks including command injection vulnerabilities in the shell fallback path and XML External Entity (XXE) vulnerabilities in the test result parsing script.)
SKILL.md
--- name: run-tests description: >- Run a Gradle project's tests by test type or module — unit, integration, or all. Use this skill whenever the user wants to run, re-run, or check the project's tests (e.g. "run the unit tests", "run all tests", "run the integration tests for the vet module", "did the tests pass?"). --- # Run tests ## Test types and modules Test **types** (extend as a project needs): | Type | Meaning | Typical Gradle tasks | |------|---------|----------------------| | `unit` | fast tests, no Spring/Docker | `test` | | `integration` | Spring + Testcontainers | `testIntgr` or `integrationTest` | | `all` | everything | `test` + `testIntgr` | A **module** is a Gradle subproject; prefix its path onto the task (`:web:test`). A module combines with a type on the fly — build that configuration when first asked and remember it. ## Pick the path Probe FIRST, here, before loading either reference — so you read only the one you need. Call `steroid_list_projects` (via ToolSearch if the tool schema isn't loaded): - It returns the repo you're in → **IDE path**: note that entry's `project_name` and follow `references/ide.md` (runs tests inside the IDE, each in its own Run tab). Its steps start already knowing the `project_name` — don't re-probe. - It fails, or the repo isn't listed → **console Gradle path**: follow `references/gradle.md` (runs Gradle in the console) and tell the user you used the console fallback because the IDE wasn't reachable. Both paths end by collecting the result **in a Haiku subagent** that returns the `references/report.md` report and nothing else — keeping the long test/build output out of the main context. Act on that report in the main model.