Last week Chris Banes — yeah, that Chris Banes from the Android team at Google — published a public repo of Claude Code skills targeting Kotlin, Jetpack Compose, and Android. I spent an evening poking around it, and there's enough here worth writing about.

I'm not going to pretend I've battle-tested every skill in the repo. But I've been using Claude Code skills for backend work for a few months now, and seeing someone with deep Android expertise share their setup publicly is a useful signal worth unpacking.

What Are Claude Code Skills, Anyway?

Quick refresher before we get into the repo itself. Skills are reusable instruction files you drop into a .claude/skills/ directory. Claude picks them up automatically and invokes the relevant ones when their description matches what you're trying to do. The official docs cover the format in more detail.

A typical skill file structure looks like this:

---
name: my-skill-name
description: "When to use this skill — Claude reads this to decide"
---

# Skill instructions
Step-by-step guidance for the model...

That's it. Frontmatter with name and description, then plain markdown instructions. Easy to write, easy to share.

Why This Beats Pasting Snippets

Before I started using skills, the way I shared "how we do things here" with Claude was either a CLAUDE.md file or just pasting context at the start of every session. Both work, but they have tradeoffs.

CLAUDE.md gets loaded every time, which bloats context for tasks where the conventions don't apply. Pasting context manually means you forget half of it. Skills sit somewhere in the middle — they're available but only pulled in when relevant.

For Android work specifically, this matters more than you'd think. Compose has at least three reasonable ways to handle state depending on context, and getting Claude to pick the right one without explicit guidance is hit or miss.

A Practical Example

Say I'm scaffolding a screen with a list and detail view. Without guidance, Claude might give me back a perfectly valid MutableStateFlow in a ViewModel when what I actually wanted was a rememberSaveable because the state should survive config changes but doesn't need to live anywhere else.

A skill file for this might look like:

---
name: compose-state-decisions
description: Use when scaffolding Compose UI state — guides choice between rememberSaveable, ViewModel state, and remember
---

When picking state holders in Compose:
- `remember`: ephemeral UI state (expanded/collapsed)
- `rememberSaveable`: state that should survive config changes
- ViewModel state: state shared across screens or surviving process death

Prefer `rememberSaveable` over ViewModel for screen-local state
unless the state needs to be observed elsewhere.

That's the kind of thing where a skill earns its keep. You're not writing code — you're encoding judgment that Claude can apply consistently across sessions.

Setting It Up

Cloning into your project's skills directory is the obvious first move:

# From your Android project root
mkdir -p .claude/skills
cd .claude/skills

# Pull in the repo (or copy specific skills you want)
git clone https://github.com/chrisbanes/skills.git chrisbanes

After that, Claude Code should pick them up on the next session. You can verify by asking Claude what skills it has available.

One thing I'd recommend: don't just dump the whole thing in and forget about it. Read through the skill descriptions, decide which ones match how your team actually works, and prune the ones that don't fit. Skills you don't use are noise that can muddle relevance scoring.

Where This Pattern Has Legs

The interesting thing about Chris's repo isn't really the specific skills — it's that someone with serious Android credentials is sharing them publicly. That means others can fork, adapt, or just learn from how to structure skills well.

I'd love to see more of this across other ecosystems. A skills repo for Rust async patterns. One for Spring Boot conventions. One for React Server Components gotchas. The model is portable, and the more reference examples there are, the better everyone's skills get.

A few weeks ago I started writing skills for our team's internal conventions, and the format Chris uses is tighter than what I'd been doing. Short descriptions, clear when-to-use guidance, minimal prose. I'm going to refactor mine this week.

Things to Watch Out For

A few things I've bumped into running skills in real projects:

• Skill descriptions matter more than the body. Claude uses the description to decide whether to invoke a skill. Vague descriptions equal skills that never fire.
• Overlapping skills cause weird behavior. If two skills both claim to handle Compose state, you'll get inconsistent invocation. Be ruthless about scope.
• Project-specific beats generic. A skill that says "use clean architecture" is too broad to be useful. One that says "use our Result<T> type for network calls" lands much better.

Also a small tooling aside — if you're tracking how often skills get used across your team (or just want analytics on your dev blog without the GDPR cookie banner dance), privacy-focused options like Umami or Plausible give you full data ownership and a much lighter footprint than Google Analytics. I migrated two side projects to Umami last year and haven't looked back.

Should You Use This Repo?

If you write Android, Kotlin, or Compose code and you're already using Claude Code, yes — at least take a look. Even if you don't adopt the skills wholesale, the patterns in how they're written are worth learning from.

If you're not using Claude Code yet for Android work, this repo is a reasonable nudge to try it. Pair it with your own CLAUDE.md and you've got a setup that respects your conventions without constant babysitting.

I haven't tested this thoroughly enough on a real feature to make grand claims — I'll probably write a follow-up once I've used it for a couple of weeks on something nontrivial. But the early signal is positive. The skill format is simple enough that even if Chris's repo isn't a perfect fit for your project, it gives you a clear template to write your own.

Go read the repo: github.com/chrisbanes/skills.