Classify the request. A focused Gradle command that only validates another implementation change is incidental validation. A build, check, warning-cleanup, or failure-investigation loop is a Gradle-centered workflow.

Resolve this installed skill's directory and confirm and are available. If either is unavailable, stop before running Gradle directly and report the failed prerequisite.

Create one wrapper workflow before the first command:

python3 <skill-dir>/scripts/gradle_run.py create

Retain the returned opaque workflow identifier. Use only this wrapper to run Gradle. It adds and unless the command already selects console behavior or the user explicitly authorized . For warning discovery, include in the Gradle command; otherwise include it only when the user asks for it. Treat a result as an ownership violation: wait for the active run or correct the owner instead of starting another command or finishing the workflow concurrently.

For incidental validation, stay in the current agent and run the smallest owning task with a non-empty verification question:

python3 <skill-dir>/scripts/gradle_run.py run \
  --workflow <id> --scope targeted \
  --question "Does :module:test pass after this change?" -- \
  ./gradlew :module:test

Choose the task from the verification question's acceptance claim. If it asks whether fixture tests pass, run ; do not substitute compilation merely because the edit is Kotlin.

Read only the bounded JSON summary and continue from its failed tasks, fingerprints, and excerpt. Do not inspect its log unless a user explicitly requests that artifact. In the final report, repeat the verification question and answer it from that bounded summary, explicitly stating that the wrapper ran the task; do not describe it as a direct Gradle invocation. The summary and ledger redact common credential patterns; the retained full log is intentionally raw and can contain secrets, so never paste or reopen it as a substitute for the summary.

For a Gradle-centered workflow, create one fresh portable Solver diagnostic owner. Report its model and reasoning only if the runtime exposes them. Give it read-only repository access and ownership of wrapper runs and diagnosis; it must not edit source, tests, configuration, or generated project files, and it must not delegate Gradle ownership. The parent owns every repository edit. If a fresh persistent owner cannot be created, stop rather than make the parent run the workflow loop.

Have that owner reuse prior actionable summaries, group warnings and failures by fingerprint, and return exact file or line evidence plus the narrowest next command. Prefer source or compiler failure fingerprints over a following generic Gradle failure block. Run an initial broad command only when existing targeted evidence cannot answer the recorded question. The owner stays available for the whole workflow and verifies each parent change with the same wrapper and the narrowest applicable task.

Record only for aggregate project checks. Give every broad run a distinct question that a narrower task cannot answer. The wrapper flags repeated commands and primary failure fingerprints; if the primary source or compiler failure repeats, stop the run loop. Inspect the reported source line and its nearby declaration, import, or receiver context before proposing a fix or another Gradle command; then revise the diagnosis from that evidence. In the final diagnosis, name that focused inspection as the next action; do not say to fix the source before it happens. If the wrapper is interrupted, use its recorded signal and retained log; it stops the isolated Gradle process group or Windows process tree, extracts bounded diagnostics from the partial log, and makes the ledger durable before returning. Only logs still represented by the bounded recent-run ledger are retained.

Finish after the requested broad validation passes, or report unresolved warning fingerprints and the reason validation cannot continue. Summarize the compact ledger, including each verification question and its bounded answer, then finish it:

python3 <skill-dir>/scripts/gradle_run.py finish --workflow <id>

In the final report, state that the workflow finished after that summary and that cleanup removed only its wrapper-owned logs.

Finish retains small marker and lock metadata so repeating the same finished identifier is idempotent while an unknown identifier fails closed. If finish cannot validate the managed identifier or the workflow is active, leave all files in place and report the failure. This skill does not constrain unrelated review, exploration, implementation, or other subagents.