New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Kotlin Tooling Gradle To Kotlin Toolchain Plugin

by Kotlin in Kotlin/kotlin-agent-skills

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…

Apache-2.0Auto-check passedMobile

Install Kotlin Tooling Gradle To Kotlin Toolchain Plugin

skills CLI
$ npx skills add Kotlin/kotlin-agent-skills --skill kotlin-tooling-gradle-to-kotlin-toolchain-plugin -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Kotlin/kotlin-agent-skills kotlin-tooling-gradle-to-kotlin-toolchain-plugin --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Kotlin/kotlin-agent-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin .claude/skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
kotlin-tooling-gradle-to-kotlin-toolchain-plugin
GitHub stars
1.1k
Token cost
~3.2k tokens
SKILL.md length
932 words
Files
2 (incl. references)
Skills in repo
6
Repo updated
First seen
Licence
Apache-2.0

At a glance

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…

  • Works in 4 steps: Investigate the source plugin → Lock the scope → Implement bottom-up → …
  • Tasks that involve Android development
  • SKILL.md covers Workflow, Concept mapping, The mapped constructs and Redesigns, not ports, plus 1 more section
  • Calls git

What it does

Kotlin Tooling Gradle To Kotlin Toolchain Plugin is an agent skill from Kotlin/kotlin-agent-skills. 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.

Its SKILL.md is about 3.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/examples.md`).

It sits in Mobile, covering Android development. It works with Kotlin and Gradle. The repository describes itself as: A collection of AI agent skills useful for projects using Kotlin language. The licence is Apache-2.0.

When your agent uses it

  • Tasks that involve Android development

Example prompts

  • “/kotlin-tooling-gradle-to-kotlin-toolchain-plugin”

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Investigate the source plugin
  2. Lock the scope
  3. Implement bottom-up
  4. Validate against a demo module

What it can do on your machine

Read from SKILL.md and the folder at commit c2f9069. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • kotlin-toolchain.org

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Kotlin Tooling Gradle To Kotlin Toolchain Plugin loads about 3.2k tokens when it runs, and up to ~4.1k if it reads all its reference files. Until then it costs about 93 tokens; SKILL.md has 932 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~93
When it runs · the whole SKILL.md, loaded when a task matches
~3.2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~4.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Kotlin/kotlin-agent-skills at commit c2f9069, republished under its Apache-2.0 licence (© Kotlin). 932 words, ~3,160 tokens.

Download SKILL.mdSave it as .claude/skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
kotlin-tooling-gradle-to-kotlin-toolchain-plugin
description
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.
license
Apache-2.0
metadata.author
github:@singleton11
metadata.version
0.1.0

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/push and the context each receives.
  • CLI overrides — every -Pfoo.bar flag.
  • 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.

Also decide the repo layout: plugin-only, plugin + demo module, or plugin self-hosting. A demo module is strongly recommended.

3. Implement bottom-up

Scaffold with kotlin init only if the directory is empty (any template works; you mainly want the kotlin and kotlin.bat wrappers). Then hand-write project.yaml, plugins/<name>/module.yaml, and the demo module.

Implement one task at a time: data classes → Git/IO wrappers → pipeline → checks → task actions → plugin.yaml wiring.

4. Validate against a demo module

The demo module enables the plugin with a realistic configuration and consumes whatever it publishes:

yaml
# demo-app/module.yaml
product: jvm/app

plugins:
  release:
    enabled: true
    tagPrefix: "v"
    initialVersion: "0.1.0"
    releaseBranchPattern: "main|master"

settings:
  jvm:
    mainClass: com.example.demo.MainKt
    jdk:
      version: 21
  kotlin:
    languageVersion: 2.1
kotlin
// demo-app/src/main.kt
package com.example.demo

private const val VERSION_RESOURCE = "/META-INF/release/version.txt"

fun main() {
    val version = readVersionFromClasspath() ?: "(version unavailable)"
    println("demo-app version: $version")
}

private fun readVersionFromClasspath(): String? =
    object {}.javaClass.getResourceAsStream(VERSION_RESOURCE)
        ?.bufferedReader()
        ?.use { it.readText().trim() }
        ?.takeIf { it.isNotEmpty() }

Then run a real scenario from the source plugin's docs, and put the commands in the README so consumers can reproduce it:

sh
./kotlin run :demo-app            # => demo-app version: 0.1.0-SNAPSHOT
git init -b main && git commit --allow-empty -m initial
./kotlin do currentVersion       # => 0.1.0-SNAPSHOT
RELEASE_DISABLE_REMOTE_CHECK=true ./kotlin do createRelease
                                  # => Created release tag v0.1.0
./kotlin do currentVersion       # => 0.1.0
git commit --allow-empty -m next
./kotlin do currentVersion       # => 0.1.1-SNAPSHOT
RELEASE_FORCE_VERSION=2.0.0 ./kotlin do currentVersion
                                  # => 2.0.0

Concept mapping

Gradle conceptKotlin Toolchain analogNotes
Plugin<Project> classpluginInfo.id + settingsClass in module.yaml, product: jvm/amper-pluginOne module per plugin; no apply().
Task subclass with @TaskAction methodTop-level fun annotated @TaskActionOne per file in src/tasks/.
extensions.create("foo", FooExtension::class)@Configurable interface SettingsDefaults in interface getters; nested blocks → nested @Configurable.
task.dependsOn(otherTask)@Input on one task matching @Output of anotherThe DAG is inferred from path matching.
project.version = scmVersion.versionA task writing version.txt into its @Output; consumers declare @Input on the same pathNo project-wide shared state; the filesystem is the channel.
-Prelease.forceVersion=XRELEASE_FORCE_VERSION=X read via System.getenv()No -P equivalent.
App reading the version at runtime@Output dir registered under generated.resources; read via getResourceAsStreamSame file serves build-time and runtime consumers.
Generated Kotlin sourcegenerated.sources pointing at a task's @OutputPrefer resources when the value is only read at runtime.
Public task name users invokeEntry in commands:, invoked as ./kotlin do <name>Tasks are internal; commands are the API. Build-graph contributors stay out.
Project.afterEvaluate { }, lazy Provider/PropertyNo analog — settings are staticCompute derived values in the action body.
Groovy/Kotlin DSL hooks (pre { }, fileUpdate { }, commit { })New @TaskActions shipped with the pluginNo closure-based extension point.
dependencies { implementation(...) }dependencies: in plugins/<name>/module.yamlSame coordinates; : exported, : runtime-only, : compile-only suffixes.
Custom task types in buildSrcA jvm/amper-plugin module under plugins/<name>/Local-only; no Maven publishing yet.
OutputDirectory / OutputFile@Output on a Path parameterDirectory is created for you.
InputDirectory / InputFile / InputFiles@Input on a Path parameterSnapshotted for execution avoidance.
outputs.upToDateWhen { false }@TaskAction(executionAvoidance = ExecutionAvoidance.Disabled)For Git/network/env inputs.
Configuration with custom resolution, taskGraph.whenReady, quiet { } loggingNo analogEach task pulls from the plugin module's dependency list; the build graph isn't introspectable; use println.
Show full SKILL.md (296 more words)Show less

The mapped constructs

project.yaml — making the plugin resolvable

Lists every module, plugins included, and points at the plugin source:

yaml
modules:
  - demo-app
  - plugins/release

plugins:
  - ./plugins/release

Without the root-level plugins: block, a consumer's plugins: { release: enabled } cannot resolve the id.

Settings — the extension analog

Gradle's myPlugin { ... } extension becomes a @Configurable interface. Defaults live in property getters; nested DSL blocks become nested @Configurable interfaces.

kotlin
package com.example.release

import org.jetbrains.amper.plugins.Configurable

@Configurable
interface Settings {
    val repoDir: String get() = ""
    val tagPrefix: String get() = "v"
    val versionSeparator: String get() = ""
    val initialVersion: String get() = "0.1.0"
    val ignoreUncommittedChanges: Boolean get() = false
    val releaseBranchPattern: String get() = "main|master"
    val checks: ChecksSettings
}

@Configurable
interface ChecksSettings {
    val uncommittedChanges: Boolean get() = true
    val aheadOfRemote: Boolean get() = true
    val snapshotDependencies: Boolean get() = true
}

Consumers set what they need in module.yaml, keyed by pluginInfo.id; omitted values fall back to the getter default:

yaml
plugins:
  release:
    enabled: true
    tagPrefix: "v"
    initialVersion: "0.1.0"
    ignoreUncommittedChanges: false
    checks:
      aheadOfRemote: true
@TaskAction — the Task analog

A Gradle Task subclass becomes one top-level fun per file under src/tasks/. Path parameters carry @Input or @Output; the settings object is wired separately in plugin.yaml.

kotlin
package com.example.release.tasks

import com.example.release.Settings
import com.example.release.git.GitRepo
import com.example.release.version.VersionPipeline
import org.jetbrains.amper.plugins.Input
import org.jetbrains.amper.plugins.TaskAction
import java.nio.file.Path

@TaskAction
fun currentVersion(
    @Input moduleRootDir: Path,
    settings: Settings,
) {
    val pipeline = VersionPipeline(settings)
    GitRepo.open(moduleRootDir, settings.repoDir).use { repo ->
        println(pipeline.infer(repo).version)
    }
}
plugin.yaml — task and command registry

Each action: block wires one @TaskAction's parameters, addressing the function by fully-qualified name in YAML tag form. ${module.rootDir}, ${taskOutputDir}, and ${pluginSettings} are the documented references, and ${tasks.<task>.action.<param>} cross-references another task's parameter.

yaml
tasks:
  currentVersion:
    action: !com.example.release.tasks.currentVersion
      moduleRootDir: ${module.rootDir}
      settings: ${pluginSettings}

  writeVersion:
    action: !com.example.release.tasks.writeVersion
      moduleRootDir: ${module.rootDir}
      outputDir: ${taskOutputDir}
      settings: ${pluginSettings}

  release:
    action: !com.example.release.tasks.release
      moduleRootDir: ${module.rootDir}
      settings: ${pluginSettings}

generated:
  resources:
    - directory: ${tasks.writeVersion.action.outputDir}

# `writeVersion` stays out of commands: its @Output feeds generated.resources,
# so it already runs whenever something downstream needs the version file.
commands:
  - currentVersion
  - release

Every action taking a Settings parameter needs its own settings: ${pluginSettings} line; omitting it passes null.

Redesigns, not ports

Three Gradle features need conscious redesign every time.

No project.version

Turn the value into a file: one @TaskAction writes version.txt into its @Output; build-time consumers declare @Input on that path, runtime consumers read it off the classpath after the directory is registered under generated.resources. Code in references/examples.md.

No -P properties

Read ephemeral overrides from the environment inside the action. Take the env map as a constructor parameter rather than calling System.getenv() in nested methods, so tests can inject a controlled map:

kotlin
class VersionPipeline(
    private val settings: Settings,
    private val env: Map<String, String?> = System.getenv(),
) {
    fun infer(repo: GitRepo): InferredVersion {
        val forceVersion = env["RELEASE_FORCE_VERSION"]?.takeIf { it.isNotBlank() }
        val forceSnapshot = env["RELEASE_FORCE_SNAPSHOT"].asBoolean()
        // ...
    }
}

private fun String?.asBoolean(): Boolean =
    this != null && this.equals("true", ignoreCase = true)

Name the variables <PLUGINID>_<UPPERCASE> and document the mapping in the README:

-Prelease.forceVersion=X              → RELEASE_FORCE_VERSION=X
-Prelease.forceSnapshot               → RELEASE_FORCE_SNAPSHOT=true
-Prelease.disableChecks               → RELEASE_DISABLE_CHECKS=true
-Prelease.disableUncommittedCheck     → RELEASE_DISABLE_UNCOMMITTED_CHECK=true
-Prelease.disableRemoteCheck          → RELEASE_DISABLE_REMOTE_CHECK=true
-Prelease.overriddenBranchName=X      → RELEASE_OVERRIDDEN_BRANCH_NAME=X

Static config still goes through module.yaml; env vars are only for ephemeral overrides.

README contents

Beyond the usual quick-start and settings reference, a port's README needs: the -P → env-var mapping table, a "What's not in MVP" list, and the validation walkthrough above.

Plugin docs: https://kotlin-toolchain.org/dev/user-guide/plugins/

© Kotlin, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin of Kotlin/kotlin-agent-skills.

  • SKILL.md
  • references/examples.md

Open the folder on GitHubat commit c2f9069

Compare with similar skills

Kotlin Tooling Gradle To Kotlin Toolchain Plugin next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Kotlin Tooling Gradle To Kotlin Toolchain Plugin compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Kotlin Tooling Gradle To Kotlin Toolchain Plugin this skillKotlin/kotlin-agent-skills1.1k—~3.2kAutomated safety check: PassApache-2.0
Android Developmentdpconde/claude-android-skill336—~1.7kAutomated safety check: PassMIT
Diagnosing Compose StabilityrosuH/EasyWatermark1.9k1 repos~3.3kAutomated safety check: PassApache-2.0
Claude Android NinjaDrjacky/claude-android-ninja124—~5.2kAutomated safety check: PassApache-2.0
Expo Brownfield Integrationmweinbach/agent-coworker1562 repos~900Automated safety check: NotesCustom licence
Jugg Android Dev Loopniki914/zafiro241—~2kAutomated safety check: PassMIT

Similar skills

  • Android Development

    dpconde/claude-android-skill

    Create production-quality Android applications following Google's official architecture guidance and NowInAndroid best practices.

    336 GitHub stars~1.7k tokensUpdated 10 mo ago
    MobileAuto-check passed

  • Diagnosing Compose Stability

    rosuH/EasyWatermark

    A skill your agent uses to diagnose Jetpack Compose stability problems by enabling and reading the Compose Compiler Reports (classes.txt, composables.txt, composables.csv, module.json).

    1.9k GitHub starsUsed in 1 repo~3.3k tokens
    MobileAuto-check passed

  • Claude Android Ninja

    Drjacky/claude-android-ninja

    Build and migrate Android apps with Kotlin, Jetpack Compose, MVVM, Hilt, Room 3 (KSP, SQLiteDriver, Flow/suspend DAOs), Navigation3, and multi-module Gradle.

    124 GitHub stars~5.2k tokensUpdated 11 days ago
    MobileAuto-check passed

  • Expo Brownfield Integration

    mweinbach/agent-coworker

    Helps add Expo and React Native to an existing native iOS or Android app, and choose between a prebuilt AAR or XCFramework and a fully integrated build.

    156 GitHub starsUsed in 2 repos~900 tokens
    MobileAuto-check: notes

  • Jugg Android Dev Loop

    niki914/zafiro

    A skill your agent uses when editing source files (Java/Kotlin/XML/layout/AndroidManifest/Gradle) in a Android project, or when user asks to build/deploy/verify an Android app.

    241 GitHub stars~2k tokensUpdated today
    MobileAuto-check passed

  • Build Foreman

    nekomangaorg/Neko

    Optimizes Gradle build scripts, compilation times, and Android Studio sync performance.

    2.8k GitHub stars~807 tokensUpdated yesterday
    MobileAuto-check passed

More from Kotlin/kotlin-agent-skills

  • Kotlin Tooling Native Build Performance

    Kotlin/kotlin-agent-skills

    Diagnoses and fixes slow Kotlin/Native compilation and linking in Kotlin Multiplatform projects that target iOS.

    1.1k GitHub stars~2k tokensUpdated 3 days ago
    Auto-check passed

  • Kotlin Tooling Kotlin Toolchain

    Kotlin/kotlin-agent-skills

    Load when building, running, testing, packaging, linting, or configuring a Kotlin/Java project with the Kotlin Toolchain (JetBrains' unified CLI, formerly Amper), when scaffolding a new or…

    1.1k GitHub stars~2.4k tokensUpdated 3 days ago
    Auto-check passed

  • Kotlin Tooling Kotlin Toolchain Plugin Authoring

    Kotlin/kotlin-agent-skills

    Load when authoring, writing, or designing a Kotlin Toolchain local plugin to extend the declarative build with code generation, build-time processing, custom verification, or packaging that…

    1.1k GitHub stars~2.3k tokensUpdated 3 days ago
    Auto-check passed

  • Kotlin Tooling Gradle To Kotlin Toolchain Project

    Kotlin/kotlin-agent-skills

    Load when migrating or converting an entire Gradle Kotlin project (build.gradle(.kts), wrapper, libs.versions.toml, buildSrc) to the Kotlin Toolchain, including rewriting CI and replacing Gradle…

    1.1k GitHub stars~6k tokensUpdated 3 days ago
    Auto-check passed

Works with

Categories

Questions about Kotlin Tooling Gradle To Kotlin Toolchain Plugin

What does Kotlin Tooling Gradle To Kotlin Toolchain Plugin do?

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…. Kotlin Tooling Gradle To Kotlin Toolchain Plugin is an agent skill from Kotlin/kotlin-agent-skills.version, dependsOn, -P properties, afterEvaluate) to Toolchain analogs.

When should I use Kotlin Tooling Gradle To Kotlin Toolchain Plugin?

Kotlin Tooling Gradle To Kotlin Toolchain Plugin fits situations like: tasks that involve Android development.

How do I install Kotlin Tooling Gradle To Kotlin Toolchain Plugin in Claude Code?

Run `npx skills add Kotlin/kotlin-agent-skills --skill kotlin-tooling-gradle-to-kotlin-toolchain-plugin -a claude-code`. Or copy the skill folder (skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin in Kotlin/kotlin-agent-skills) into .claude/skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin in your project. Claude Code loads it when a task matches its description.

How do I install Kotlin Tooling Gradle To Kotlin Toolchain Plugin in Codex?

Run `npx skills add Kotlin/kotlin-agent-skills --skill kotlin-tooling-gradle-to-kotlin-toolchain-plugin -a codex`. Or copy the skill folder (skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin in Kotlin/kotlin-agent-skills) into .agents/skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin in your project. Codex loads it when a task matches its description.

Can I use Kotlin Tooling Gradle To Kotlin Toolchain Plugin in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Kotlin/kotlin-agent-skills --skill kotlin-tooling-gradle-to-kotlin-toolchain-plugin -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin, .gemini/skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin, .github/skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin and .opencode/skills/kotlin-tooling-gradle-to-kotlin-toolchain-plugin in your project.

What does Kotlin Tooling Gradle To Kotlin Toolchain Plugin need to run?

Going by SKILL.md and its folder, Kotlin Tooling Gradle To Kotlin Toolchain Plugin needs the command-line tools its instructions call (git).

Does Kotlin Tooling Gradle To Kotlin Toolchain Plugin access the network?

SKILL.md names 1 domain. As links in the text: kotlin-toolchain.org. This is read from the text; nothing was executed.

Is Kotlin Tooling Gradle To Kotlin Toolchain Plugin safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Kotlin Tooling Gradle To Kotlin Toolchain Plugin use?

Kotlin Tooling Gradle To Kotlin Toolchain Plugin is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Kotlin Tooling Gradle To Kotlin Toolchain Plugin use?

About 3.2k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 929 tokens, read only when the agent opens those files.

What are the alternatives to Kotlin Tooling Gradle To Kotlin Toolchain Plugin?

Skills that share tags, products or a category with Kotlin Tooling Gradle To Kotlin Toolchain Plugin: Android Development (dpconde/claude-android-skill, 336 stars), Diagnosing Compose Stability (rosuH/EasyWatermark, 1.9k stars), Claude Android Ninja (Drjacky/claude-android-ninja, 124 stars) and Expo Brownfield Integration (mweinbach/agent-coworker, 156 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Kotlin Tooling Gradle To Kotlin Toolchain Plugin?

Kotlin (a GitHub organization) maintains it in Kotlin/kotlin-agent-skills, which has 1,072 GitHub stars. The repository holds 6 skills in this directory. The repository was last updated on October 8, 2026.

Source: Kotlin/kotlin-agent-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.