agentsclimarketplace

Android gradle build performance

Skill krutikJain/android-agent-skills/.github/skills/android-gradle-build-performance

Android skills repository for Kotlin, Compose, XML, testing, CI, release work, and legacy upgrades

Install
npx -y skills add krutikJain/android-agent-skills --skill android-gradle-build-performance

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Diagnose and improve Android and Gradle build performance with scans, cache checks, and bottleneck audits.

SKILL.md

4.8 KB, 841 tokens by cl100k_base, as published. Nobody here has run it

Android Gradle Build Performance

When To Use

  • Use this skill when the request is about: android gradle build performance, configuration cache android build, ksp vs kapt android.
  • Primary outcome: Diagnose and improve Android and Gradle build performance with scans, cache checks, and bottleneck audits.
  • Use this skill when the problem is build speed, task churn, cache misses, or CI wall time rather than build-logic structure.
  • Read references/patterns.md when you need the measurement ladder or the most common Gradle performance smells.
  • Read references/scenarios.md for audit-first entry points on the example projects.
  • Handoff skills when the scope expands:
  • android-gradle-build-logic
  • android-ci-cd-release-playstore

Workflow

  1. Identify whether the problem is local developer feedback time, CI build duration, or both.
  2. Measure one build path at a time with --profile, --scan, configuration-cache diagnostics, or the bundled audit script before proposing a fix.
  3. Check gradle.properties, plugin wiring, dependency declarations, task registration style, and module conventions for common performance smells.
  4. Apply one high-confidence optimization at a time, then compare before and after behavior instead of stacking changes.
  5. Hand off structural Gradle refactors or release-pipeline changes once the performance bottleneck is isolated.

Guardrails

  • Do not recommend broad rewrites when a single cache, plugin, or dependency pattern is the real bottleneck.
  • Separate measurement from speculation; call out what was observed vs inferred.
  • Prefer KSP, configuration cache, and lazy task configuration when the toolchain supports them.
  • Treat dynamic dependency versions, changing modules, and eager task creation as performance regressions unless there is a deliberate reason.
  • Keep CI guidance reproducible on the example projects before suggesting org-wide rollout.

Anti-Patterns

  • Turning on every Gradle flag without checking compatibility or failures.
  • Blaming AGP upgrades for slow builds without measuring task hot spots.
  • Mixing build-logic architecture advice with build-time diagnosis in one pass.
  • Using dynamic dependency versions that force repeated resolution work.

Review Focus

  • Configuration time vs execution time vs dependency resolution vs test wall time.
  • Configuration cache compatibility and lazy task registration.
  • KSP vs kapt and annotation-processor hotspots.
  • Remote/local cache value, dynamic dependencies, and CI-specific bottlenecks.

Examples

Happy path

  • Scenario: Audit the Compose fixture for build cache, configuration cache, KSP, and eager task creation smells.
  • Command: python3 skills/android-gradle-build-performance/scripts/audit_build_performance.py examples/orbittasks-compose --json

Edge case

  • Scenario: Compare XML and Compose fixture build settings before choosing a CI build optimization.
  • Command: bash skills/android-gradle-build-performance/scripts/run_examples.sh

Failure recovery

  • Scenario: Re-check a project after enabling performance flags so regressions are caught before rollout.
  • Command: python3 skills/android-gradle-build-performance/scripts/audit_build_performance.py examples/orbittasks-xml

Done Checklist

  • The bottleneck is tied to a specific phase, flag, plugin, or dependency pattern.
  • Proposed optimizations are measurable and reversible.
  • The recommended fix is compatible with the current Android and Gradle toolchain.
  • Structural Gradle work is handed off separately from performance tuning.

Official References

What ships with it: 6 files

7.6 KB alongside SKILL.md, 2 of them executable

agents/

references/

Gives 0 of the 12 instructions most performance cost skills give in 841 tokens

Counted across 803 of the 1,058 authors here whose files we hold, read 2026-08-07

  • Keep skill files under 500 lines or tokensin 82 of 803, across 16 files
  • Use imperative form in instructionsin 80 of 803, across 9 files
  • Draft assertions while test runs are in progressin 75 of 803, across 9 files
  • Create two to three realistic test promptsin 74 of 803, across 9 files
  • Write skill descriptions to be pushyin 72 of 803, across 7 files
  • Save test cases to evals JSONin 72 of 803, across 6 files
  • Ask questions about edge cases and input formatsin 72 of 803, across 7 files
  • Save timing data immediately when runs completein 70 of 803, across 5 files
  • Include all trigger conditions in the skill descriptionin 69 of 803, across 3 files
  • Launch all test runs in a single turn or simultaneouslyin 69 of 803, across 3 files
  • Capture intent before writing a skillin 67 of 803, across 1 file
  • Import directly instead of barrel filesin 52 of 803, across 15 files

Said here and by no other author read

  • Identify if the problem is local or CI build time
  • Measure one build path before proposing a fix
  • Check gradle properties for common performance smells
  • Compare behavior before and after changes
  • Hand off structural refactors after isolating bottleneck
  • Separate measurement from speculation

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.