Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/AmolPardeshi99/android-performance-skills/llms.txt

Use this file to discover all available pages before exploring further.

The SKILL.md standard is an open format supported across all major AI coding agents. On startup, the agent reads only the name and description fields from each installed skill — roughly 100 tokens per skill. The full skill body is loaded only when the user’s task matches the skill’s description. This keeps the agent’s context window lean during unrelated work while making exhaustive domain knowledge available exactly when it is needed.

​
How a skill activates

1

Agent starts up and reads skill metadata

When your AI coding agent launches, it scans the skills directory and reads the name and description field from each SKILL.md file. This costs about 100 tokens per skill and takes no meaningful context space.
2

You start a task involving Android performance

You ask your agent to review a coroutine, fix a memory leak, audit a BroadcastReceiver, or investigate why your app is freezing. The agent evaluates your request against the skill descriptions it loaded on startup.
3

Agent detects the task matches a skill

The agent identifies that your task matches one of the installed skills — for example, a question about withContext or runBlocking matches the ANR and jank prevention skill, while a question about onDestroyView or ViewBinding matches the memory leak prevention skill.
4

Full skill content is loaded and applied

The agent loads the complete SKILL.md body and uses it to inform every suggestion, code review, and fix it produces. You get exhaustive, pattern-by-pattern guidance without having to prompt for it.

​
Project structure

The repository contains two skill directories, each with a single SKILL.md file: 
android-performance-skills/
├── android-performance-anr-and-jank-prevention/
│   └── SKILL.md  # 1,667 lines — ANR, jank, main-thread safety
└── android-performance-memory-leak-prevention/
    └── SKILL.md  # 1,504 lines — memory leaks, GC, Compose leaks
The file inside each skill folder must be named exactly SKILL.md (uppercase). Most agents pick up new skills without a restart.

​
Skills activate automatically

You do not need to invoke these skills manually or include them in your prompts. The agent handles detection and loading on its own. When you are working on unrelated code, the skills stay out of the context window entirely.

​
Which tasks trigger each skill

The ANR and jank prevention skill activates whenever your task involves:
  • Coroutines or threading — Dispatchers, withContext, runBlocking, GlobalScope, Mutex, synchronized
  • Android component lifecycles — Activity, Fragment, Service, BroadcastReceiver, JobService, ContentProvider
  • Jetpack Compose recomposition or state — remember, derivedStateOf, LazyColumn, Modifier, stability
  • RecyclerView or Adapter code — onBindViewHolder, DiffUtil, ListAdapter
  • Binder IPC or system service calls — PackageManager, ContentResolver, AccountManager
  • SharedPreferences or DataStore
  • Custom views or onDraw
  • Background work — WorkManager, coroutine scopes, JobScheduler
  • Any mention of ANR, frozen frames, jank, performance, StrictMode, Perfetto, or Android Vitals
  • ANR log analysis, thread traces, CPU usage in bugreports, or distinguishing app-side ANRs from system-induced ones
It also triggers for casual phrasings like “why is my app freezing”, “how do I avoid ANR”, “is this code safe to run on the main thread”, or “my app got an ANR in production”.
The memory leak prevention skill activates whenever your task involves:
  • Fragment or Activity lifecycle and ViewBinding — onDestroyView, nulling _binding
  • Context usage in singletons or long-lived objects — applicationContext vs Activity context
  • Static fields or companion objects holding views or activities
  • Listeners, observers, or BroadcastReceivers without symmetric unregistration
  • LiveData or Flow collection in Fragments — viewLifecycleOwner, repeatOnLifecycle
  • ViewModel holding UI references or callbacks
  • Coroutine scopes — GlobalScope, CoroutineScope, viewModelScope, lifecycleScope
  • Resource management — Cursor, InputStream, MediaPlayer, Bitmap, SQLite
  • Custom views — onDetachedFromWindow, animators, bitmaps
  • Handler and Runnable with postDelayed
  • WebView lifecycle
  • Hilt or DI scope alignment
  • Jetpack Compose memory concerns — remember, DisposableEffect, LaunchedEffect, rememberCoroutineScope, RememberObserver, LocalContext, composable lambdas in ViewModels
  • Detection and tooling — LeakCanary setup, Android Studio Memory Profiler, heapprofd, Perfetto heap graphs, ApplicationExitInfo OOM detection
It also triggers for casual phrasings like “why is my app crashing with OOM”, “is this a memory leak”, “should I use applicationContext here”, “how do I clean up in onDestroyView”, or “my Activity is leaking”.

Build docs developers (and LLMs) love

Get started for freeTalk to us