Gradle run

Core principle

Treat complete Gradle output as a temporary, sensitive artifact. Every agent-initiated Gradle command runs through the compact-output wrapper; never stream, tee, paste, or reopen a full build log.

Every create, run, status, and finish invocation is the entire shell command for that tool call. Prefixes, assignments, conditionals, pipes, command chains, and follow-up inspection invalidate lifecycle evidence even when Gradle succeeds.

Procedure

1. Classify the request. Reuse a current successful result when unchanged source and inputs already answer the question. A focused task that validates another change is incidental; build/check/warning/failure work is a Gradle-centered workflow.

2. Resolve this skill directory. If python3 or scripts/gradle_run.py is unavailable (a failing standalone create shows this), stop and report that prerequisite; never run Gradle directly as a fallback. Invoke the project's designated entrypoint (normally ./gradlew) as provided; do not read its source to second-guess it or substitute another launcher script.

3. Create one workflow before its first command and retain its opaque ID:

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

   Run create, each run, and finish as standalone shell commands. Do not combine one with ls, test, variable setup, git, rg, &&, ;, a pipe, or a newline containing another command. If create fails, retry a fresh standalone create before any run. Use the wrapper exclusively; it supplies --console=plain and --no-scan unless console behavior was selected or the user authorized --scan. Add --warning-mode all only for warning discovery or an explicit request. If run or finish reports workflow is busy, inspect status and wait for the owner; keep one execution owner and avoid a duplicate build.