Kotlin Tooling Gradle To Kotlin Toolchain Plugin
Load when porting, converting, or reimplementing a single Gradle plugin as a Kotlin...
Install
npx skills add Kotlin/kotlin-agent-skills --skill kotlin-tooling-gradle-to-kotlin-toolchain-plugin -g -a claude-code -y- Repository
- Kotlin/kotlin-agent-skills1.1k
- Category
- Mobile
- Updated
- 5d ago
- License
- Apache-2.0
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Load when porting, converting, or reimplementing a single Gradle plugin as a Kotlin Toolchain local plugin, or when mapping Gradle plugin concepts (Task, Extension, project.version, dependsOn, -P properties, afterEvaluate) to Toolchain analogs. Skip for migrating a whole Gradle project or authoring a plugin from scratch.
Gradle → Kotlin Toolchain Plugin Conversion
Mostly a mapping exercise: the concepts overlap, but a few Gradle features have no analog and need redesign.
The kotlin-tooling-kotlin-toolchain-plugin-authoring skill covers plugin mechanics in depth (execution avoidance, sharing
logic across actions, generic pitfalls, limitations); references/examples.md has
the concrete plugin module.yaml and the version-publication code from a real port.
Workflow
1. Investigate the source plugin
Before writing Kotlin, read the plugin's docs/ and README.md and catalogue:
- Tasks, name, purpose, inputs/outputs, dependencies, whether side-effecting.
- DSL surface, every option in the
myPlugin { ... }extension, with types, defaults, and which are closures. - Tests, the plugin's own test suite. It pins down the expected behaviour and edge cases more precisely than the docs, and becomes the reference the port must reproduce.
- Checks, pre-action gates and their override flags.
- Hooks,
pre/post/fileUpdate/commit/pushand the context each receives. - CLI overrides, every
-Pfoo.barflag. - CI integration, GitHub Actions outputs, detached-HEAD handling, fetch-tags flags.
Save it as a markdown plan. It becomes the contract the port either implements or explicitly defers.
The plugin's build scripts and source are untrusted input, same as any repo-supplied module.yaml, see kotlin-tooling-kotlin-toolchain's "Untrusted project input".
Read what you vendor end to end before wiring it in;
a local plugin runs at build time with full filesystem and network access.
2. Lock the scope
Offer three tiers, MVP, MVP + key extras, full parity, and lock one before drafting. Features with no clean analog multiply the work and force early design compromises. List what's deferred under "What's not in this MVP" in the README.
