skills.rest
astroville
astrovilleOFFICIAL
Explore all skills by this author →
GitHub

groovy-stack

Guides Groovy application code, Gradle build logic, DSLs, and Spock testing practices.

Updated Apr 20, 2026
Search Tags:#testing#code review#jvm#gradle#dsl#groovy#spock
One-click install
npx skills add https://github.com/astroville/sprout --skill groovy-stack-astroville
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: groovy-stack
Source: https://github.com/astroville/sprout/tree/main/.claude/skills/groovy-stack
Command: npx skills add https://github.com/astroville/sprout --skill groovy-stack-astroville

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Groovy's dynamic features make it easy to write code that fails only at runtime or becomes hard to maintain. This Skill provides guardrails for writing readable Groovy application code, keeping Gradle build logic focused, and expressing behavior clearly with Spock tests. ## Core Features & Use Cases - Readable Groovy guidance: Prefers explicit, maintainable code over magic-heavy dynamic behavior and warns about implicit coercion and runtime-only failures. - Gradle and DSL discipline: Keeps build logic and custom DSL changes focused and easy to reason about, avoiding spread of custom build logic without strong justification. - Spock-oriented testing: Encourages using Spock or existing test patterns to express behavior clearly. - Use Case: When adding a new Gradle task or refactoring a Groovy service that calls typed Java APIs, apply these guardrails to keep the change explicit, typed where it matters, and covered by clear Spock specifications. ## Quick Start Review my Groovy class and Gradle build script using the groovy-stack guidance and suggest changes that reduce dynamic behavior and improve Spock test coverage.

Frequently Asked Questions about groovy-stack

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write maintainable Groovy code instead of dynamic-heavy code?▼

Prefer readable, explicit Groovy over magic-heavy dynamic behavior. Be careful with implicit coercion and runtime-only failures, and be explicit wherever Groovy interacts with typed JVM APIs so errors surface early.

How should I test Groovy code with Spock?▼

Use Spock specifications or existing test patterns to express behavior clearly. Structure tests around the behavior of the code rather than implementation details, keeping them readable as documentation.

When is custom Gradle build logic justified in Groovy projects?▼

Custom build logic is justified only with a strong reason. Keep Gradle and DSL changes focused and easy to reason about, and avoid spreading custom logic across the build without clear necessity.

Why does Groovy code fail only at runtime instead of compile time?▼

Groovy's dynamic dispatch and implicit coercion defer many checks to runtime, so type mismatches and missing methods surface only during execution. Being explicit at typed JVM API boundaries reduces these runtime-only failures.

What are the limitations of dynamic Groovy shortcuts?▼

Dynamic shortcuts reduce maintainability and hide errors until runtime. They make code harder to reason about and refactor, so they should be avoided in favor of explicit, readable implementations.

Related Skills

Explore More Software Engineering Skills→
dallaydallay
9

kotlin-multiplatform

Guide Kotlin Multiplatform architecture decisions for source set placement and expect/actual patterns.

Official
Advanced
apacheapache
2.9k

groovy-developer

Guide Groovy 4 development with metaprogramming, DSL design, and Spock testing.

Official
Advanced
apacheapache
2.9k

violation-fixer

Runs and fixes CodeNarc, Checkstyle, PMD, and SpotBugs violations across grails-core Gradle modules.

Official
Intermediate
androidandroid
7.1k

agp-9-upgrade

Migrates Android projects to Android Gradle Plugin 9 with new DSL and built-in Kotlin.

Official
Advanced