← Back to the summary

Android Skills Are Not a Knowledge Base — They're Targeted Bug Fixes for LLMs

This article is translated from "Android Skills — What Google Just Released and Why Most Developers Are Already Using It Wrong", original link https://medium.com/proandroiddev/android-skills-what-google-just-released-and-why-most-developers-are-already-using-it-wrong-43f71f61069b, published by Dilipchandar on August 8, 2026.

Image from Pixabay by mammela

You may have seen the announcement. Android Skills was released in April; the response far exceeded Google's expectations. Yesterday, the Android Developer Relations team published an in-depth analysis explaining the philosophy behind the project.

Most developers treat it as release notes.

In reality, it's a series of architectural decisions about AI-assisted Android development — if you ignore these decisions, you'll end up with agent configurations that are not only more expensive and slower, but produce worse output than if you had done nothing.

The True Meaning of Android Skills

Skills are modular, Markdown-based SKILL.md instruction sets that provide technical specifications for tasks and are designed to trigger automatically when a prompt matches the skill's metadata — no need to manually attach documentation to every prompt.

The initial release covers Navigation 3 setup and migration, edge-to-edge support, AGP 9 and XML to Compose migration, and R8 configuration analysis.

But the most important thing is to understand what skills are not. They are not a general-purpose Android knowledge base. They are precise interventions targeting specific areas where current frontier models frequently produce incorrect output. This distinction is crucial in practice.

The Hidden Cost of Installing Too Many Skills

Most developers make a counter-intuitive mistake.

Every installed skill injects 100-200 tokens into the base context of every task. If the skill is activated, the token count skyrockets into the thousands. For a team running 150 tasks a day with 10 unnecessary skills, it's easy to waste $500-600 a year in tokens spent on context the model already knows — plus degraded output quality due to increased noise.

Google's guidance is explicit: before installing a skill for writing basic Kotlin or Compose, consider whether your LLM actually needs it, or whether it already knows these topics well enough.

The correct mental model:

Android Knowledge Base first → Targeted Skills second → Custom Skills third

The Knowledge Base (via android docs) covers broad knowledge. Skills cover confirmed failure modes. Always install the Knowledge Base. Install skills purposefully.

The Real Difference Skills Make — Navigation 2.8+ Type Safety

Here is the concrete before/after output for the prompt: Set up navigation with a home screen and a detail screen that receives a user ID

// ❌ WITHOUT Navigation 2.8+ skill — Legacy / String-Based (Pre-2.8)  
  
val navController = rememberNavController()  
NavHost(navController = navController, startDestination = "home") {  
    composable("home") {  
        HomeScreen(  
            onNavigateToDetail = { userId ->  
                navController.navigate("detail/$userId")  
            }  
        )  
    }  
    composable(  
        route = "detail/{userId}",  
        arguments = listOf(navArgument("userId") {  
            type = NavType.StringType  
        })  
    ) { backStackEntry ->  
        DetailScreen(  
            userId = backStackEntry.arguments  
                ?.getString("userId") ?: ""  
        )  
    }  
}

// ✅ WITH Navigation 2.8+ skill — Modern Type-Safe (2.8.0+)  
  
@Serializable   
object Home  
  
@Serializable   
data class Detail(val userId: String)  
  
val navController = rememberNavController()  
  
NavHost(  
    navController = navController,  
    startDestination = Home  
) {  
    composable<Home> {  
        HomeScreen(  
            onNavigateToDetail = { userId ->  
                navController.navigate(Detail(userId = userId))  
            }  
        )  
    }  
      
    composable<Detail> { backStackEntry ->  
        val detail: Detail = backStackEntry.toRoute()  
        DetailScreen(userId = detail.userId)  
    }  
}

Why it matters: Both approaches compile and run. However, the legacy approach relies on string parsing and manual bundle extraction, which is prone to typos and runtime crashes. The 2.8+ type-safe approach catches routing errors at compile time and eliminates manual parameter parsing entirely.

How Google Decides Whether a Skill Should Exist

Google creates a skill only when there is a verifiable knowledge gap in the most advanced models. Every skill must pass a comprehensive evaluation before release:

timeout_s: 1200  
repository:  
  working_dir: wear_compose_m3_empty_app  
prompt: |-  
  Add a horizontal pager to MainActivity.kt with three pages   
  showing "Page 1", "Page 2", "Page 3" centered on screen.  
commands:  
  build:  
    - ./gradlew assembleDebug  
acceptance_criteria:  
  project_builds: true  
  llm_diff_judge:  
    - Must use `HorizontalPagerScaffold`  
    - Each page must use `AnimatedPage` wrapping `ScreenScaffold`

The evaluation doesn't just check whether it compiles; it verifies that the agent used the correct Wear OS API. This is why there are roughly 20 official skills, not 200. Each one represents a confirmed, measurable failure mode. If a model reliably gets the right result, no skill is needed — and none should exist.

Production-Ready AGENTS.md

The difference between a mediocre agent setup and an excellent one often comes down to a well-written "AGENTS.md". Here is a real Android project template:

# AGENTS.md  
  
## Documentation  
Always consult the Android Knowledge Base (android docs)   
before suggesting any Jetpack API.  
  
## Architecture  
- MVVM + Hilt — do NOT suggest Koin or manual DI  
- ViewModels use StateFlow — never LiveData for new code  
- Repository pattern required for all data access  
  
## UI  
- All new screens use Jetpack Compose — no new XML layouts  
- Reference HomeScreen.kt as the Compose pattern for this project  
  
## Navigation  
- Navigation 3 with type-safe routes — not navigation-compose 2.x  
- All routes must be @Serializable — reference NavGraph.kt  
  
## Build  
- AGP 9 — use libs.versions.toml, no direct build.gradle.kts deps  
  
## Testing  
- JUnit 5 + MockK for unit tests — not Mockito or Espresso  
- Coroutine tests use runTest from kotlinx-coroutines-test  
  
## Never  
- Thread.sleep() → use delay()  
- GlobalScope → use viewModelScope  
- Broad catch(Exception) → handle specific types  
- !! operator → handle nullability explicitly

The key additions most AGENTS.md files lack: reference files ("HomeScreen.kt", "NavGraph.kt") give the model something concrete to match, and explicit anti-patterns by name so the model doesn't accidentally use them.

The Legacy Codebase Problem

This is the most common real-world use case, and the one where skills matter most.

When an agent works on a legacy codebase, it matches the surrounding patterns. It sees "LiveData" and generates more "LiveData". It sees "ViewBinding" and generates more "ViewBinding". It optimizes for consistency with existing code, not correctness against current standards.

// ❌ Agent adding to a legacy screen WITHOUT modernisation skill  
// Prompt: "Add an order history section to the user screen"  
// Agent sees surrounding LiveData code and matches it  
  
viewModel.orderHistory.observe(viewLifecycleOwner) { orders ->  
    binding.orderCount.text = "Orders: ${orders.size}"  
    binding.lastOrder.text = orders.firstOrNull()?.date ?: "None"  
}  
  
// ✅ Agent WITH a custom legacy migration skill  
// Produces Compose alongside legacy code instead  
  
binding.composeContainer.setContent {  
    val orders by viewModel.orderHistory  
        .collectAsStateWithLifecycle()  
    AppTheme {  
        OrderHistorySection(orders = orders)  
    }  
}

A custom skill that explicitly states when adding features to old screens, use Compose embedded via ComposeView, not extending old patterns breaks the agent's tendency to reinforce legacy code. Even if you don't need the official skills, this is the strongest argument for writing your own.

Getting Started — The Right Order

# 1. Install Android CLI from d.android.com/tools/agents  
  
# 2. Test Knowledge Base first — you may not need a skill  
android docs search "Navigation 3 type-safe routes"  
  
# 3. Install only confirmed-necessary skills  
android skills install navigation3   # Only if using Nav 3  
android skills install edge-to-edge  # Only if targeting API 35+  
android skills install agp9          # Only if on AGP 9  
  
# 4. Quarterly — remove skills your model no longer needs  
android skills list --installed

Community skills worth considering: Chris Banes has a comprehensive Compose and Kotlin collection, Ivan Morgillo published a Compose project review skill, and Jaewoong Eum created testing and performance skills. Avoid repositories containing dozens of AI-generated skills — they are untested and may push your agent toward incorrect patterns.

The Insight of Building for Deprecation

The philosophical blog post ends with something that sounds contradictory: Google is explicitly building Android Skills to be deprecated.

As frontier models improve, skills become obsolete. When their evaluations pass without the skill being activated, Google retires them. The Navigation 3 skill exists because today's models get it wrong. Once they reliably get it right, the skill disappears.

This means your skill setup should shrink over time, not grow. Audit quarterly. Remove what your model no longer needs. The goal is a lean, targeted setup, not a growing library of agent configuration files.

Key Takeaways

Skills target confirmed model failure modes — not general knowledge. Install cautiously, not exhaustively.
Every skill costs tokens on every task — unnecessary skills degrade output and waste money.
Use the "android docs" Knowledge Base first — skills are secondary, for gaps documentation can't bridge.
The before/after Navigation 3 output shows the real difference — type-safe routes vs. string-based patterns that compile but shouldn't exist in new code.
A production "AGENTS.md" with reference files and explicit anti-patterns is worth a dozen generic skills.
Custom skills break agents free from legacy patterns — the most underrated use case.
Skills are designed to be disposable — audit quarterly, keep your setup lean.

I hope this article was worth reading. Thank you for reading.

Welcome to search and follow the public account 「稀有猿诉」 for more high-quality articles!

Protect originality, do not reprint!