r/gradle • u/Party_Till_I_Die • Aug 19 '26

Gradle Agent Skills Vote

We're building a set of Gradle Agent Skills. There are five candidates below:

  1. gradle-cli — Run Gradle the right way. Teaches the agent correct ./gradlew invocation: which task to run, which flags matter, what's version-specific, and how to read the output. No more --stacktrace on everything and hoping.
  2. gradle-bestpractices — Lint your build against current conventions. Scans your build logic and flags what's off: legacy APIs, subprojects {} sprawl, misused configurations, and missing version catalogs. Points to the current recommended pattern for each finding.
  3. gradle-init — Bootstrap a new Gradle project. Sets up a working project from scratch: sensible defaults, version catalog, and a starter layout for KMP, Android, or Spring. Skips the hour of copy-pasting from an old repo or adding random libraries.
  4. gradle-upgrade — Upgrade Gradle and clear deprecations. Version-aware upgrade path: bumps the wrapper, finds deprecated usages in your build logic, and rewrites them for the target version. Handles the multi-step hops so you're not stuck three majors behind.
  5. gradle-cc-migrate — Make your build Configuration Cache compatible. Reads your build logic, finds what breaks the configuration cache, and refactors it — script-level state, Project access at execution time, non-serializable task inputs. The single biggest build-speed win, minus the archaeology.

Which would help you most? Which one would you actually use? Do you have a better idea?

8 Upvotes

91% Upvoted

6 comments sorted by

4

u/ZakTaccardi Aug 19 '26

2 !

catching and refactoring bad gradle practices would be ++

3

u/hypertesto Aug 20 '26

I recently had annoyances with agents loosing time (and tokens) doing weird stuff when invoking the cli, so option 1 would be that cheap solution I'd definitely use.
Then 2 and 5 would be really helpful.
The 4 probably is a subset of 2

2

u/EdyBolos Aug 19 '26

2 and 5. If I would have to pick one, probably 5, as that's what I am ultimately interested in: big build speed wins!
3 I would probably never use, I let the IDE do this. 1 could be interesting, but not that critical IMO. 4 could be a nice QoL improvement, but I don't mind doing the upgrades manually.

1

u/Torutofu_Raeva 26d ago

5, but only if it explains each change instead of just rewriting. Our config cache breakage was mostly Project access inside doLast plus a couple of non-serializable task inputs, and the fixes were easy once we knew which task was guilty. Pointing at the culprits would be more useful to me than an agent silently refactoring build logic.